Есть ли техническая разница между API / потреблением услуг монолитной и микросервисной архитектуры?

Question

Я изучаю концепцию микро-услуг. Я сделал небольшую демонстрацию и понял разницу между монолитным и микросервисным приложением. (архитектурная разница тоже. круто!) Демонстрация: используется Spring-Boot, Eureka, Spring-Cloud, который использует Обнаружение службы на стороне клиента.

Я также пытался понять обнаружение службы на стороне клиента и на стороне сервера. А потом я изо всех сил пытался понять техническую разницу между ... вызов API из монолитного приложения. и вызов микросервисов из другого приложения микросервисов. (как то, что на самом деле происходит под / за занавесками)

Для экземпляра, Рассмотрим следующий API из монолитного приложения. которые могут быть использованы из другого приложения монолит ./micorservice

A) GET API: http://127.0.0.1:8080/projects как традиционный REST API - это то, что я знаю и чего мы ожидаем.

Рассмотрим этот API, полученный из микросервисного приложения (скажем, Eureka Client)

B-initial) GET API: http://localhost:18082/products который впоследствии был преобразован для использования в целях обнаружения служб

B-new) http://product -инфо-сервис: 18082 / продукты

Итак, из того, что я наблюдаю, Eureka Server содержит эти имена сервисов в своем реестре сервисов. Всякий раз, когда какой-либо зарегистрированный клиент Eureka запрашивает вышеуказанный микросервис со своим конкретным «service-name», eurekaServer выполняет поиск, разрешает, если находит идеальное совпадение и перенаправляет запрос, запрос обрабатывается.

Моя забота: Так это все же происходит внутри? будь то монолит или микросервис? Я имею в виду, вызывает ли сервер обнаружения в микросервисах внутренний микросервис как API? ИЛИ отличается ли монолитный вызов API от вызова службы микросервиса? Или это просто абстракция.

PS: все еще учусь, заранее извиняюсь. Если я допустил ошибки, задавая здесь что-то неопределенное или запутанное. Пожалуйста, поправьте меня. Спасибо

Моя ссылка на git-hub: https://github.com/aniketrb-github/microservices Контент, из которого я слежу, является JavaBrains

Answer 1

Вы правы, это действительно просто абстракция и развязка сервисов. Единственное, что вы вводите, - это еще один запрос API. В A у вас есть client -> projects, тогда как в микросервисной архитектуре у вас есть client -> api-gateway -> projects. Это означает, что вы создали распределенную систему, которая имеет много плюсов и минусов (как и монолитная архитектура).

В целом, это по сути то же самое, возвращая список продуктов. Это просто получение списка продуктов из другого сервиса, а не изнутри монолитного приложения. Eureka используется для определения местонахождения других служб, поэтому она знает, где находится микросервис по отношению к вашему приложению шлюза.

В будущем вам захочется начать изучать отказоустойчивость и другие аспекты использования надежной архитектуры микросервиса.