Обучение проектированию микросервисов (3) Регистрация сервисов и обнаружение управления сервисами

Java
Обучение проектированию микросервисов (3) Регистрация сервисов и обнаружение управления сервисами

предисловие

Добро пожаловать в предыдущую серию:

Сегодня, с ростом популярности микросервисов, гранулярность сервисов очень тонко разделена, за чем следует быстрый рост количества сервисов. В облачной волне управление услугами часто сочетается с платформой планирования контейнеров, чтобы сформировать единую автоматизированную платформу планирования и управления.

Конечно, независимо от того, используется ли система планирования на основе контейнеров,Принцип и объем управления услугами не изменятся, но реализация другая.

Управление службами в основном включает в себя обнаружение служб, балансировку нагрузки, ограничение тока, автоматический выключатель, тайм-аут, повторные попытки, отслеживание служб и т. д.Сегодня мы поговорим о содержании обнаружения сервисов..

Краткое содержание этой главы

Эта глава в основном представляет следующее содержание:

  1. Что такое обнаружение службы? (какие)
  2. Зачем нам нужно обнаружение сервисов в среде микросервисов? (Зачем)
  3. Как работает обнаружение служб? (как)
  4. Теорема CAP
  5. Внедрение нескольких существующих решений (реализаций)

Теперь давайте начнем это путешествие.

Что такое сервисное обнаружение (что)

Обнаружение услуги относится к поиску информации о сетевом местоположении поставщика услуг.

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

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

Зачем вам сервисное обнаружение? (Зачем)

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

Рассмотрим этот основной вопрос: как потребители услуг узнают IP-адрес и порт поставщика услуг?

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

Но в архитектуре микросервисов это не так.Микросервисы часто обновляются и выпускаются, и часто эластично масштабируются в соответствии с условиями нагрузки., потому что смена сетевого адреса экземпляра микросервисного приложения — вполне нормальное явление, а упомянутое ранее статическое конфигурационное решение явно не подходит для такого случая.Высоко динамичныйместо действия. Итак, нам нужно предоставить механизм (модуль),Разрешить потребителям услуг быстро и своевременно получать последнюю информацию об услугах при изменении IP-адреса поставщика услуг..

Как работает обнаружение служб? (как)

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

Давайте проиллюстрируем, как работает обнаружение сервисов (простая версия) на двух примерах:

image.png

  1. biz serviceНачните, сообщите сервисному центру свою сервисную информацию, и сервисный центр завершит написание
  2. admin serviceНачать, запросить сервисный центрbiz serviceслужебная информация
  3. Сервисный центр находит информацию о местоположении соответствующей службы и возвращает ее вadmin service
  4. admin serviceПосле получения фактического адреса отправьтеbiz serviceобратиться с просьбой

когдаbiz serviceС кластерной архитектурой, когда больше узлов подключается к сети, на что похож весь рабочий процесс?

image.png

  1. Вновь запущенный узел сообщает центру регистрации и обнаружения служб свою собственную служебную информацию, а центр обслуживания завершает запись.

  2. admin serviceИнициировать запрос на обновлениеbiz serviceсписок сервисных адресов для

    Здесь клиентская сторона активно запрашивает обновление информации, что является методом «вытягивания»; есть и другой способ, когда клиентская сторона регистрирует обратный вызов и ждет уведомления от сервисного центра, что является методом «выталкивания»)

Теорема CAP

Хотя весь механизм работы «обнаружения сервисов» очень прост для понимания, в реальном распределенном сценарии, как ядре системы микросервисной архитектуры, нам обязательно нужно построить кластер, чтобы обеспечить его высокую доступность. В это время необходимо рассмотреть некоторые проблемы, с которыми может столкнуться распределенная система.

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

  • последовательность: означает, что все узлы могут одновременно возвращать одну и ту же самую последнюю копию данных;

  • Доступность: означает, что каждый запрос может возвращать ответ без ошибок;

  • Допуск перегородки: Это означает, что даже если связь между серверами не может поддерживаться бесперебойно в течение определенного периода времени, это не повлияет на дальнейшую работу системы.

undefined

Для распределенных систем отказоустойчивость разделов является обязательной. Следовательно, должен быть компромисс между согласованностью и доступностью, который называется «выбрать AP или выбрать CP».

