Spring Boot - для чего используются разные системы (eureka, zuul, tape, nginx,)?

without having an API gateway is there any use with this service registry ?

да. Например, вы можете использовать его для определения (IP и порта) всех ваших микросервисов. Это пригодится для работы типа DevOps. Например, в одном проекте, над которым я работал, мы использовали Eureka, чтобы найти все экземпляры наших микросервисов и проверить их статус (/ health, / info).

I understand ZUUL can be used as API gateway which is basically a load balancer , that calls appropriate microservice corresponding to request URL. iS that assumption correct?

Да, но он может намного больше. По сути, поскольку Zuul - это скорее фреймворк / библиотека, которую вы превращаете в микросервис, вы можете закодировать ее для реализации любой логики маршрутизации, которую вы можете придумать. В этом смысле он очень мощный. Например, допустим, вы хотите изменить свой маршрут в зависимости от времени суток или любых других внешних факторов, с Zuul вы можете это сделать.

will the api gateway interact with Eureka for getting the appropriate microservice?

да. Вы настраиваете Зуул так, чтобы он указывал на Эврику. Он становится клиентом Eureka и даже подписывается на Eureka для получения обновлений в реальном времени (какие экземпляры присоединились или ушли).

I have read NGINX can also be used as API gateway? Also i read some where else like NGINX can be used as a service registry , that is as an alternate for Eureka ! Thus which is right? Api gateway or service registry or both?

Nginx довольно мощный и может выполнять работу типа шлюза API. Но есть несколько существенных отличий. AFAIK, микросервисы не могут динамически регистрироваться с помощью Nginx, пожалуйста, поправьте меня, если я ошибаюсь ... как они могут с Eureka. Во-вторых, хотя я знаю, что Nginx легко (очень хорошо) настраивается, я подозреваю, что его возможности настройки не приближаются к возможностям маршрутизации Zuul (из-за того, что в Zuul есть весь язык Java для кодирования вашей логики маршрутизации). Возможно, существуют решения для обнаружения сервисов, которые работают с Nginx. Таким образом, Nginx позаботится о маршрутизации и тому подобном, но для обнаружения сервисов все равно потребуется решение.

Is this can also be used as an alternate for ZUUL?

Да, AWS API Gateway можно использовать как своего рода замену Zuul. Проблема здесь, как и в Nginx, - это обнаружение служб. AWS API Gateway позволяет применять логику к маршрутизации ... хотя и не так открыто, как Zuul.

for what ribbon is used?

Хотя вы можете использовать библиотеку Ribbon напрямую, по большей части рассматривайте ее как внутреннюю зависимость Zuul. Это помогает Zuul выполнять простую балансировку нагрузки. Обратите внимание, что этот проект находится в режиме обслуживания и больше не рекомендуется.

This can also be used for load balancing. Thus do we need ZUUL if we have AWS ALB?

Вы можете использовать ALB с ECS (служба эластичных контейнеров), чтобы заменить Eureka / Zuul. ECS позаботится об обнаружении службы за вас и сопоставит все экземпляры конкретной службы с целевой группой. Затем ваша таблица маршрутизации ALB может маршрутизировать к целевым группам на основе простых правил маршрутизации. Правила маршрутизации в ALB очень простые, но со временем они улучшаются.

Различные системы, которые можно использовать для работы microservices, поставляемого вместе с пружинной загрузкой:

1. Эврика: Вероятно, первый микросервис, который будет работать. Eureka - это реестр служб, то есть он знает, какие микросервисы работают и в каком порту. Eureka развертывается как приложение sperate, и мы можем использовать аннотацию @EnableEurekaServer вместе с @SpringBootAPplication, чтобы сделать это приложение сервером eureka. Итак, наша служба регистрации eureka работает. Отныне все микросервисы будут регистрироваться на этом сервере eureka с использованием аннотации @EnableDiscoveryClient вместе с @SpringBootAPplication во всех развернутых микросервисах.

2. Зуул: ZUUL - это приложение load balancer, routing, а также сервер reverse proxy. Это было до того, как мы использовали apache для обратного прокси, теперь для микросервисов мы можем использовать ZUUL. Преимущество в том, что в ZUUL мы можем программно устанавливать конфигурации, например, если / customer / * приходит к этому микросервису, вот так. Также ZUUL может действовать как балансировщик нагрузки, который выбирает соответствующий микросервис циклически. Итак, как ZUUL знает детали микросервисов, ответ - эврика. Он будет работать вместе с eureka для получения сведений о микросервисе. И на самом деле этот ZUUL также является клиентом Eureka, где мы должны отметить использование @EnableDiscoveryClient, именно так связаны эти 2 приложения (Eureka и zuul).

3. Лента: Использование ленты для балансировки нагрузки. Это уже доступно в ZUUL, где zuul использует Ribbon для балансировки нагрузки. Микросервисы идентифицируются по имени службы в файле свойств. ЕСЛИ мы запускаем 2 экземпляра одного микросервиса в другом порту, это будет идентифицировано Eureka и вместе с Ribbon (Inside zuul) запросы будут перенаправлены сбалансированным образом.

4. AWS ALB, NGINX, шлюз AWS Api и т.д .: Для всего вышеупомянутого есть альтернативы. Aws имеет собственный балансировщик нагрузки, обнаружение служб, шлюз API и т. д. Они есть не только на AWS, но и на всех облачных платформах, таких как Azure. Это зависит от того, какой из них использовать.

5. Добавив также общий вопрос, Как эти микросервисы взаимодействуют друг с другом: Используя Resttemplate или Feignclient, можно вызвать фактический API отдыха или использовать очереди сообщений, такие как Rabbit MQ и т. д.

Eureka можно использовать вместе с NGINX, что приводит к очень мощной комбинации.

Я использую его в среде AWS EC2. Раньше вместо NGINX я использовал Spring Cloud Gateway, а до этого Zuul. В зависимости от нагрузки Spring Cloud Gateway работал на экземплярах AWS t3.medium или t3.large. После перехода на NGINX я использую экземпляр t3.micro (в 8 раз меньше памяти). Я почти уверен, что справлюсь и с экземпляром t3.nano (в 16 раз меньше памяти), но хотел быть уверен, что сюрпризов не будет.

Ниже приведены общие шаги, которые вам нужно сделать, чтобы подключить NGINX к экосистеме Eureka. Подробнее читайте в статье NGINX с Eureka вместо Spring Cloud Gateway или Zuul.

• Создайте службу, которая может считывать конфигурацию всех приложений из Eureka и «переводить» ее в конфигурацию NGINX.
• Создайте запись cronjob, которая в определенный период будет считывать конфигурацию из вышеуказанной службы и вызывать горячую перезагрузку NGINX.
• NGINX, который будет использовать конфигурацию, созданную из службы и cronjob, и будет работать как API-шлюз.