Диаграмму архитектуры для консула, работающего в одном центре обработки данных, лучше всего описать, как показано ниже:
Как мы видим, есть три разных сервера, которые управляются консулом. Рабочая архитектура работает с использованием алгоритма raft, который помогает нам выбрать лидера из трех разных серверов. Эти серверы затем маркируются в соответствии с тегами, такими как Follower и Leader . Как следует из названия, последователь несет ответственность за следование решениям лидера. Все эти три сервера дополнительно связаны друг с другом для любого общения.
Каждый сервер взаимодействует со своим клиентом, используя концепцию RPC. Общение между Клиентами возможно благодаря Протоколу Сплетни, как упомянуто ниже. Связь с Интернетом может быть доступна с использованием протокола TCP или сплетни. Это сообщение находится в прямом контакте с любым из трех серверов.
Алгоритм Рафта
Raft — это согласованный алгоритм для управления реплицированным журналом. Он основан на принципе теоремы CAP , который гласит, что при наличии сетевого раздела приходится выбирать между согласованностью и доступностью. Не все три основы теоремы CAP могут быть достигнуты в любой момент времени. Нужно обменять на любые два из них в лучшем случае.
Raft Cluster содержит несколько серверов, обычно с нечетным числом. Например, если у нас пять серверов, это позволит системе выдерживать два сбоя. В любой момент времени каждый сервер находится в одном из трех состояний: Лидер, Последователь или Кандидат . При нормальной работе есть ровно один лидер, а все остальные серверы являются последователями. Эти последователи находятся в пассивном состоянии, то есть они не подают никаких запросов самостоятельно, а просто отвечают на запросы лидеров и кандидата.
На следующем рисунке описана модель рабочего процесса, в которой работает алгоритм рафта.
Ключевые данные ценности
Начиная с версии 0.7.1 Консула, были введены отдельные данные значения ключа. Команда KV используется для взаимодействия с хранилищем ключей консула через командную строку. Он предоставляет команды верхнего уровня для вставки, обновления, чтения и удаления из хранилища. Чтобы получить хранилище объектов Key / Value, мы вызываем метод KV, доступный для клиента консула —
kv := consul.KV()
Структура KVPair используется для представления одной записи ключа / значения. Мы можем просмотреть структуру Consul KV Pair в следующей программе.
type KVPair struct { Key string CreateIndex uint64 ModifyIndex uint64 LockIndex uint64 Flags uint64 Value []byte Session string }
Здесь различные структуры, упомянутые в приведенном выше коде, могут быть определены следующим образом:
-
Ключ — это косая черта. Например — sites / 1 / domain.
-
CreateIndex — номер индекса, назначенный при первом создании ключа.
-
ModifyIndex — номер индекса, назначенный при последнем обновлении ключа.
-
LockIndex — индексный номер, созданный при получении новой блокировки для записи ключ / значение
-
Флаги — могут использоваться приложением для установки пользовательского значения.
-
Значение — это байтовый массив максимум 512 КБ.
-
Сеанс — это можно установить после создания объекта сеанса.
Ключ — это косая черта. Например — sites / 1 / domain.
CreateIndex — номер индекса, назначенный при первом создании ключа.
ModifyIndex — номер индекса, назначенный при последнем обновлении ключа.
LockIndex — индексный номер, созданный при получении новой блокировки для записи ключ / значение
Флаги — могут использоваться приложением для установки пользовательского значения.
Значение — это байтовый массив максимум 512 КБ.
Сеанс — это можно установить после создания объекта сеанса.
Типы протокола
В Консуле есть два типа протокола, которые называются —
- Протокол о согласии и
- Протокол сплетни
Давайте теперь разберемся в них подробно.
Консенсусный протокол
Консенсусный протокол используется Консулом для обеспечения согласованности, как описано в теореме CAP. Этот протокол основан на алгоритме Плот. При реализации согласованного протокола используется алгоритм Плот, в котором узлы плот всегда находятся в любом из трех состояний: «Подписчик», «Кандидат» или «Лидер».
Протокол сплетни
Протокол сплетен может быть использован для управления членством, отправки и получения сообщений по всему кластеру. В консуле использование протокола сплетен происходит двумя способами: WAN (беспроводная сеть) и LAN (локальная сеть). Существует три известные библиотеки, которые могут реализовать алгоритм Gossip для обнаружения узлов в одноранговой сети —
-
teknek-gossip — работает с UDP и написан на Java.
-
gossip-python — он использует стек TCP и позволяет обмениваться данными через построенную сеть.
-
Smudge — написано на Go и использует UDP для обмена информацией о статусе.
teknek-gossip — работает с UDP и написан на Java.
gossip-python — он использует стек TCP и позволяет обмениваться данными через построенную сеть.
Smudge — написано на Go и использует UDP для обмена информацией о статусе.
Протоколы сплетен также использовались для достижения и поддержания согласованности распределенной базы данных или с другими типами данных в согласованных состояниях, подсчета количества узлов в сети неизвестного размера, надежного распространения новостей, организации узлов и т. Д.
Удаленные вызовы процедур
RPC можно обозначить как краткую форму для удаленных вызовов процедур. Это протокол, который одна программа использует для запроса услуги у другой программы. Этот протокол может быть расположен на другом компьютере в сети без необходимости подтверждения деталей сети.
Настоящая прелесть использования RPC в Консуле заключается в том, что он помогает нам избежать проблем с задержкой, которые были у большинства инструментов службы обнаружения некоторое время назад. До RPC Консул имел обыкновение иметь только соединения на основе TCP и UDP , что было хорошо для большинства систем, но не в случае распределенных систем. RPC решает такие проблемы путем сокращения периода времени передачи пакетной информации из одного места в другое. В этой области GRPC от Google — это отличный инструмент, который можно рассчитывать на случай, если кто-то захочет соблюдать критерии и сравнить производительность.