AWS ALB на сервис ECS против нескольких сервисов на ALB для архитектуры микросервисов
Первоначально я думал, что очевидным выбором было несколько служб для каждого слушателя ALB с различными шаблонами пути для надлежащего распределения вызовов API. Хотя с точки зрения проверки работоспособности (если одна из этих служб выйдет из строя), я не знаю разумного способа перенаправить трафик только для этой службы в другой регион.
Если у меня есть активная активная настройка с записями взвешенного маршрута 53, которые при отказе при проверке работоспособности завершатся, я не вижу другого решения, кроме как отключить весь этот трафик ALB и перенаправить его в другой регион, или игнорировать услугу 1 down и продолжить отправку трафика в частично сбойный ALB.
Такое сопоставление ALB с сервисами исправляет это решение, но добавляет дополнительные издержки с точки зрения стоимости и сложности.
Какой шаблон рекомендуется использовать для активной архитектуры активных микросервисов?
1 ответ
Если доступ ко всем службам осуществляется под одним именем хоста, то DNS, конечно, должен указывать на одно и то же место, так что перенаправление в принципе является перспективой "все или ничего".
Тем не менее, есть эффективный обходной путь.
Настройте "секретное" имя хоста для каждой службы. ("Секрет" в том смысле, что клиенту не нужно знать об этом.) Мы назовем эти "конечные точки обслуживания". Назначение этих имен хостов - для маршрутизации запросов к каждой службе... svc1.api.example.com, svc2.api.example.com и т. Д.
Сконфигурируйте каждую из этих записей DNS, чтобы они указывали на основной балансировщик нагрузки или балансировщик нагрузки при сбое, с записями маршрута 53 и проверкой работоспособности маршрута 53, которая специально проверяет эту одну службу на работоспособность на каждом балансировщике.
На данный момент у вас есть имя хоста для каждой службы, которая будет иметь ответ DNS, который правильно указывает на предпочтительную, исправную конечную точку.
То, чего у вас еще нет, - это способ гарантировать, что клиентские запросы будут отправлены в нужное место.
Для этого создайте дистрибутив CloudFront с вашим общедоступным именем хоста API в качестве альтернативного имени домена. Определите один источник CloudFront для каждой из этих конечных точек службы (оставьте поле "Путь источника" пустым), затем создайте поведение кэша для каждой службы с соответствующим шаблоном пути, например /api/svc1* и выберите соответствующий источник. Белый список любых HTTP-заголовков, которые должен видеть ваш API.
Наконец, укажите DNS для вашего основного имени хоста на CloudFront.
Клиенты будут автоматически подключаться к своему ближайшему пограничному местоположению CloudFront, а CloudFront - после сопоставления шаблона пути, чтобы определить, куда отправить запрос - проверит DNS для этой конечной точки, специфичной для данной службы, и направит запрос соответствующему балансировщику.
CloudFront в этом приложении представляет собой не "CDN" как таковой, а скорее глобально распределенный обратный прокси-сервер - логически, это единый пункт назначения для всего вашего трафика, поэтому для основного имени хоста для API не требуется конфигурация отработки отказа... так что больше нет маршрутов "все или ничего". На обратной стороне CloudFront эти имена хостов конечных точек службы гарантируют, что запросы направляются в исправное место назначения на основе проверок работоспособности Route 53. CloudFront учитывает TTL этих записей DNS и не будет кэшировать ответы DNS, которые не должны.