Детская обувь, не знакомая с теоремой CAP, может расширить чтение -Теорема CAP

Для сервисного обнаружения и кластера реестра, если вы выбираете согласованность за счет доступности (выберите CP), то для обеспечения согласованности данных в многоточечном сервисном центре, как только сервисный центр в какой-то момент выходит из строя, сервисный центр кластер должен быть приостановлен внешними службами записи данных. При обеспечении согласованности данных кластера сервисного центра в жертву приносится доступность службы записи. Если выбрать доступность и пожертвовать консистентностью (выбрать AP), то для обеспечения бесперебойного обслуживания, когда сервисный центр в определенный момент выйдет из строя, уцелевший узел сервисного центра может выбрать запись данных сначала в локальное хранилище, а затем напрямую вернуться на сторону клиента, но это приведет к несогласованности данных между несколькими узлами.

Предоставленные отраслью системы обнаружения и регистрации услуг в основном удовлетворяютAPилиCPсистема.

Существующие решения (реализации)

В распределенной системе обслуживания все поставщики услуг и потребители полагаются на [Сервисный центр].Если в сервисном центре возникнут проблемы, возникнут такие явления, как нечувствительность к восприятию статуса услуги, что повлияет на всю систему. Поэтому очень важно гарантировать доступность реестра, используемого для обнаружения служб. Чтобы обеспечить доступность центра регистрации, необходимо обеспечить многоузловое развертывание.Если это крупномасштабный веб-сайт, фон обычно развертывается в нескольких компьютерных залах, чтобы гарантировать, что центр регистрации может по-прежнему предоставлять услуги даже когда один компьютерный зал недоступен. Сервисный центр с высокой доступностью должен иметь следующие возможности:

  1. Возможность многоузлового развертывания
  2. Способность к самовосстановлению и настройке в распределенных сценариях
  3. Возможность проверки работоспособности узла может удалить узел, время доступа которого истекло, из текущего кластера или повторно присоединиться к текущему кластеру после того, как узел восстановил возможность доступа.

В следующих разделах мы представим несколько распространенных продуктов, которые могут непосредственно выступать в качестве реестра.

Zookeeper

Zookeeper стремится предоставить высокодоступную распределенную систему координации со строгими возможностями последовательного контроля доступа, и это решение для согласованности распределенных данных.

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

undefined

В этой статье специально не рассказывается о протоколе согласованности Zookeeper, структуре данных и т. д. Если вам интересно, вы можете прочитать предыдущие статьи автора Zookeeper.

Zookeeper Learning Series [1] Научит вас некоторым основным понятиям Zookeeper. Серия обучения Zookeeper [3] Архитектура кластера Zookeeper, механизм чтения и записи и принцип согласованности (протокол ZAB)

Механизм чтения-записи Zookeeper и протокол согласованности определяют, что это система CP.

Сильные и слабые стороны

Как наиболее широко используемый распределенный компонент координации, ZooKeeper имеет много преимуществ. Его широкое использование является его самым большим преимуществом, что также упрощает использование ZooKeeper, когда архитекторы выбирают технологии. Однако необходимо четко заявить, что Zookeeper — не лучший выбор в области обнаружения сервисов, его преимущества в основном отражаются в сценариях с сильной распределенной согласованностью, таких как выборы и распределенные блокировки. Когда главный узел ZooKeeper теряет связь с другими узлами из-за сбоя в сети и инициирует выбор всей системы, кластер становится недоступным, что приводит к параличу системы службы регистрации во время выборов.

дальнейшее чтениеПочему Alibaba не использует ZooKeeper для обнаружения сервисов?

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

etcd

Поскольку такие проекты, как CoreOS и Kubernetes, становятся все более и более популярными в сообществе открытого исходного кода, компоненты etcd, используемые в их проектах, постепенно вошли в поле зрения разработчиков как высокодоступный и строго согласованный репозиторий обнаружения сервисов.

image.png

etcd — проект, вдохновленный Zookeeper,и имеют аналогичную архитектуру и функциональность, основанный на более простом и легком для понимания протоколе Raft и реализации языка go. etcd также является системой CP, и требования к согласованности более строгие, чем требования к доступности. etcd использует TTL (время жизни, время жизни) для достижения функции, аналогичной временному узлу Zookeeper, который требует, чтобы клиент etcd постоянно продлевал аренду узла, чтобы определить текущий статус службы.

