Единственная точка отказа на сервисном шлюзе (Netflix Zuul)

Question

Я пытаюсь обратиться за советом по реализации проекта для использования Service Gateway в Microservice Architecture

A, B, C, D, E, F - 6 микросервисов.

Там Есть 2 возможных сценария ios для их взаимодействия

Случай 1: Если я позволю им взаимодействовать между собой самостоятельно

Случай 2: Если я использую сервисный шлюз для их связи

Сервисный шлюз, который планируется использовать, - это Netflix Zuul

Меня беспокоит ЕДИНАЯ ТОЧКА ФАЙЛИУРА на Сервисном шлюзе.

Если мой Сервисный шлюз (Netflix Zuul) выйдет из строя, все микросервисы перестанут взаимодействовать

Хотя, поскольку это теоретически принятая архитектура, я пытаюсь обратиться за советом к моему страху!

Между вариантом 1 по сравнению с вариантом 2, что должно быть предпочтительным для набора из примерно 6 микросервисов?

Answer 1

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

Возьмите первый случай Принимая во внимание, что вам не хватает единой точки безопасности, вы должны обеспечить безопасность на уровне микросервисов (например, OAuth2). Также распространенным шаблоном проектирования, который широко используется для отказов и тайм-аутов, является Hystrix . Вы всегда можете использовать это при реализации первого подхода.

Я думаю, что это может помочь ... !!