Почему API Gateway рекомендуется для микросервисов?

Question

Для микросервисов обычно используется шаблон проектирования API-Gateway.Я немного запутался по поводу его реализации и последствий.Мои вопросы / проблемы следующие:

1. Почему другие шаблоны для микросервисов вообще не обсуждаются?Если они есть, то я пропустил их?
2. Если мы развернем сервер шлюза, не является ли это узким местом?
3. Разве сервер шлюза не уязвим к сбоям / сбоям из-зачрезмерные запросы в одной точке?Я полагаю, что на данный момент нагрузка будет огромной (и следует учитывать, что Netflix делает что-то подобное).Поправьте меня, если я ошибаюсь в понимании.
4. Поток / загрузка / выгрузка данных (таких как файлы, видео, изображения) также будут проходить через сервер шлюза с другими сервисами промежуточного программного обеспечения?
5. Почему можноРазве мы не используем шаблон прокси вместо шлюза?

Насколько я понимаю, в идеальной среде сервер шлюза будет принимать запросы от клиентов и отвечать обратно после того, как микросервисы выполнят соответствующую задачу.

Кроме того, я смотрел на Spring Cloud Gateway.Кажется, это то, что я ищу на сервере шлюза, но его функциональность смущает меня, если это просто служба маршрутизации (перенаправления) и микросервис будет непосредственно отвечать за ответ клиенту.

Answer 1

В области микросервисов API-шлюз является проверенным шаблоном.Он имеет несколько преимуществ, например:

• Он включает в себя несколько периферийных функций (таких как аутентификация, авторизация, маршрутизация, мониторинг, ...)
• Он скрывает все ваши микросервисы и контролирует доступ ких (я не думаю, что вы хотите, чтобы ваши клиенты могли иметь прямой доступ к вашим микросервисам).
• Он может инкапсулировать протоколы связи, запрошенные вашими микросервисами (иногда служба может иметь внутреннюю смесь протоколовкоторые даже разрешены только в брандмауэре).
• API-шлюз также может предоставлять «композицию API» (согласование вызовов к нескольким сервисам и объединение их результатов с одним).Реализовать такую ​​композицию в микросервисе не рекомендуется.
• и т. Д.

Реализация всех этих функций в прокси-сервере не является тривиальной задачей.Существует пара API-шлюзов, которые предоставляют все эти функции, и, в частности, Netflix-Zuul, Spring-Gateway или Akana Gateway.

Кроме того, чтобы избежать того, что ваш API-шлюз станет узким местом для васможет:

• Масштабировать свой API-шлюз и балансировать его нагрузку (как упомянуто выше Arran_Duff)
• Ваш API-шлюз не должен обеспечивать однократного соответствия-all API для всех ваших клиентов.При этом вы, в случае большого количества запросов (или больших файлов для загрузки / загрузки), наверняка столкнетесь с проблемами, упомянутыми в вопросах 3 и 4. Поэтому, чтобы смягчить такую ​​ситуацию, ваш шлюз, например, может предоставить каждому клиентус конкретным клиентским API (экземпляр API-шлюза обслуживает только определенный тип клиента или сферу деятельности ..).Это именно то, что Netflix сделал, чтобы решить эту проблему (см. https://medium.com/netflix-techblog/embracing-the-differences-inside-the-netflix-api-redesign-15fd8b3dc49d)

Answer 2

Шаблон шлюза используется для предоставления единого интерфейса множеству различных микросервисов.Если у вас есть несколько микросервисов, предоставляющих данные для вашего API, вы не хотите показывать все это своим клиентам.Намного лучше иметь только одну точку входа, не думая о том, какой сервис запрашивать какие данные.Также приятно иметь возможность централизовать общую обработку, такую ​​как аутентификация.Как и любой шаблон проектирования, он может быть очень хорошо применен к некоторым решениям и плохо работает для других.

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

Существуют некоторые тонкие различия между шаблоном прокси и шаблоном шлюза API.Я рекомендую эту статью для довольно простого объяснения https://blog.akana.com/api-proxy-or-gateway/