Для получения подробной информации, пожалуйста, прочитайте расширенную статью ниже.

дальнейшее чтениеetcd: всесторонняя интерпретация от сценариев применения до принципов реализации

Официальный сайт:etcd.io/

Представляем еще одну качественную статью с интерпретацией принципов реализации etcd:Принцип реализации высокодоступного распределенного хранилища etcd

По сравнению с Zookeeper, etcd также имеет следующие преимущества:

  1. Простой. Написано на GoПростота развертывания; использовать HTTP в качестве интерфейсаПростой в использовании; используйте алгоритм Raft, чтобы обеспечить строгую согласованность и сделать его понятным для пользователей..
  2. сохранение данных. etcd по умолчанию сохраняет данные, как только они обновляются.
  3. Безопасность. etcd поддерживает аутентификацию безопасности клиента SSL.

Eureka

Eureka имеет открытый исходный код от Netflix и в основном используется для поиска сервисов среднего уровня в домене AWS. Eureka привлекла большое внимание, поскольку она используется в качестве реестра для Spring Cloud. Eureka состоит из двух компонентов: сервера и клиента. Сервер Eureka обычно используется в качестве сервера регистрации службы, а клиент Eureka используется для упрощения взаимодействия с сервером и обеспечения поддержки аварийного переключения службы в качестве циклического балансировщика нагрузки.

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

undefined

Хотя Eureka 2.X объявила, что больше не будет поддерживаться, ее текущие функции очень стабильны.Даже если она не обновлена, функций регистрации/обнаружения службы достаточно.

Consul

Consul основан на продуктах HashiCorp и предоставляет ряд функций, в том числеОбнаружение служб, расширенные проверки работоспособности (детальные возможности определения состояния служб, такие как память, использование диска и т. д.), возможности хранения пар «ключ-значение» и несколько центров обработки данных(Четыре основные функции описаны на официальном сайте). По сравнению с другими программами она имеет характеристики «одного окна».

image.png

Консул написан на языке Go, поэтому естественно переносим (поддерживает Linux, Windows и Mac OS X), установочный пакет содержит всего один исполняемый файл, что удобно для развертывания и без проблем работает с легковесными контейнерами, такими как Docker.

Как и etcd, Consul основан на протоколе raft, который требует, чтобы более половины узлов были успешно записаны до успешной регистрации.Когда Лидер вешает трубку, весь Консул недоступен во время перевыборов. Сильная согласованность гарантируется за счет доступности.

У самого автора не так много исследований Consul, и заинтересованные читатели могут обратиться к соответствующим документам для изучения.

Официальный сайт:www.consul.io/

Nacos

Nacos — это новый проект Alibaba с открытым исходным кодом в Китае, и его основное позиционирование — «динамическая платформа для обнаружения, настройки и управления услугами, которая упрощает создание облачных приложений». (Распространенное понимание: центр регистрации + центр конфигурации)

image.png

Сервисы — первоклассные граждане мира Nacos. Nacos поддерживает обнаружение, настройку и управление почти всеми основными типами «сервисов»:

  • Kubernetes Service

  • gRPC & Dubbo RPC Service

  • Spring Cloud RESTful Service

Ключевые особенности Nacos включают в себя:

  • Обнаружение служб и мониторинг работоспособности служб
  • Служба динамической настройки
  • Служба динамического DNS
  • Службы и управление их метаданными

Для получения дополнительной информации, пожалуйста, прочитайте официальную документацию Nacos:

дальнейшее чтениечто cos.IO/this-capable/docs/…

резюме

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

Увидимся в следующий раз.

Справочная статья

  1. Service Discovery in a Microservices Architecture
  2. Microservices: Service Registration and Discovery
  3. Service Discovery
  4. nacos.io/zh-cn/
  5. etcd: всесторонняя интерпретация от сценариев применения до принципов реализации
  6. «От сервиса к облаку»
  7. «Микросервисный дизайн»

Если эта статья была вам полезна, я надеюсь, что вы можете поставить лайк, это самая большая мотивация для меня.

Категории