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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

Answer 3

1. Почему другие шаблоны для микросервисов обычно не обсуждаются? Если да, то я их пропустил? Существует множество шаблонов микросервисов в разных категориях, таких как базы данных, службы и т. Д. Это очень хорошая статья https://microservices.io/patterns/index.html

2. Если мы развернем сервер шлюза, разве это не узкое место?

Да, в некоторой степени.Q3 отвечает на это изображение.

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

4.Данные потока / загрузки / загрузки (например, файлы, видео, изображения) также будут проходить через сервер шлюза с другими службами промежуточного программного обеспечения? Почему мы не можем использовать шаблон прокси вместо шлюза?

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

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