Микросервисная архитектура стала необходимой возможностью поддержки проектов для малых и средних предприятий, особенно Интернет-предприятий BATJ, которые стали очень зрелыми в 2004 году и объединили множество крупномасштабных решений по планированию обслуживания и обработке больших наборов данных в крупномасштабной битве основного бизнеса. . В микросервисной архитектуре задействовано множество модулей.В этой статье речь пойдет о продуктах регистрации и обнаружения сервисов микросервисной архитектуры, о том, как сделать обнаружение сервисов на основе DNS.

Регистрация и обнаружение службы

В системе микрослужб регистрация службы и обнаружение службы являются двумя основными модулями. Когда бизнес-служба вызывает службу заказов, ей необходимо найти список IP-адресов и портов службы заказов через модуль обнаружения служб, а экземпляр службы заказов должен зарегистрировать IP-адрес и порт, которые предоставляют службу, в реестре служб. когда он запущен. Типичная структура выглядит следующим образом:

регистрация службы

В настоящее время существует множество популярных реестров, таких как zookeeper, ectd, consul, eureka и др. Обычно существует три типа регистрации службы: самостоятельная регистрация, сторонняя регистрация и активная синхронизация центра регистрации.

• Самостоятельная регистрация:
  • То есть, когда поставщик услуг запускает службу, он отправляет IP-адрес и порт службы в центр регистрации и поддерживает работоспособное состояние посредством сердцебиения, а когда служба отключается, он удаляет соответствующие данные. Типичным примером является использование клиента ZK для публикации микросервисов.
• Регистрация третьей стороны:
  • Сторонняя регистрация означает наличие сторонней системы, отвечающей за добавление или удаление данных службы в реестр при запуске или остановке службы. Типичное использование заключается в том, что система devops или система планирования контейнеров активно настраивают службу регистрации интерфейса центра регистрации;
• Активная синхронизация реестра аналогична стороннему методу регистрации.Метод активной регистрации означает, что реестр подключен к системе планирования или публикации для активной синхронизации последнего списка IP-адресов службы, например, в системе kubernetes, подписывается coredns. к данным сервера API.

обнаружение службы

Прежде чем инициировать вызов службы, вызывающему абоненту необходимо получить список доступных IP-адресов и портов для соответствующей службы из реестра, т. е. выполнить обнаружение службы. Обнаружение служб можно разделить на две категории с точки зрения навязчивости приложений:

• Метод обнаружения службы SDK требует, чтобы вызывающая сторона полагалась на соответствующий SDK и явно вызывала код SDK для реализации вызова службы, что мешает бизнесу. Типичными примерами являются eureka, zookeeper и т. д.

• DNS сама по себе является системой разрешения доменных имен, которая может соответствовать простым сценариям обнаружения служб, таким как согласованные порты, протоколы сериализации и т. д. Однако это далеко не соответствует потребностям реальных сценариев микросервисов.

Обнаружение службы на основе DNS

Протокол DNS является одним из наиболее распространенных протоколов в настоящее время, и почти все операционные системы будут иметь реализацию клиента DNS. Следовательно, он, естественно, имеет межъязыковые характеристики. Это также самый быстрый способ быстрого доступа к системе микросервисов. Чтобы сделать обнаружение службы на основе DNS, прежде всего, данные реестра должны быть представлены через формат данных DNS. Позволяет DNS-клиенту любой системы получать список служб по протоколу DNS.

Примечание:仅仅是服务发现系统提供DNS协议接入

Методы обнаружения служб на основе DNS можно условно разделить на две категории:

Автономный DNS-сервер

Базовая архитектура режима независимого DNS-сервера выглядит следующим образом:

Как показано на рисунке выше, в этой архитектуре требуется отдельный DNS-сервер. DNS-сервер получает список всех зарегистрированных служб и соответствующих IP-портов из реестра. Вызывающая служба A запрашивает список IP-адресов службы через DNS, а затем инициирует вызов.

Преимущества и недостатки этого типа обнаружения службы заключаются в следующем:

• преимущество
  • Централизованный DNS-сервер для простого обновления и обслуживания
