Я прочитал эту статью о шаблоне API Gateway. Я понимаю, что шлюзы API обычно служат в качестве обратных прокси , но это создает узкое место. Если все запросы к общедоступным службам приложения проходят через один шлюз или даже один балансировщик нагрузки по нескольким репликам шлюза (возможно, аппаратный балансировщик нагрузки, который может обрабатывать большие объемы полосы пропускания легче, чем шлюз API), то этот единственный узким местом является точка доступа.
Я также понимаю, что это большое узкое место, поскольку оно просто должно доставлять сообщения через прокси-сервер, поскольку сами шлюзы и балансировщики нагрузки не несут ответственности за обработку или запросы. Однако, представляя очень большое приложение со многими пользователями, потребуется чрезвычайно мощное оборудование, чтобы не замечать огромную полосу пропускания, проходящую через шлюз или балансировщик нагрузки, учитывая, что каждый запрос к каждому микросервису, предоставляемому шлюзом, проходит через эту единственную точку доступа.
Если бы шлюз API вместо этого просто перенаправлял клиента на общедоступные микросервисы (что-то вроде пользовательского поиска DNS), требования к оборудованию были бы намного ниже. Это связано с тем, что сообщения, поступающие в и из шлюза API, будут очень маленькими, а запросы состоят только из имени микросервиса и ответов - только из связанного общедоступного IP-адреса.
Я понимаю, что этот шаблон будет включать большую задержку из-за увеличения внешних запросов. Также было бы сложнее обеспечить безопасность, так как каждый микросервис доступен для общественности, а не для аутентификации в одной точке входа. Однако это позволило бы распределить пропускную способность гораздо более равномерно и обеспечить более широкое узкое место, что делает приложение гораздо более масштабируемым. Это действительная стратегия?