Если вы выбираете основу для service discovery, конфигурационного KV и примитивов вроде distributed lock, то в 2026 на практике чаще всего сравнивают три «классики»: Consul, etcd и ZooKeeper. Функционально они частично перекрываются, но отличаются философией, протоколами консенсуса и эксплуатационными рисками.
Ниже — сравнение глазами администратора/DevOps: где чаще ломается прод (потеря кворума, лавины переподключений, деградация latency), как планировать backup/restore и upgrade strategy, и почему «быстро и предсказуемо» иногда важнее длинного списка фич.
Коротко: что это за системы и зачем они нужны
Consul — платформа сервисного каталога: service discovery, health-check’и, DNS/HTTP интерфейсы, плюс KV и дополнительные возможности в коммерческих редакциях. Его часто выбирают, когда нужен «единый каталог сервисов» с проверками здоровья и минимумом обвязки.
etcd — распределённое KV-хранилище со строгой консистентностью (Raft). Это «источник истины» для control plane Kubernetes и многих систем, где важно надёжно хранить состояние кластера и быстро реагировать на изменения через watch.
ZooKeeper — зрелая координационная служба, исторически популярная в big data/стриминге. Даёт примитивы (ephemeral nodes, watches), на базе которых строят локи, лидер-выборы, конфигурацию и координаторы.
Service discovery: где «нативно», а где нужна обвязка
Consul: discovery — функция номер один
Consul проектировался так, чтобы discovery был центральной функцией:
- каталог сервисов плюс health-check’и (HTTP/TCP/TTL);
- DNS-интерфейс для legacy и HTTP API для автоматизации;
- модель «сервис есть в каталоге, пока агент/инстанс жив и проверки проходят».
Практически это означает: регистрируете сервисы — и сразу получаете работающий discovery, понятный сетевым инструментам и балансировщикам.
etcd: discovery не цель, но как backend для истины — отлично
etcd — не сервис-каталог. Он даёт надёжный KV и watch-механику. Поэтому discovery поверх etcd обычно строят так:
- контроллер/оператор пишет endpoints в ключи;
- агент обновляет ключи через lease (TTL), чтобы «живые» инстансы не зависали навечно;
- потребители подписываются на watch и пересобирают конфиг/апстримы.
Это мощно, но требует дисциплины: схема ключей, аккуратные TTL/lease, контроль числа watchers и понимание, как клиенты переживают таймауты.
Если discovery — «продуктовая» часть инфраструктуры, Consul обычно выигрывает временем внедрения. Если discovery — производная от состояния control plane, etcd часто оказывается проще и надёжнее как единый backend.
Distributed lock и лидер-выборы: нюансы, которые чаще всего ломают прод
Проблема локов не в том, «есть ли API для lock», а в том, что будет при сетевых разрывах, хвостовых задержках и потере кворума. Тут всплывают quorum и «логический split brain», когда разные компоненты начинают жить в разных версиях истины.
etcd: leases + транзакции, но следите за временем и хвостами latency
В etcd локи обычно делают на lease (TTL) и атомарных транзакциях compare-and-swap. Сильная сторона — строгое поведение при наличии кворума. Слабая — чувствительность к задержкам: если p99 RTT или p99 fsync растут, lease может истекать «внезапно», и клиенты начнут чаще переизбирать лидера/перехватывать лок.
Практическое правило: etcd для критичных локов держите в пределах одной площадки/зоны с низкой RTT и предсказуемым диском. Если нужна геораспределённость — чаще лучше поднять отдельные локальные кластеры и согласование вынести уровнем выше.
Consul: сессии и блокирующие запросы — удобно для приложений
Consul даёт сессии и блокирующие запросы (long polling), что делает локи и лидерство удобными на уровне приложения. Но важно помнить: многие выбирают Consul из-за discovery, а локи получают «в нагрузку». Если локи — ваше критическое ядро, к Consul нужно относиться как к базе консенсуса: считать кворум, планировать деградации и тестировать отказные сценарии.
ZooKeeper: классические примитивы, но нужна грамотная клиентская модель
ZooKeeper известен «рецептами» локов/лидерства: последовательные ephemeral znodes плюс watchers и детерминированный выбор. Это работает годами, но клиент должен корректно обрабатывать переподключения, истечение сессий и «шторма» событий от watchers.
Quorum, split brain и топология: как не спровоцировать аварию
Quorum — минимальное число узлов, которое должно подтвердить запись. Классика: 3 узла переживают потерю 1, 5 узлов — потерю 2. Два узла почти всегда превращают любой сетевой инцидент в «нет кворума» и простой на записи.
Split brain в системах со строгой консистентностью чаще проявляется как отказ записей при отсутствии кворума. Но на уровне интеграций вы всё равно можете получить «логический split brain»: часть приложений читает устаревшее из кэша, часть продолжает работать на старых endpoints, а часть переключилась.
Практические правила против split brain
- Делайте нечётное число voting-узлов: 3 или 5.
- Не растягивайте quorum-кластер через «медленные» площадки. Между узлами консенсуса важны хвостовые RTT, а не «средняя задержка».
- Ограничьте шумные операции: compaction/defrag, снепшоты, бэкапы, апгрейды выполняйте по регламенту и с наблюдением метрик.
- Тестируйте поведение клиентов при потере кворума: что будет с локами, discovery, конфигами, ретраями.
Если вы строите HA-стек, где DCS критичен (например, для СУБД-кластера), полезно сверить подходы и типовые отказные сценарии с материалом про DCS и фейловер: Patroni и DCS: как устроен фейловер и где ломается кворум.
Latency: скрытый убийца локов и discovery
Для всех трёх систем latency влияет на качество жизни, но по-разному:
- etcd: запись проходит через лидера и подтверждения от кворума; рост задержек и fsync на диске напрямую увеличивает время коммита и провоцирует timeouts клиентов.
- Consul: кроме консенсуса, есть health-check’и и обновления каталога. При дрожании сети легко получить flapping статусов и churn в маршрутизации.
- ZooKeeper: чувствителен к паузам JVM/GC и сетевым задержкам, которые выглядят как «сессия зависла»; ephemeral узлы могут исчезать, а клиенты получают лавину событий.
Если критичны локи и лидерство, планируйте инфраструктуру как для базы данных: быстрый предсказуемый диск, низкая RTT, стабильные лимиты по CPU и I/O, мониторинг p95/p99 задержек.
Backup/restore: что реально проверять, а не «галочку»
Типовая ловушка координационных систем: «снепшот есть», а restore никто не делал. В аварии выясняется, что снепшот несовместим с версией, восстановление запускает узлы с конфликтующими identity, или данные «поднялись», но клиенты теперь видят два разных мира.
etcd
Обязательно разделяйте задачи compaction и defrag: compaction уменьшает историю/ревизии, defrag возвращает место на диске. Для snapshot/restore — тестируйте восстановление в изолированной среде и помните: restore поднимает всё состояние на момент снимка.
ETCDCTL_API=3 etcdctl snapshot save /var/backups/etcd/snapshot.db
ETCDCTL_API=3 etcdctl snapshot status /var/backups/etcd/snapshot.db -w table
ETCDCTL_API=3 etcdctl snapshot restore /var/backups/etcd/snapshot.db --data-dir /var/lib/etcd-restoredConsul
Чётко определите источник истины: только KV или ещё и сервис-каталог/проверки. В части сценариев каталог можно пересобрать из конфигов и автодискавери, а вот KV с флагами фич и параметрами приложений — уже нет.
ZooKeeper
Смотрите на dataDir и транзакционные логи как на единый набор, и заранее продумайте cold restore так, чтобы не получить «частично живой» кластер с разной реальностью. На практике важна не команда бэкапа, а регламент: кто, когда, где проверяет восстановление и как изолируется тестовый кластер.
Upgrade strategy: как обновляться без сюрпризов
Апгрейды — один из главных критериев выбора, потому что эти системы стоят в центре инфраструктуры.
Общее для всех
- Rolling upgrade используйте только если он официально поддержан вашей версией и топологией.
- Перед обновлением проверьте здоровье кластера: нет ли отстающих followers, переполненных дисков, аномалий по fsync/RTT.
- Сделайте бэкап и проведите репетицию restore в отдельной среде.
etcd
Rolling upgrade обычно возможен, но критичны совместимость версий и порядок обновления. Отдельно следите за изменениями поведения compaction/defrag и форматов snapshot/restore между минорными релизами.
Consul
Проверяйте изменения в API, DNS-поведении и безопасности (ACL). И учитывайте эксплуатационный масштаб: Consul часто касается каждого сервиса через agent, поэтому «обновить кластер» — это не только 3–5 серверов, а ещё и множество машин с агентами.
ZooKeeper
Rolling upgrade возможен, но боль часто приходит со стороны Java-окружения: версии JVM, параметры GC, лимиты файловых дескрипторов, предсказуемость диска. Апгрейд без контроля JVM-метрик — плохая идея.
Сравнение по сценариям: что выбирать в 2026
Если в первую очередь нужен service discovery
Consul обычно лучший выбор, когда нужен «из коробки» каталог сервисов, health-check’и и удобный способ потребления (DNS/API). Это подходит, если discovery — отдельная инфраструктурная функция, которую вы хотите стандартизировать для команд.
Если нужно надёжное согласованное KV и примитивы координации
etcd — сильный выбор, особенно если вы уже живёте в Kubernetes-мире или строите собственный control plane. Он хорошо масштабируется операционно как «строгая база состояния», но требует дисциплины по latency и диску.
Если вы в экосистеме, завязанной на ZooKeeper
ZooKeeper остаётся актуальным, когда он «родной» для ваших компонентов или когда важны проверенные временем паттерны. Но для новых микросервисных платформ часто проще стартовать с Consul/etcd из-за более привычной операционной модели и меньшей зависимости от JVM-тюнинга.
Чеклист выбора: вопросы до внедрения
- Что для нас важнее: discovery, KV, локи, лидерство, конфиги, ACL?
- Какая целевая топология: один ДЦ, несколько зон, несколько площадок? Какой допустимый p99 latency между узлами?
- Сколько будет записей в секунду и сколько watch-подписчиков в пике?
- Какой RPO/RTO и есть ли регулярные тесты backup/restore?
- Как будет выглядеть upgrade strategy: rolling, blue/green, окно обслуживания?
- Что будет делать приложение при потере quorum: деградировать, читать кэш, останавливать критические операции?
Итог
В споре Consul vs etcd vs ZooKeeper нет единого победителя: Consul выигрывает там, где нужен удобный service discovery и checks; etcd — там, где нужен строгий Raft-кворум и хранилище состояния; ZooKeeper — там, где важны зрелые координационные примитивы и совместимость с существующей экосистемой.
Прагматичный выбор почти всегда упирается в три вещи: (1) требования к консистентности и локам, (2) допустимую latency и топологию, (3) способность команды стабильно делать бэкапы, restore и безопасные апгрейды.
Если инфраструктуру под кластер консенсуса вы разворачиваете с нуля, проще всего держать узлы на предсказуемых виртуальных машинах с гарантированными IOPS и низкой RTT внутри сети: под это хорошо подходит VDS с фиксированными ресурсами и понятным сетевым контуром.
