Построение кластера регистрации и обнаружения сервисов на базе Docker + Consul + Registrator

задняя часть Микросервисы сервер Docker

предисловие

В последние годы микросервисная архитектура становится все более популярной в сфере интернет-приложений, внедрение микросервисов в основном решает проблему монолитности приложений.Плотное соединение нескольких модулей,Невозможно масштабироватьиСложность в эксплуатации и обслуживанииИ другие вопросы. Архитектура микросервиса основана наФункциональная гранулярностьПройти бизнес-модульвертикальное разделение, на самом монолитном приложенииОбслуживаниеисоставной, каждый компонент развертывается отдельно какапплет(отDBприбытьUI). между микросервисами и микросервисамиService APIвзаимодействовать, поддерживаяГоризонтальное расширение,повышение производительностиидоступность услуги, одна служба позволяет одновременно развертывать одну или несколькоЭкземпляр службы. Во время выполнения каждый экземпляр обычно являетсяОблачная виртуальная машинаилиDockerконтейнер.

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

текст

1. Обнаружение службы и регистрация

1.1. Конкретный процесс

  • Реестр услуг: В качестве ядра всей архитектуры для поддержкираспределенный,постоянное хранение,Изменения в регистрационной информацииУведомление потребителей в режиме реального времени.
  • поставщики услуг:служба сdocker контейнерныйспособ развертывания (реализациясервисный портизДинамическая генерация), может пройтиdocker-composeспособ управлять. пройти черезRegistratorобнаруженdockerОбработка информации для завершения обслуживанияавтоматическая регистрация.
  • потребители услуг: нужно использоватьпоставщики услугПредоставляемые услуги и поставщики услуг часто динамически перемещаются друг к другу.

Относительно полный процесс регистрации и обнаружения службы выглядит следующим образом:

  1. регистрационная служба: от поставщика услуг к рееструрегистр;
  2. Подписка на сервис: сервисный потребитель для реестраподпискаслужебная информация, для котороймонитор;
  3. Список служб кэширования:местныйтайникСписок сервисов для уменьшения сетевого взаимодействия с реестром;
  4. вызов службы:ПервыйнайтиЛокальный кеш, если не можете найти, идите в центр регистрацииВытащитьадрес службы, а затем отправить запрос на обслуживание;
  5. Уведомление об изменении: сервисный узелизменятьВремя (новый,Удалитьд.), реестр уведомит прослушивающий узел,возобновитьСлужебная информация.

1.2. Связанные компоненты

Система обнаружения сервисов в основном состоит из трех частей:

  1. регистратор: Регистрируйте / нерегистрируйте службу в соответствии со статусом работы службы. Основная проблема, которая должна быть решена, - это то, когда инициировать действие регистрации / периодации.
  2. реестр: Сохранение служебной информации. Распространенными решениями являются zookeeper, etcd, cousul и т. д.
  3. Открытие: Чтение служебной информации из реестра и инкапсуляция интерфейса доступа для пользователя.

1.3. Сторонняя реализация

Для реализации регистрации и обнаружения сторонних сервисов существуют следующие три инструмента:

  1. zookeeper: Высокопроизводительный, распределенный сервис по координации приложений для обслуживания имен, распределенные блокировки, делится ресурсы и синхронизировать распределенную конфигурацию.
  2. Etcd: система хранения пар ключ/значение, использующая протокол HTTP, в основном используется для общей конфигурации и обнаружения сервисов, а предоставляемые функции относительно просты по сравнению с Zookeeper и Consul.
  3. Consul: Распределенное программное обеспечение для обнаружения и обмена конфигурациями с высокой доступностью, которое поддерживает обнаружение и регистрацию служб, несколько центров обработки данных, проверки работоспособности и распределенное хранилище ключей/значений.

Простое сравнение:

В отличие от Zookeeper и etcd, Consul реализует встроенную в него систему обнаружения сервисов, нет необходимости создавать собственную систему или использовать стороннюю систему, клиентам нужно только регистрировать сервисы и выполнять обнаружение сервисов через интерфейсы DNS или HTTP.

2. Консул и регистратор

2.1. Консул введение

