микросервисы внутренней связи через API-шлюз

Question

В микросервисной архитектуре существует общий шаблон, называемый API Gateway.

Я знаю, что вся связь извне шлюза API используется в качестве единой точки входа.

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

Так что же говорит против использования шлюза API также для всей внутренней связи?

Answer 1

При первом подходе (API-шлюз для внутренних и внешних вызовов) есть две проблемы, которые вы можете рассмотреть:

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

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

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

Answer 2

Я попробовал три варианта

1. Все коммуникации через API-шлюз Это облегчает обнаружение услуг, все коммуникации могут быть отслежены в одной точке, но это увеличивает задержку для служб позадишлюз (не очень, но один дополнительный прыжок).Также вы можете лишить аутентификации, и это означает, что все сервисы, даже те, которые находятся за шлюзом, должны получить правильную аутентификацию (это может не быть минусом для некоторых приложений, но для других это вполне может быть)
2. Внешние сервисычерез шлюз Помогает лишить аутентификации на шлюзе.Вы можете принудительно выполнять более строгие проверки на входящий запрос, ваши службы общаются друг с другом напрямую (но это означает, что им нужно как-то узнать службу, мы используем DNS на основе route53, поэтому конечные точки для них остаются неизменными).Сервисы доверяют друг другу, и для этих сообщений авторизация не требуется.
3. Внешние / внутренние шлюзы У нас также был сценарий, когда нам нужно было получить два шлюза API, одной из причин были разные виды провероккоторые требовались для двух наборов шлюзов и различного набора нагрузки, который должен был пройти каждый из них.