Что такое Service Discovery в микросервисах

Что такое Service Discovery? Зачем это нужно?

В ранние дни Интернета людям приходилось вводить длинные строки IP-адресов для доступа к онлайн-сервисам. IP-адреса не были длинными, но как бессмысленная строка чисел, запомнить конкретный адрес определенного сервиса было сложно, что привело к изобретению системы доменных имен. Каждый онлайн-сервис регистрировал доменное имя у провайдера доменных имен, а затем устанавливал связь между доменным именем и конкретным IP через DNS (Domain Name System). Таким образом, люди могли просто ввести запоминающееся доменное имя и получить доступ к онлайн-сервису по конкретному IP, что стало самой ранней формой Service Discovery.

Когда количество сервисов внутри компании достигает определенного размера (например, разделение на микросервисы), возникает проблема, что IP-адреса действительно сложно запомнить, для чего и нужна система Service Discovery. Сервисы внутри компании регистрируются в системе, а другие сервисы, которые хотят получить к ним доступ, ищут соответствующий IP-адрес в системе, так что сервису не нужно "запоминать" сложный и изменчивый IP-адрес.

Изменения IP-адресов могут сбить с толку посетителей.

Введение DNS как механизма Service Discovery позволяет гибко обрабатывать изменения IP.

Введение в распространенные системы Service Discovery

Как система Service Discovery, она должна удовлетворять как минимум четырем функциям:

1. API для регистрации
2. API для запросов
3. Высокая доступность: в конце концов, система Service Discovery является нервом всей системы и не может быть парализована или выйти из строя
4. Экосистема: как известно, программисты ленивы и предпочли бы иметь библиотеку, которая может легко взаимодействовать с API

Давайте рассмотрим несколько основных открытых систем Service Discovery на рынке:

Consul

Consul — это система Service Discovery, разработанная компанией Hashicorp, ведущей в области открытого ПО. Как давно существующее программное обеспечение, выпустившее свою первую версию 17 апреля 2014 года, Consul имеет одну из самых богатых экосистем и даже имеет сторонних разработчиков, которые разрабатывают SDK для Haskell. Большинство SDK Consul — это просто обертки для его HTTP API, поэтому разработка не требует больших усилий.

Consul поддерживает регистрацию и запросы сервисов через HTTP API. Он поддерживает HTTP long polling для своевременной передачи данных при запросах, чтобы избежать опроса. Также Consul поддерживает запрос экземпляра соответствующего сервиса через DNS.

Развертывание Consul интересно тем, что каждый экземпляр Consul называется агентом, который может быть как клиентом, так и сервером. На стороне клиента Consul поддерживает состояние на стороне клиента; на стороне сервера Consul поддерживает распределенное развертывание через алгоритм консенсуса Raft для достижения высокой доступности.

Eureka

Eureka — это проект, открытый Netflix, который также довольно старый (есть следы коммитов, датируемых 2012 годом). Однако проект не поддерживался в течение года. Многие пользователи перешли на Nacos, о котором будет упомянуто ниже.

Eureka поддерживает взаимодействие через HTTP API и Java SDK. Многие пользователи Eureka были привлечены через проекты в экосистеме Java, такие как Spring Cloud. Высокодоступный дизайн Eureka, если описывать его в терминах CAP (теорема CAP утверждает, что распределенная система может одновременно обеспечивать только два из трех свойств: Согласованность, Доступность и Устойчивость к разделению), является AP, что позволяет клиентам видеть устаревшие данные при разделении сети, избегая вторичных катастроф из-за сетевых проблем.

Nacos

Nacos — это система Service Discovery, разработанная Alibaba, название которой происходит от объединения первых букв Naming и Configuration Service. С момента выпуска версии 0.1.0 20 июля 2018 года, Nacos теперь развился до версии 2.1.

Как и многие открытые проекты Alibaba, Nacos довольно популярен среди Java-разработчиков в Китае, и его популярность даже значительно выше, чем у Eureka.

Он поддерживает регистрацию и запросы сервисов через HTTP API и SDK, такие как Java/Go/Python/NodeJS/C#. В настоящее время разработчики Nacos также работают над новыми API на основе gRPC. Для HTTP API Nacos в настоящее время поддерживает только опрос списка сервисов. Поэтому Nacos официально предпочитает подход SDK, который представляет собой опрос + push на основе UDP с лучшей производительностью в реальном времени. Nacos также работает над новыми API на основе gRPC, которые введут возможности push на стороне сервера, что будет большим преимуществом для тех систем, которые не имеют доступа к SDK.

Высокая доступность Nacos частично обусловлена возможностями сохранения состояния, предоставляемыми в клиентском SDK, и частично согласованностью серверной стороны через протоколы Raft и Distro.

Распространенные методы взаимодействия и их преимущества и недостатки

Оставляя в стороне частные протоколы, методы взаимодействия Service Discovery можно разделить на три категории:

1. HTTP опрос
2. DNS
3. HTTP long polling или gRPC server streaming