Что такое консул

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

  • обнаружение службы:Consulпройти черезDNSилиHTTPинтерфейсРегистрация службы и обнаружение службыСтановится легко. некоторые внешние службы, такие какsaasПредоставленные также могут быть зарегистрированы таким же образом;
  • медицинское обследование: проверка работоспособности включенаconsulОперация в кластере может быть быстро предупреждена. Интеграция с обнаружением служб предотвращает переадресацию служб неисправным службам;
  • хранилище ключей/значений: Один используетсяХранилище динамической конфигурациисистема. обеспечить простойHTTPинтерфейс, можно работать где угодно;
  • Несколько центров обработки данных:служба поддержкиНесколько центров обработки данныхизбегатьединая точка отказаВнутренние и внешние сетевые службы используют разные порты для мониторинга. Однако его развертывание необходимо учитывать задержку сети, фрагментацию и т. Д.zookeeperиetcdНи один из них не поддерживает функции нескольких центров обработки данных;
  • алгоритм консенсуса:использоватьRaftАлгоритм протокола консенсуса, чемPaxosАлгоритмы просты в использовании. использоватьGOSSIPПротокол управляет членством и широковещательными сообщениями, а также поддерживаетACLКонтроль доступа;
  • Панель управления услугами: обеспечитьWeb UIуслуги, зарегистрированные вмониторинг состояния здоровьяAdmin Page.

Несколько концепций Консула

На картинке нижеConsulСхема проектирования архитектуры, предоставленная официальным документом:

Фигура содержит дваConsulдата-центры, каждый дата-центр — этоconsulкластер. В центре обработки данных 1 видно, чтоconsulКластер состоит изNКусокSERVER, плюсMКусокCLIENTсостоит из. будь тоSERVERвсе ещеCLIENT, обаconsulУзел кластера. Все услуги могут быть зарегистрированы на этих узлах, и именно через эти узлы реализуются совместное использование информации о регистрации услуг. В дополнение к этим двум кратко представлены несколько небольших деталей.

  • CLIENT

CLIENTвыражатьconsulизclientрежим, то естьклиентский режим. даconsulРежим узла, в этом режиме все службы, зарегистрированные на текущем узле, будутВпередприбытьSERVERузел, самНе стойкийэти сообщения.

  • SERVER

SERVERвыражатьconsulизserverрежим, указывающий, что этоconsulЯвляетсяserverузел. В этом режиме функции иCLIENTВсе равно, разница только в том, что он берет всю информациюУпорствоместный. Таким образом, в случае сбоя информация может быть сохранена.

  • SERVER-LEADER

среднийSERVERНиже приведеныLEADERОписание, указывающее на этоSERVERНод - их босс. И другиеSERVERРазница в том, что он должен быть ответственнымСинхронизировать регистрационную информациюдать другимSERVER, но и отвечает закаждый узелизМониторинг здоровья.

  • Другая информация

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

2.2. Знакомство с регистратором

Что такое регистратор Registratorне зависит от реестра услугКомпонент автоматической регистрации/отмены регистрации услуг, обычно сDocker containerспособ развертывания.Registratorавтоматически определит, где он находитсяхозяинвсе включеноDockerСостояние контейнера (включить/уничтожить) и в соответствии с состоянием контейнера на соответствующийСписок регистрации службыРегистрация/отмена регистрации услуг.

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

Registratorслужба поддержкиПодключаемыйизсервисный реестрконфигурация, поддерживаемая в настоящее время, включаетConsul, etcdиSkyDNS 2Три инструмента регистрации.

2.3 Докер устанавливает кластер Consul

2.3.1 Планирование узла кластера

Мой местный используетUbuntu16.04Виртуальная машина:

имя контейнера IP-адрес контейнера номер порта карты IP-адрес хоста сервисный режим
node1 172.17.0.2 8500 -> 8500 192.168.127.128 Server Master
node2 172.17.0.3 9500 -> 8500 192.168.127.128 Server
node3 172.17.0.4 10500 -> 8500 192.168.127.128 Server
node4 172.17.0.5 11500 -> 8500 192.168.127.128 Client

2.3.2 Установка кластера Consul

ConsulПараметр конфигурации Информация Описание:

список параметров Значение параметров и описание сценариев использования
advertise Адрес представления уведомления используется для изменения адреса, который мы представляем другим узлам в кластере.В общем, адрес -bind является адресом представления.
bootstrap Он используется для управления тем, находится ли сервер в режиме начальной загрузки.В центре обработки данных только один сервер может находиться в режиме начальной загрузки.Когда сервер находится в режиме начальной загрузки, он может выбрать себя в качестве лидера плота.
bootstrap-expect Ожидаемое количество серверных узлов в центре обработки данных. Если указано это значение, Consul не будет загружать весь кластер до тех пор, пока не будет достигнуто указанное количество серверов. Этот флаг нельзя использовать совместно с начальной загрузкой.
bind Этот адрес используется для связи IP-адресов в кластере, все узлы к адресу в кластере должны быть до 0,0.0,0.
client В котором адрес клиента является обязательным, этот адрес предоставляет такие службы, как HTTP, DNS, RPC, который по умолчанию равен 127.0.0.1.
config-file Явно указать, какой файл конфигурации загрузить
config-dir Каталог файлов конфигурации, все файлы, заканчивающиеся на .json, будут загружены
data-dir Укажите каталог для хранения состояния агента. Этот каталог требуется для всех разрешений агента. Каталог должен быть стабильным и продолжать существовать после перезапуска системы.
dc Этот тег управляет именем центра обработки данных, разрешенным агентом, по умолчанию — dc1.
encrypt Укажите секретный ключ для шифрования consul во время связи. Ключ может быть сгенерирован consul keygen. Узлы в одном кластере должны использовать один и тот же ключ.
join Добавьте IP-адрес уже запущенного агента, и вы можете указать адреса нескольких агентов несколько раз. Если консул не может быть добавлен ни на один указанный адрес, агент не запустится.По умолчанию агент не присоединится ни к одному узлу при запуске.
retry-interval Интервал времени между двумя присоединениями, по умолчанию 30-е годы
retry-max Количество попыток повторить соединение, по умолчанию 0, что означает бесконечное количество попыток.
log-level Уровень информации журнала, отображаемой после запуска агента-консула. По умолчанию это информация, необязательно: трассировка, отладка, информация, предупреждение, ошибка
node Имя узла в кластере должно быть уникальным в кластере, по умолчанию используется имя узла узла.
protocol Версия протокола, используемая консулом
rejoin Заставить консула игнорировать предыдущие отправления и по-прежнему пытаться присоединиться к кластеру после перезапуска
server Определите, чтобы агент работал в режиме сервера, а в каждом кластере был хотя бы один сервер.Рекомендуется, чтобы количество серверов в каждом кластере не превышало 5.
syslog Включите функцию системного журнала, она действует только на linux/osx
pid-file Укажите путь для хранения файла pid, который можно использовать для агента SIGINT/SIGHUP (закрыть/обновить).

2.4. Docker устанавливает кластер Consul

2.4.1. Вытащите официальное изображение консула

madison@ubuntu:~$ docker pull consul:latest

2.4.2 Запустите узел Сервер

бегатьconsulзеркало, началоServer Masterузелnode1:

node1:

madison@ubuntu:~$ docker run -d --name=node1 --restart=always \
             -e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \
             -p 8300:8300 \
             -p 8301:8301 \
             -p 8301:8301/udp \
             -p 8302:8302/udp \
             -p 8302:8302 \
             -p 8400:8400 \
             -p 8500:8500 \
             -p 8600:8600 \
             -h node1 \
             consul agent -server -bind=172.17.0.2 -bootstrap-expect=3 -node=node1 \
             -data-dir=/tmp/data-dir -client 0.0.0.0 -ui

Проверятьnode1log для отслеживания операции:

В настоящее время в кластере нет выборовleaderУзел, продолжайте запускать два другихServerузелnode2иnode3:

node2:

madison@ubuntu:~$ docker run -d --name=node2 --restart=always \
             -e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \
             -p 9300:8300  \
             -p 9301:8301 \
             -p 9301:8301/udp \
             -p 9302:8302/udp \
             -p 9302:8302 \
             -p 9400:8400 \
             -p 9500:8500 \
             -p 9600:8600 \
             -h node2 \
             consul agent -server -bind=172.17.0.3 \
             -join=192.168.127.128 -node-id=$(uuidgen | awk '{print tolower($0)}') \
             -node=node2 \
             -data-dir=/tmp/data-dir -client 0.0.0.0 -ui

Проверятьnode2Журнал запуска процесса узла:

node3:

madison@ubuntu:~$ docker run -d --name=node3 --restart=always \
             -e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \
             -p 10300:8300  \
             -p 10301:8301 \
             -p 10301:8301/udp \
             -p 10302:8302/udp \
             -p 10302:8302 \
             -p 10400:8400 \
             -p 10500:8500 \
             -p 10600:8600 \
             -h node2 \
             consul agent -server -bind=172.17.0.4 \
             -join=192.168.127.128 -node-id=$(uuidgen | awk '{print tolower($0)}') \
             -node=node3 \
             -data-dir=/tmp/data-dir -client 0.0.0.0 -ui

