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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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