HTTP опрос прост в реализации, но не является реальным временем.

Производительность DNS минимальна. DNS также не является реальным временем из-за кэша DNS, и имеет преимущество в виде широко принятого, независимого от реализации набора стандартов. Однако у медали две стороны, что означает, что система Service Discovery не может добавлять дополнительные поля в ответ DNS, если только не используется поле Additional в ответе DNS, но это потребует специальной обработки со стороны клиента.

HTTP long polling или gRPC server streaming являются наиболее реальным временем из трех. Поскольку они оба основаны на HTTP, ответ может быть легко настроен. Недостатком является то, что они относительно сложны в реализации на стороне клиента.

Как APISIX взаимодействует с системами Service Discovery

Как облачный шлюз, APISIX поддерживает получение узлов вышестоящего уровня из системы Service Discovery и разработан для поддержки взаимодействия с системой Service Discovery как на плоскости данных, так и на плоскости управления.

Плоскость данных

APISIX поддерживает интеграцию с DNS, Eureka, Consul (режим KV), Nacos и K8s на плоскости данных.

При взаимодействии с DNS-сервисами APISIX будет использовать записи SRV или A/AAAA DNS для получения конкретного узла вышестоящего уровня сервиса. Когда делается запрос на доступ к вышестоящему уровню, он сначала попытается получить его из кэша DNS. Если нет, он инициирует DNS-запрос для получения конкретного IP-адреса внутри соответствующей записи.

Что касается других типов Service Discovery, они синхронизируются в фоновом режиме. Когда делается запрос на доступ к вышестоящему уровню, часть данных, соответствующая имени сервиса, извлекается из текущих синхронизированных данных. Для K8s и Consul KV мы можем получить измененный IP-адрес в реальном времени таким образом, так как они поддерживают HTTP long polling. Для Eureka и Nacos мы в настоящее время только опрашиваем данные.

Плоскость управления

APISIX также поддерживает Service Discovery на плоскости управления. Мы работаем над apisix-seed, который будет синхронизировать данные из системы Service Discovery в etcd, чтобы плоскость данных могла синхронизировать последние узлы вышестоящего уровня из etcd.

Мы уже реализовали поддержку Nacos и Zookeeper на плоскости управления. Поскольку поддержка Service Discovery на плоскости управления реализована через официальный SDK, она имеет преимущества, недоступные при обычном HTTP-методе. Например, в реализации Nacos в apisix-seed мы поддерживаем push на основе UDP, поэтому данные более эффективны по времени, чем HTTP опрос.

Преимущества поддержки APISIX сценариев Service Discovery

Интегрируя Service Discovery непосредственно на шлюзе, можно значительно упростить работу по выводу сервисов в онлайн. Настройте APISIX для взаимодействия с вашей системой Service Discovery, а затем позвольте APISIX сделать все остальное за вас. Например, если ваша компания использует Nacos как систему Service Discovery, все, что вам нужно сделать, это настроить APISIX для включения Service Discovery Nacos, а затем просто настроить имя сервиса вышестоящего уровня в APISIX, и APISIX автоматически получит конкретный IP-узел, соответствующий этому вышестоящему уровню.

Это преимущество, которое может значительно сократить объем работы, необходимой при миграции шлюза, например, с Spring Cloud Gateway на APISIX. Если Spring Cloud Gateway используется для применения Eureka или Nacos для Service Discovery, переход на новую систему может быть выполнен просто включением поддержки Eureka или Nacos в APISIX.

Huan Bei Loan имеет большой опыт в этой области, и замена Spring Cloud Gateway предназначена для дальнейшего улучшения стабильности, контроля, точности и эффективности.

Цитируя оригинальный текст Huan Bei Loan:

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

Кроме того, APISIX поддерживает одновременную настройку нескольких систем Service Discovery. Многие компании, по историческим причинам, могут иметь несколько систем Service Discovery. Например, насколько я знаю, некоторые компании будут иметь как старую систему Service Discovery Eureka, так и новую систему Service Discovery Nacos. APISIX просто нужно включить как Eureka, так и Nacos, чтобы справиться с этой ситуацией.

Если вы в настоящее время настраиваете узлы вышестоящего уровня непосредственно на APISIX, вы также можете рассмотреть возможность развертывания отдельной системы Service Discovery и хранения конкретной конфигурации узлов в системе Service Discovery. Преимущество перемещения конфигурации узлов вышестоящего уровня из APISIX в отдельную систему Service Discovery заключается в том, что клиент может сам выполнить регистрацию сервиса, а отдельная система Service Discovery часто предоставляет дополнительные функции, такие как более богатые проверки здоровья.

В будущем мы также будем поддерживать интеграцию различных компонентов регистрации и обнаружения сервисов на APISIX Ingress Controller, чтобы упростить использование для пользователей. В то время пользователи смогут не только указывать конечные точки сервиса K8s как узлы вышестоящего уровня на APISIX Ingress Controller, но и интегрировать узлы, полученные через Service Discovery.