Проверятьnode3Журнал запуска процесса узла:

когда 3ServerКогда узлы запущены и работают нормально, наблюдайтеnode2иnode3Журнал процесса можно найтиnode1избран какleaderузел, а этоДата центризServer Master.

Проверьте еще разnode1Журнал запуска процесса узла:

Журналы наблюдений найденыnode2иnode3успешно присоединилсяnode1в центре обработки данныхdc1. Когда в кластере 3 единицыConsul ServerПри запускеnode1избран какdc1Первичный узел в. Потом,node1Он будет постоянно проверять пульсацию.node2иnode3Сделайте проверку здоровья.

2.4.4. Запустите клиентский узел

node4:

madison@ubuntu:~$ docker run -d --name=node4  --restart=always \
            -e 'CONSUL_LOCAL_CONFIG={"leave_on_terminate": true}' \
            -p 11300:8300 \
            -p 11301:8301 \
            -p 11301:8301/udp \
            -p 11302:8302/udp \
            -p 11302:8302 \
            -p 11400:8400 \
            -p 11500:8500 \
            -p 11600:8600 \
            -h node4 \
            consul agent -bind=172.17.0.5 -retry-join=192.168.127.128  \
            -node-id=$(uuidgen | awk '{print tolower($0)}') \
            -node=node4 -client 0.0.0.0 -ui

Проверятьnode4Журнал запуска процесса узла:

Его можно найти:node4даClientрежим активирован. После завершения запуска поместитеdc1в центре обработки данныхServerрежим запущенного узлаnode1,node2иnode3добавляются кЛокальный список кешсередина.当客户端向node4После инициирования запроса на обнаружение службыnode4пройдетRPCперенаправить запрос наServerОдин из узлов выполняет обработку.

2.4.5 Просмотр состояния кластера

madison@ubuntu:~$ docker exec -t node1 consul members

dc14 узла в дата-центреnode1, node2, node3иnode4Успешно стартовал,Statusуказать свой статус, обаalive.node1, node2, node3отServerрежим запускается, покаnode4отClientзапускается режим.

2.5 Регистратор установки Docker

2.5.1. Получение образа регистратора

madison@ubuntu:~$ docker pull gliderlabs/registrator:latest

2.5.2. Запустите узел Регистратора

madison@ubuntu:~$ docker run -d --name=registrator \
             -v /var/run/docker.sock:/tmp/docker.sock \
             --net=host \
             gliderlabs/registrator -ip="192.168.127.128" consul://192.168.127.128:8500

--net, указанный как хост, указывает на использование режима хоста. -ip используется для указания IP-адреса хоста и коммуникационного адреса, используемого для проверки работоспособности. consul://192.168.127.128:8500: используйте Consul в качестве реестра службы и укажите конкретный адрес связи Consul для регистрации и отмены регистрации службы (Примечание: 8500 — это порт связи HTTP, предоставляемый Consul).

ПроверятьRegistratorЖурнал запуска процесса контейнера:

RegistratorВ процессе запуска выполняются следующие шаги:

  1. Просмотреть лидер Центра данного узла Консул, как реестр услуг;
  2. Синхронизируйте включенные контейнеры текущего хоста и все служебные порты;
  3. Зарегистрируйте адрес/порт сервиса, публикуемый каждым контейнером, в список регистрации сервисов Consul.

2.5.3 Просмотр статуса регистрации Консула

ConsulпредоставилWeb UIвизуализироватьСписок регистрации службы,узел связи,Дата центрихранилище ключей/значенийи т. д., прямой доступ к хосту8500порт.

Список регистрации службы:

NODESустановлен на узлеdc1все в дата-центреConsulузлов, в том числеConsul ServerиClient.

Список узлов связи:

запускатьRegistratorВ будущем все контейнеры на узле регистрируют службу наConsulизSERVICESНа, тест сделан!

Суммировать

единый дата-центризConsulСтроительство кластера завершено! ! ! В следующих главах я объясню, как использоватьRegistratorрегистрация службымаркировка. затем пройтиdockerразвертыватьнесколько экземпляровизWebБазовый контейнерHTTPизRESTful Serviceи на основеTCPизRPC Serviceизрегистрация службыиОпределение проверки работоспособности, и продемонстрируйте, какЭтикеткаИдентифицирует несколько экземпляров службы.

Добро пожаловать в технический публичный аккаунт: Zero One Technology Stack

零壹技术栈

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

Категории