микросервисы с многорегиональной HA

Question

при использовании микросервисов и микросервисов А хочет общаться с микросервисами В, существует некоторая балансировка нагрузки, поскольку у нас может быть несколько экземпляров B. Это может быть инфраструктура LB (kubernetes) или LB на стороне клиента (eureka + tape).это довольно просто, когда все развернуто в одном регионе и AZ.

что происходит, когда мы хотим достичь многозонного HA и использовать ближайший регион для достижения низкой задержки?

пользовательский запрос должен быть направлен назакрытый регион облачным провайдером?A должен звонить B только в том же AZ?все ли AZ должны быть полностью изолированы, а пользователи должны переключаться между ними?если все службы B в AZ X мертвы, весь AZ X должен быть уничтожен или трафик из службы A в AZ X должен быть направлен в AZ Y?во втором случае облачные провайдеры предлагают такую ​​функциональность?

или, может быть, A должен видеть все B во всех AZ, и он должен вызывать любой из них?в этом случае как насчет задержки, когда запрос отправляется в B, расположенный далеко?

Каковы шаблоны для обработки таких сценариев?

Answer 1

Высокая доступность в пределах региона

Вы правы, что в Регионе может быть несколько зон доступности (AZ), и если вы используете облачного провайдера (AWS / Azure), они будут предоставлять экземпляры в разныхзоны доступности.

Вы должны иметь в виду, что трафик между AZ не передается в общедоступном Интернете, но у облачного провайдера есть собственная выделенная сеть.Облачные провайдеры (AWS / Azure) обычно обеспечивают задержку <2 мс для запроса, передаваемого между AZ, что очень хорошо, учитывая, что у нас высокая доступность.При развертывании кластера kubernetes узлы распределяются по разным AZ.Если какой-либо из AZ или узла не работает, трафик перемещается в другой AZ, что делает его высокодоступным.</p>

Высокая доступность по регионам

Управление доступностью по регионам может быть проблемой.Обычно вы реплицируете одну и ту же вычислительную инфраструктуру (другой кластер Kubernetes) в другом регионе и используете DNS поставщика облачных услуг для приземления пользователя в ближайшем регионе.Это проще для приложений без сохранения состояния.Однако, когда дело доходит до стоимости и базы данных, все становится сложнее.

База данных является очень важным фактором.Если вы используете RDBMS (строгая согласованность), то у вас может быть только один главный узел во всех регионах, но несколько реплик чтения в разных регионах.Поэтому операция записи независимо от того, в какой области она происходит, может идти только на конкретный узел записи и может включать задержку.

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

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

Наличие избыточной инфраструктуры в разных регионах действительно зависит от вашего бизнес-приложения и основных потребностей.