• недостаток
  • Высокие требования к производительности DNS-сервера
  • В этом случае обычно требуется, чтобы устройство LVS перенаправляло запросы к кластеру DNS-серверов, у которого есть одна проблемная точка.

DNS Filter

Мы определяем режим DNS-фильтра как интеграцию DNS-сервера с машиной или контейнером, вызывающим службу, как показано на следующем рисунке:

В этом режиме в первую очередь необходимо добиться того, чтобы все DNS-запросы ServiceA перехватывались на локальном DNS-сервере (127.0.0.1:53), а вызов осуществлялся после получения IP-листа сервиса. Поскольку этот метод добавляет DNS-сервер к фактической вызывающей машине, он решает одноточечную проблему режима независимого DNS-сервера, который является полным режимом P2P. Однако, поскольку DNS-сервер должен быть установлен на компьютере приложения, затраты на обслуживание и обновление выше, чем в первом случае.

Практика обнаружения сервисов на основе DNS

Alibaba начала попытки обнаружения сервисов на основе DNS еще в 2014 году, и теперь она сформировала относительно зрелую модель. Али использует VIPServer в качестве центра регистрации и разрабатывает DNS-фильтр, который развертывается в контейнере приложения. В настоящее время DNS-фильтр установлен более чем на 100+ машинах или контейнерах, поддерживая обнаружение почти всех служб REST.

Регистрационный центр VIPServer

VIPServer – это центр регистрации услуг, разработанный группой по загрузке промежуточного программного обеспечения Alibaba. VIPServer поддерживает три режима регистрации услуг одновременно и имеет широкий спектр приложений. Кроме того, VIPServer имеет следующие возможности:

• Активные и пассивные проверки работоспособности VIPServer поддерживает как активные, так и пассивные проверки работоспособности.
  • Активная проверка работоспособности означает, что сервер VIPserver периодически активно отправляет пробные пакеты проверки работоспособности, чтобы определить, может ли поставщик услуг нормально предоставлять услуги.
    • Пользователи могут настроить различные методы проверки работоспособности, настроить порт зонда и URL-адрес зонда (HTTP).
  • Преимущество активного обнаружения заключается в том, что поставщик услуг может быстро интегрироваться в архитектуру микросервиса без внесения каких-либо изменений.
  • Пассивная проверка работоспособности означает, что поставщик услуг активно регистрирует свой собственный IP-адрес, порт, имя службы и другую информацию и поддерживает ее в активном состоянии с помощью такта.
• Несколько стратегий балансировки нагрузки В то же время VIPServer поддерживает несколько стратегий балансировки нагрузки, включая вес, один и тот же компьютерный зал, один и тот же регион, одну и ту же среду и т. д. Это одна из основных систем для удаленных мультиактивных проектов.
• Несколько стратегий защиты от аварийного восстановления VIPServer предлагает различные стратегии защиты от аварийного восстановления, которые могут эффективно снизить влияние аномалий, вызванных человеческим фактором или основной системой (сетью и т. д.). Эти средства защиты от аварийного восстановления включают:
  • Кэш клиента, даже если сервер VIPServer зависнет, это не повлияет на нормальный вызов приложения;
  • Порог защиты на стороне сервера может эффективно предотвратить лавину приложения из-за чрезмерного давления;
  • Каталог аварийного восстановления клиентов, обеспечивающий возможность ручного вмешательства в список IP-адресов службы;
  • Защита пустого списка клиентов, эффективно предотвращающая удаление списка IP-адресов по ошибке или неисправность сервера VIPServer.

DNS-F-клиент

Из соображений производительности мы используем второй режим обнаружения службы DNS Filter. С этой целью мы разработали клиент DNS-F отдельно, который развертывается на том же хосте или в контейнере, что и приложение. Принцип его работы показан на следующем рисунке:

• Во-первых, приложение ServiceA получает список доступных IP-адресов ServiceB через DNS-запрос.
• DNS-F перехватит запрос запроса ServiceA, определит, есть ли у него ответ на запрос, и если да (сервис был зарегистрирован в VIPServer), то напрямую вернет список IP;
• Если запрашиваемая служба не зарегистрирована в VIPServer, DNS-F перенаправляет DNS-запрос на сервер имен системы, который разрешается реальной системой DNS;