Как упоминалось в предыдущей статье, компонент обнаружения и регистрации распределенных служб, используемый в проекте, является консулом.В этой статье в основном обсуждается применение компонентов консула в проекте и соответствующие введения. В этой статье в качестве основного источника используются официальные документы.консульская документация.
1. Знакомство с консулом
Consul — это программное обеспечение для управления услугами со следующими основными функциями:
- Поддерживает распределенную высокую доступность, обнаружение сервисов и совместное использование конфигурации в нескольких центрах обработки данных.
- Consul поддерживает проверки работоспособности и позволяет хранить пары ключ-значение.
- Согласованное принятие протокола
Raft
Алгоритмы используются для обеспечения высокой доступности услуг. - Управление членством и принятие широковещательных сообщений
GOSSIP
протокол, поддерживающий управление доступом ACL.
1.1 Регистрация и обнаружение службы
Регистрация службы — это процесс, в котором служба регистрирует информацию о своем местоположении в «центральном узле регистрации». Служба обычно регистрирует IP-адрес своего хоста и номер порта, а иногда также имеет информацию об аутентификации для доступа к службе, используемый протокол, номер версии и некоторые сведения о среде.
Обнаружение служб позволяет приложению или компоненту обнаруживать свою операционную среду и информацию о других приложениях или компонентах. Пользователь настраивает инструмент обнаружения служб, чтобы отделить фактический контейнер от работающей конфигурации. Общая информация о конфигурации включает в себя: IP-адрес, номер порта, имя и т. д.
Традиционно, когда служба существует на нескольких хост-узлах, для регистрации информации о службе используется метод статической конфигурации.
Когда сложная система требует высокой масштабируемости, а службы часто заменяются, динамическая регистрация и обнаружение служб важны, чтобы избежать перерывов в обслуживании.
Существует множество компонентов для регистрации и обнаружения сервисов, таких как Zookeeper, Etcd и т. д. Может использоваться для координации между сервисами и регистрации сервисов одновременно.
1.2 Consensus Protocol - Raft
Consul использует протокол Consensus Raft для обеспечения согласованности (Consistency). Эта статья является лишь кратким введением в консульство, а специальную статью напишу позже.
алгоритм плота
Во-первых, Raft — это алгоритм консенсуса на основе Paxos. По сравнению с Paxos, Raft разработан с меньшим количеством состояний и представляет собой более простой и понятный алгоритм.
Только серверный узел участвует в Raft и является членом набора пиров. Все клиентские узлы просто пересылают запросы на сервер. Соображение в этой схеме заключается в том, что по мере того, как к группе одноранговых узлов присоединяется больше участников, размер кворума также будет увеличиваться. Что может вызвать проблемы с производительностью, так это ожидание кворума записей журнала узла.
При запуске Консула один узел консула должен работать в режиме начальной загрузки, который запускает самовыбор в качестве лидера. После выбора лидера другие серверы могут добавлять пиры.
В наборе соблюдайте последовательность и безопасность. Со временем в кластер добавляются несколько серверов, и режим начальной загрузки необходимо отключить.
Поскольку все серверы являются членами набора одноранговых узлов, все они знают, кто является лидером. Когда запрос RPC поступает на узел, не являющийся ведущим сервером, запрос будет переадресован ведущему. Если RPC является типом запроса, что означает, что он доступен только для чтения, лидер сгенерирует соответствующий результат на основе текущего FSM.Если RPC является типом транзакции, то есть модифицирует состояние, лидер сгенерирует новый запись журнала на основе алгоритма Raft для управления. Как только записи журнала применяются к конечному автомату, транзакция завершается.
Из-за характера репликации Raft производительность очень чувствительна к сетевой задержке. С этой целью каждый центр обработки данных выбирает независимого лидера и поддерживает несвязанный набор одноранговых узлов. Данные разделены по центрам обработки данных, поэтому каждый руководитель отвечает только за данные в соответствующем центре обработки данных. Когда поступает запрос из удаленного центра обработки данных, запрос перенаправляется соответствующему Лидеру. Этот дизайн обеспечивает транзакции с меньшей задержкой и более высокую доступность без ущерба для согласованности.
Хотя все операции записи реплик журнала основаны на Raft, операции чтения являются более гибкими. Но для поддержки различных компромиссов, которые могут понадобиться разработчикам, Consul поддерживает 3 различных режима согласованности.
- По умолчанию Raft использует модель аренды лидера, которая предоставляет временное окно, в течение которого роль лидера остается стабильной.
- последовательная, безусловная согласованность
- stale, этот режим позволяет выполнять операции чтения на любом узле сервера, независимо от того, является ли он ведущим или нет.
1.3 Group Membership Protocol - Gossip
Consul использует протокол сплетен для управления членством и рассылки сообщений всему кластеру. Для получения подробной информации см.Serf library.
Консул использует два разных пула сплетен. Локальная сеть (LAN Pool) и глобальная сеть (WAN Pool).
В каждом центре обработки данных Consul есть пул сплетен в локальной сети, в который входят все участники (сервер и клиент). LAN Pool имеет следующие цели:
- Во-первых, членство позволяет клиентам автоматически обнаруживать серверные узлы, уменьшая объем необходимой настройки.
- Во-вторых, распределенное обнаружение отказов позволяет выполнять работу по обнаружению отказов в нескольких точках сервера, а не централизованно на всех узлах всего кластера.
- Наконец, сплетни позволяют надежно и быстро транслировать такие события, как выборы лидеров.
Пул WAN глобально уникален, независимо от того, к какому центру обработки данных он принадлежит, все серверы должны быть добавлены в пул WAN. Информация о членстве, предоставляемая пулом WAN, позволяет серверу выполнять запросы между центрами обработки данных с энергосбережением. Интегрированное обнаружение сбоев позволяет Consul корректно справляться с потерей подключения во всем центре обработки данных или только на одном узле сервера в удаленном центре обработки данных.
Все эти функции обеспечиваются использованием Serf. С точки зрения пользователя, он предоставляет эти функции в виде встроенной библиотеки. Но он заблокирован Консулом, и пользователям все равно. Как разработчик, вы можете понять, как используется эта библиотека.
1.4 Сеанс сеанса
предыдущий постГенерация глобального идентификатора версии обновления SnowflakeИспользуется хранилище КВ консула.
Consul предоставляет механизм сеанса сеанса, который можно использовать для создания распределенных блокировок. Сеансы могут быть привязаны к узлам, проверкам работоспособности, данным KV, чтобы обеспечить точную блокировку.
Интеграция хранилища KV и сессий — основной сценарий использования сессий. Сеанс должен быть создан перед использованием, а затем используется его идентификатор. KV API поддерживает операции получения и освобождения.Операция получения похожа на операцию CAS и возвращает успех только тогда, когда блокировка свободна. В случае успеха будет обновлен обычный идентификатор, также будет увеличен LockIndex и, конечно же, будет обновлена информация о сеансе.
Если во время операции получения блокировка, связанная с сеансом, уже удерживается, то LockIndex не будет увеличиваться, но значение ключа будет обновлено, что позволит текущему владельцу блокировки обновить содержимое ключа. без повторного получения блокировки.
Как только блокировка получена, ее необходимо снять с помощью операции освобождения (используя тот же сеанс). Операция Release также аналогична операции CAS. Если данный сеанс недействителен, запрос завершится ошибкой. Важно отметить, что блокировку также можно снять, минуя создателя сеанса. Этот дизайн позволяет вмешаться оператору, чтобы завершить сеанс, когда это необходимо. Как упоминалось выше, аннулирование сеанса также приведет к снятию или удалению всех удерживаемых блокировок. Когда блокировка снимается, LockIndex не изменяется, но сеанс очищается, а ModifyIndex увеличивается. Эта семантика позволяет использовать кортежи (Key, LockIndex, Session) как уникальную «последовательность». Эта последовательность может быть передана и использована для проверки того, что запрос принадлежит текущему держателю блокировки. потому что каждый приобретает
приведет к увеличению LockIndex, даже если блокировка будет повторно получена в том же сеансе, последовательность способна обнаруживать устаревшие запросы. Аналогичным образом, если сеанс признан недействительным, соответствующий LockIndex будет пустым.
Чтобы было ясно, эта система блокировки носит исключительно рекомендательный характер. Не обязательно, чтобы клиент получил блокировку, прежде чем он сможет выполнить операцию. Любой клиент может читать, записывать и удалять ключевые операции без получения блокировки. Это не то, что Консул использует для защиты системы.
2. Консул Архитектура
Технический инсайд консула представлен выше. Теперь поговорим об архитектуре консула.
consul
Разберите эту систему и начните разбираться с каждого компонента. Во-первых, вы можете видеть, что есть два центра обработки данных, помеченные как «один» и «два». Consul является первоклассным решением для поддержки нескольких центров обработки данных и является распространенным бизнес-сценарием.
Каждый центр обработки данных состоит из серверов и клиентов. Рекомендуется иметь от 3 до 5 серверов в зависимости от баланса обработки сбоев и производительности. Консенсус становится все медленнее и медленнее, если вы добавляете больше машин. Количество клиентов не ограничено, и их можно легко масштабировать до тысяч или десятков тысяч.
Все узлы в одном центре обработки данных должны присоединиться к протоколу Gossip. Это означает, что пул сплетен содержит все узлы в данном центре обработки данных. Это служит следующим целям: Во-первых, нет необходимости настраивать параметр адреса сервера для клиента, обнаружение выполняется автоматически. Во-вторых, работа по обнаружению отказов узлов не размещается на сервере, а распределяется. Это делает обнаружение сбоев более масштабируемым, чем механизм сердцебиения. В-третьих, его можно использовать в качестве уровня сообщений для уведомления о важных событиях, таких как выборы лидера.
Серверы в каждом центре обработки данных принадлежат узлу Raft. Это означает, что они работают вместе, чтобы выбрать лидера, а на сервере-лидере есть дополнительные обязанности. Отвечает за обработку всех запросов и транзакций. Транзакции также должны быть реплицированы для всех партнеров по протоколу консенсуса. В связи с этим требованием, когда сервер, не являющийся ведущим, получает запрос RPC, он будет перенаправлен лидеру кластера.
Серверные узлы также являются частью пула сплетен WAN. Этот пул отличается от пула сплетен в локальной сети, он оптимизирован для сетевых ответов с более высокой задержкой и может включать в себя другие серверные узлы кластера consul. Цель разработки WANpool — позволить центрам обработки данных обнаруживать друг друга с минимальным вмешательством. Добавить новый центр обработки данных к существующей сети WAN Gossip несложно. Поскольку все серверы в пуле являются управляемыми, это также создает требования для нескольких центров обработки данных. Когда Serfer получает запрос из другого центра обработки данных, он перенаправляет запрос на любой сервер в соответствующем центре обработки данных. Затем сервер, получивший запрос, может перенаправить его Лидеру.
Существует низкая связь между несколькими центрами обработки данных, но для всех центров обработки данных требуются быстрые и надежные ответы из-за обнаружения сбоев и мультиплексирования кэша соединений.
3. Развертывание Консула
3.1 установка докера
docker
Установка очень простая.Автор основан на конфигурационном файле docker-compose.Вам нужно только установить docker и docker-compose локально.docker-compose.yml выглядит следующим образом:
version: '3'
services:
consul:
image: consul
ports:
- "8500:8500"
- "8600:8600"
- "8300:8300"
Загрузите последний образ из консула, выполните сопоставление портов и откройте внешние порты 8500 и 8300.
3.2 Установка программного обеспечения
- Скачать консул установочный пакет криминала с официального сайта,woohoo.consul.IO/downloads.Также…
- Разархивируйте consul_0.6.4_darwin_amd64.zip.
- Скопируйте распакованный бинарный файл consul в /usr/local/bin.
- Напишите файл конфигурации.
Файл конфигурации для регистрации службы выглядит следующим образом:
{
"service": {
"name": "redis",
"tags": ["master"],
"address": "1192.168.1.100",
"port": 8000,
"enableTagOverride": false,
"check": {
"id": "redis",
"name": "redis on port 8000",
"tcp": "localhost:8000",
"interval": "10s",
"timeout": "1s"
}
}
}
Приведенная выше конфигурация регистрирует порт 8000 Redis с проверкой работоспособности tcp.
Конфигурационный файл узла:
{
"datacenter": "east-cn",
"data_dir": "/opt/consul",
"log_level": "INFO",
"node_name": "redis",
"server": true,
"addresses": {
"https": "192.168.1.100"
},
"ports": {
"https": 0
},
"ui": true,
"retry-join": [
]
}
При загрузке параметров конфигурации consul загружается из всех файлов конфигурации или каталогов в лексикографическом порядке. Например,a.json
будет предшествоватьe.json
иметь дело с. Параметры конфигурации, заданные позже, будут объединены с предыдущим набором конфигураций, а при наличии повторяющихся параметров конфигурации они будут перезаписаны. Конечно, в некоторых случаях, таких как обработчики событий, последние обработчики добавляются к существующим параметрам конфигурации, формируя список обработчиков событий.
3.3 Запуск
Конкретную документацию по запуску см.configuration.
как:
consul agent -server -config-dir /etc/consul.d -bind=192.168.1.100
-config-dir /etc/consul.d
-
config-dir
Каталог загружаемого файла конфигурации, consul загрузит все файлы с суффиксом ".json" в каталоге, порядок загрузки - в алфавитном порядке, а параметры конфигурации в файле объединены как файл конфигурации. Этот параметр можно настроить несколько раз. Подкаталоги внутри каталога не загружаются. -
data-dir
В этом каталоге хранятся данные о состоянии агента. Требуется для всех Агентов.Данный каталог должен храниться в постоянном хранилище (перезагрузка не будет потеряна.Критичен для Агента в роли сервера и необходим для записи состояния кластера. И в каталоге включена блокировка файлов. -
server
Укажите, находится ли агент в режиме сервера или в режиме клиента. Консул агент имеет два режима работы: Сервер и Клиент. Сервер и Клиент здесь отличаются только на уровне кластера Consul и не имеют ничего общего со службами приложений, построенными на кластере. Узел агента режима Consule Server используется для поддержания состояния кластера Consul с помощью алгоритма raft.Официально рекомендуется, чтобы в каждом кластере Consul было не менее трех или более агентов, работающих в режиме сервера, а количество узлов Client не ограничено. .
Другими часто используемыми являются:
-
client
Адрес, который будет привязан к клиентскому интерфейсу, который может быть сервером HTTP, DNS или RPC. По умолчанию «127.0.0.1», что разрешает только петлевые соединения. Адрес RPC будет использоваться другими командами консула, такими как члены консула, для запроса списка агентов. -
node
Имя узла в кластере, которое должно быть уникальным в кластере. По умолчанию используется имя хоста узла. -
bootstrap
Устанавливает, находится ли служба в режиме начальной загрузки. Если в центре обработки данных есть только один агент сервера, этот параметр необходимо установить. Технически сервер в режиме начальной загрузки может выбрать себя в качестве лидера плота. В консул-кластере только один узел может настраивать этот параметр, если есть несколько параметров для настройки этого параметра, трудно обеспечить согласованность. -
bind
IP-адрес, используемый для связи внутри кластера, который может быть связан с другими узлами в кластере. По умолчанию «0.0.0.0», и консул будет использовать первый действительный частный IPv4-адрес. Если указано "[::]", консул будет использовать первый действующий публичный IPv6-адрес. Связь с использованием TCP и UDP. Обратите внимание на брандмауэр, чтобы избежать невозможности связи.
3.4 Результаты
при открытии"ui": true
На узле сервера, напримерhttp://192.168.1.100:8500/ui для просмотра услуг регистрационного центра.
Демонстрационный пользовательский интерфейс выглядит следующим образом:
consul demo UI
4. Резюме
В этой статье представлена некоторая внутренняя информация о консуле и конфигурации консула, а также показаны некоторые фактические конфигурации в проекте. Я надеюсь, что это может помочь вам понять знания, связанные с консулом, и узнать о вводной конфигурации консула и практических приложениях. Лично я считаю, что принцип работы консула прост и понятен, а настройка кластера не сложна, Amway используют все. Позже я напишу еще одну статью, чтобы представить интеграцию и использование компонентов консула в облаке Spring в качестве центра регистрации и обнаружения.