0 Обзор альбома
etcd Облако родная архитектура Важные базовые компоненты, размещенные люком CNCF. ETCD не только он может быть зарегистрирован как услуга для открытия, но и в качестве ценности на промежуточное программное обеспечение, хранящееся в кластере Micro-Services и Kubernates.
"Понимание статей серии etcd" познакомит с etcd с точки зрения базовой функциональной практики etcd, интерфейса API, принципа реализации, анализа исходного кода и опыта преодоления ям в реализации. Ожидается, что статей будет около 20, автор будет обновлять каждую неделю, прошу обратить внимание.
1 и т. д. Введение
etcd — это проект с открытым исходным кодом, запущенный командой CoreOS в июне 2013 года. Его цель — создать высокодоступную распределенную базу данных «ключ-значение». Имеет следующие характеристики:
- Простота: установка и настройка просты, а для взаимодействия предоставляется HTTP API, и использование тоже очень простое
- Хранилище «ключ-значение»: хранит данные в иерархически организованных каталогах, как в стандартной файловой системе.
- Мониторинг изменений: отслеживайте определенные ключи или каталоги на предмет изменений и реагируйте на изменения значений.
- Безопасность: поддерживает проверку SSL-сертификата
- Быстрота: согласно официальным данным тестов, один экземпляр поддерживает более 2000 операций чтения в секунду.
- Надежность: алгоритм плота используется для обеспечения доступности и согласованности данных распределенной системы.
etcd написан на Go, который имеет отличную кросс-платформенную поддержку, небольшие бинарные файлы и сильное сообщество. Связь между машинами etcd осуществляется с помощью алгоритма Raft.
etcd — это высококонсистентное распределенное хранилище ключей и значений, обеспечивающее надежный способ хранения данных, к которым должен обращаться распределенная система или кластер машин. Он изящно обрабатывает выборы лидеров во время сетевых разделов в ответ на сбои компьютеров, даже если выходит из строя ведущий узел.
Из простого веб-приложения в кластере Kubernetes любое сложное приложение может прочитать данные из данных ETCD или записи на ETCD.
etcd в декабре 2018 года официально присоединился к Фонду облачных вычислений (CNCF, расшифровывается как Cloud Native Computing Foundation), поддерживаемому CNCF. CNCF — это независимый от поставщиков фонд, лидер облачных технологий в продвижении и популяризации технологий.
2 сценария использования
Многие сценарии приложений etcd используются для регистрации и обнаружения служб, кроме того, его также можно использовать для хранения пар ключ-значение, а приложения могут читать и записывать данные в etcd.
Простой вариант использования — хранить сведения о подключении к базе данных или флаги функций в etcd в виде пар ключ-значение. Эти значения можно наблюдать, что позволяет нашему приложению перенастраивать себя при изменении. Расширенное использование заключается в том, чтобы воспользоваться гарантиями согласованности etcd для реализации выбора лидера базы данных или принудительной распределенной блокировки среди набора последователей.
2.1 Хранение пар ключ-значение
A highly-available key value store for shared configuration and service discovery.
Хранилище «ключ-значение» для совместного использования конфигурации и обнаружения служб.
хранилище ключей-значенийкомпоненты, другие приложения основаны на функции его хранилища ключ-значение. Хранилище etcd имеет следующие характеристики:
- Использование хранилища данных типа kv, как правило, быстрее, чем реляционных баз данных.
- Поддерживает динамическое хранилище (память), а также статическое хранилище (диск).
- Распределенное хранилище, которое можно интегрировать в многоузловой кластер.
- Метод хранения использует аналогичную структуру каталогов.
- Только узлы листьев могут на самом деле можно хранить данные, которые эквивалентны файлу.
- Родительский узел листового узла должен быть каталогом, а каталог не может хранить данные.
Задержка лидера etcd является наиболее важной метрикой для отслеживания, и на встроенной панели мониторинга есть представление, предназначенное для этого. В наших тестах сильная задержка вызывала нестабильность в кластере, поскольку Raft был настолько же быстрым, как и самая медленная из большинства машин. Мы можем смягчить эту проблему, соответствующим образом настроив кластер. etcd предварительно настроен для облачных провайдеров с сильно изменчивыми сетями.
2.2 Регистрация и обнаружение службы
Регистрация и обнаружение сервисов (Service Discovery) — это решение одной из самых распространенных проблем в распределенных системах, то есть того, как процессы или сервисы в одном распределенном кластере могут находить друг друга и устанавливать соединения. По сути, обнаружение службы заключается в том, чтобы узнать, есть ли в кластере процессы, прослушивающие порты UDP или TCP, а также найти и связать их по имени.
Чтобы решить проблему обнаружения сервисов, необходимы следующие три столпа, ни один из которых не является обязательным.
-
Строгая согласованность, высокодоступный каталог хранилища служб. ETCD, основанный на алгоритме RAFT, представляет собой каталог хранения служб с высокой согласованностью и высокой доступностью.
-
Сервисные механизмы и регистрация медицинских услуг. Пользователи могут подписаться на услугу в etcd, а ключ TTL для регистрации конфигурации услуги, время удержания услуг для достижения эффекта состояния здоровья монитора сердечного ритма.
-
Механизм поиска и подключения к сервисам. Службы, зарегистрированные в теме, указанной etcd, можно найти в соответствующей теме. Чтобы обеспечить соединение, мы можем развернуть прокси-режим etcd на каждом сервисном компьютере, чтобы гарантировать, что службы, обращающиеся к кластеру etcd, могут подключаться друг к другу.
Библиотека etcd/raft, представленная в etcd2, является одним из самых стабильных и многофункциональных протоколов согласованности с открытым исходным кодом. Являясь основным механизмом репликации данных известных распределенных баз данных, таких как etcd, TiKV, CockcorachDB и Dgraph, etcd/raft управляет более чем 100 000 кластеров и является одной из наиболее широко используемых реализаций консенсусного протокола. Многоверсионный контроль, транзакции и другие функции, представленные в etcd3, значительно упрощают процесс разработки распределенных приложений и повышают эффективность и стабильность. После 5 лет эволюции etcd также стал вариантом хранения по умолчанию для различных систем оркестрации контейнеров. Kubernetes – популярная контейнерная платформа. Кластеры Kubernetes, работающие в любой среде, полагаются на etcd для предоставления стабильных и надежных услуг хранения.
2.3 Публикация сообщений и подписка
В распределенной системе одним из наиболее подходящих методов связи между компонентами является публикация сообщений и подписка. То есть для создания центра обмена конфигурациями поставщики данных публикуют сообщения в этом центре конфигурации, а потребители сообщений подписываются на темы, которые им интересны. После публикации сообщения в теме подписчики будут уведомлены в режиме реального времени. Таким образом, можно обеспечить централизованное управление и динамическое обновление конфигурации распределенной системы.
В службе распределенного поиска метаинформация индекса и состояние узла машины кластера серверов хранятся в etcd для подписки каждого клиента. Использование ключевой функции TTL etcd гарантирует, что состояние машины обновляется в режиме реального времени.
Распределенная система сбора логов. Основная задача этой системы — собирать журналы, распределенные по разным машинам. Сборщик обычно выделяет блоки задач сбора в соответствии с приложением (или темой), поэтому вы можете создать каталог P, названный в честь приложения (темы) на etcd, и поместить все IP-адреса компьютеров этого приложения (связанного с темой) в подкаталог. form хранится в каталоге P, а затем настраивается рекурсивный наблюдатель etcd для рекурсивного отслеживания изменений всей информации в каталоге приложения (темы). Таким образом, когда IP-адрес машины (сообщение) изменяется, сборщик может быть уведомлен в режиме реального времени, чтобы скорректировать распределение задач.
Информация в системе требует динамического автоматического сбора и ручного вмешательства для изменения содержания информационного запроса. Обычно предоставляется доступ к интерфейсу, например интерфейсу JMX, для получения некоторой информации о времени выполнения. После введения etcd нет необходимости самостоятельно реализовывать набор решений, поскольку информация хранится в указанном каталоге etcd, доступ к этим каталогам etcd возможен извне через интерфейс HTTP.
2.4 Распределенное уведомление и координация
Распределенное уведомление и координация, упомянутые здесь, чем-то похожи на публикацию сообщений и подписку. В распределенной системе одним из наиболее подходящих методов связи между компонентами является публикация сообщений и подписка. То есть для создания центра обмена конфигурациями поставщики данных публикуют сообщения в этом центре конфигурации, а потребители сообщений подписываются на темы, которые им интересны. После публикации сообщения в теме подписчики будут уведомлены в режиме реального времени. Таким образом, можно обеспечить централизованное управление и динамическое обновление конфигурации распределенной системы.
Здесь используется механизм наблюдения в ETCD. С помощью регистрации и асинхронного механизма уведомления, уведомление и координация между различными системами в распределенной среде реализуются, чтобы изменения данных могут быть обработаны в режиме реального времени. Реализация обычно понравится: разные системы регистрируют один и тот же каталог на EtCD, и наблюдатель устанавливается для наблюдения за изменениями в каталоге (если есть необходимость в изменениях в подкаталогах, рекурсивный режим может быть установлен), когда система обновляет каталог ETCD Затем система с настроек наблюдения будет получать уведомление и справиться с ним соответственно.
Обнаружение сердцебиения с низким уровнем связи с помощью etcd. Система обнаружения и обнаруженная система связаны через каталог на etcd, а не связаны напрямую, что может значительно уменьшить связанность системы.
Системное планирование осуществляется через EtCD. Система состоит из консоли и системы push. Консоль несет ответственность за управление системой push для выполнения соответствующей настройки Push. Некоторые операции, выполняемые администратором на консоли, фактически изменили состояние некоторых узлов каталогов на ETCD, и etcd уведомляет клиента Push System, зарегистрированного в Watcher этих изменений, и система push выполняет соответствующие задачи.
Заполните отчет о работе через etcd. Для большинства подобных систем распределения задач после запуска подзадачи зарегистрируйте временный рабочий каталог с помощью etcd и регулярно сообщайте о его ходе (записывайте ход выполнения в этот временный каталог), чтобы диспетчер задач мог знать задачу в режиме реального времени. .
2.5 Распределенная блокировка
Когда в распределенной системе существует только одна копия данных (или есть ограничение), необходимо использовать технологию блокировки для контроля количества процессов, модифицирующих данные в определенное время. Блокировка в автономном режиме должна не только обеспечивать видимость процесса, но также должна учитывать сетевую проблему между процессом и блокировкой в распределенной среде.
Распределенные блокировки могут существовать в памяти, просто память выделяется не процессу, а общедоступной памяти, такой как Redis, Memcache. Что касается использования баз данных, файлов и т. д., реализация одной машины одинакова, если тег может быть взаимоисключающим.
Поскольку etcd использует алгоритм Raft для обеспечения строгой согласованности данных, значение, хранящееся в кластере для операции, должно быть глобально непротиворечивым, что упрощает реализацию распределенных блокировок. Есть два способа использования службы блокировки: один — сохранить ее эксклюзивность, а другой — контролировать время.
Оставаться эксклюзивным означает, что только один пользователь, получивший блокировку, в конечном итоге получит ее. etcd предоставляет набор API для реализации атомарной операции распределенной блокировки CAS (CompareAndSwap). Установив значение prevExist, вы можете гарантировать, что при одновременном создании каталога несколькими узлами только один будет успешным. Можно считать, что успешно созданный пользователь получил блокировку.
Контроль времени, то есть все пользователи, которые хотят получить блокировки, будут организованы для выполнения, но порядок получения блокировок также глобально уникален и определяет порядок выполнения. etcd также предоставляет набор API для этой цели (автоматическое создание упорядоченных ключей), который указывается как действие POST при создании значения для каталога, так что etcd автоматически генерирует текущее максимальное значение в качестве ключа в каталоге, и сохраните это новое значение (номер клиента). В то же время вы также можете использовать API для перечисления всех ключей в текущем каталоге по порядку. Значение этих ключей в это время является синхронизацией клиента, а значение, хранящееся в этих ключах, может быть числом, представляющим клиента.
3. Резюме
В этой главе в основном представлены связанные концепции etcd и основные сценарии использования etcd. etcd является мощным инструментом в распределенной среде и имеет широкий спектр приложений в постоянном хранилище. В следующей статье мы подробно расскажем об установке и практике etcd.
Рекомендации по качеству книги
Добро пожаловать купить авторские книги, теперь доступные на рынке:
Оригинально не просто, я надеюсь, что все его поддержат, с нетерпением жду возможности поучиться вместе с вами.