Стоя на перекрестке будущего и оглядываясь назад на потерянный путь истории, часто бывает очень интересно, потому что у нас невольно возникают бредовые мысли, типа а что, если бы что-то случилось раньше в этом году, а другое не случилось? Так же, как что было бы, если бы эрцгерцог Фердинанд и его жена, наследники престола Австро-Венгерской империи, не были застрелены сербским юношей Принципом, и что было бы, если бы Цю Лаодао не проехал через Деревня Нюцзя?
В конце 2008 года Taobao запустила проект внутренней реконструкции под названием «Цветной камень». Позже этот проект стал сервисно-ориентированным, распределенным путем самоисследования Taobao и вышел из начала системы промежуточного программного обеспечения Интернета. Родился в том же году.
Примерно в 2008 году Yahoo, бывший интернет-гигант, начал постепенно публиковать свой продукт распределенной координации больших данных ZooKeeper, ссылаясь на статьи, опубликованные Google на сайтах Chubby и Paxos.
В ноябре 2010 года ZooKeeper превратился из подпроекта Apache Hadoop в проект верхнего уровня Apache, официально объявив ZooKeeper зрелым и стабильным продуктом промышленного уровня.
В 2011 году Alibaba открыла исходный код Dubbo. Чтобы лучше использовать открытый исходный код, необходимо было разорвать отношения с внутренней системой Alibaba. Dubbo поддерживала ZooKeeper с открытым исходным кодом в качестве своего регистрационного центра. Типичное сервисно-ориентированное решение сделало ZooKeeper репутацию в качестве реестра.
Двойной 11 в 2015 году, прошло почти 8 лет с момента появления службы ConfigServer, внутренний «масштаб обслуживания» Alibaba превысил несколько миллионов, а продвижение технологии аварийного восстановления IDC «за тысячи миль» и т. Д. В совокупности побудили Alibaba открыть ConfigServer. путь обновления схемы с 2.0 до ConfigServer 3.0.
Время движется к 2018 году, стоя на стыке 10 лет времени, сколько людей готовы немного притормозить в погоне за постоянно меняющимися модными технологическими концепциями, внимательно вглядываться в область открытия сервисов, сколько людей задумались или думал об одной?
Обнаружение службы, действительно ли ZooKeeper лучший выбор?
Оглядываясь назад на историю, нам тоже есть что наверстать, найти эту сценку в сервисе, лучше ли рождение ZooKeeper, чем наш центр регистрации HSF CONFIGSERVER?
Не пойдем ли мы сначала по пути использования ZooKeeper, а затем лихорадочно модифицируем и исправим ZooKeeper, чтобы адаптировать его к сценариям обслуживания и потребностям Alibaba?
Однако, стоя на плечах сегодняшнего дня и наших предшественников, мы еще никогда так твердо не осознавали, как сегодня, что в сфере обнаружения сервисов ZooKeeper вовсе не лучший выбор, как Эврика и Эврика, которые были с нами все эти Эта статья "Эврика! Почему вам не следует использовать ZooKeeper для обнаружения сервисов" - такое же твердое заявление, почему вам не следует использовать ZooKeeper для обнаружения сервисов!
Я не одинок.
Реестр нуждается в анализе и ключевых аспектах дизайнаДалее давайте вернемся к анализу спроса на обнаружение сервисов в сочетании с практикой Alibaba в ключевых сценариях, чтобы проанализировать один за другим и обсудить, почему ZooKeeper не является самым подходящим решением для реестра.
Является ли реестр системой CP или AP?Я верю, что читатели знакомы с кепками и базовыми теориями, и они стали одним из ключевых принципов, направляющих конструкцию распределенных систем и интернет-приложений. Я не буду повторять свои теории здесь, и мы будем напрямую введем требования к согласованности данных и доступности реестра. Проанализировать:
-
Анализ требований к согласованности данных
Наиболее важной функцией реестра можно считать функцию запроса.Si = F(service-name),отservice-nameдля параметров запроса,service-nameСоответствующая услуга доступнаendpoints (ip:port)Список является возвращаемым значением.
Примечание. В следующем тексте служба обозначается аббревиатурой svc.
Давайте сначала посмотрим на ключевые данныеendpoints (ip:port)Влияние несоответствия, то есть последствия неудовлетворительного C в CAP:
Как показано выше, если
svcB развертывает 10 узлов (реплика/реплика), если для одного и того же имени службы svcB 2 узла вызывающего svcA возвращают противоречивые данные для 2 запросов, например: S1 = { ip1,ip2,ip3...,ip9 }, S2 = {ip2,ip3,....ip10}, каково влияние этого несоответствия? Думаю, вы уже заметили, что трафик каждого узла svcB будет немного несбалансированным.
По сравнению с другими 8 узлами {ip2...ip9} трафик запросов ip1 и ip10 немного меньше, но очевидно, что в распределенной системе даже для одноранговых развернутых служб из-за времени когда поступает запрос, состояние оборудования, планирование операционной системы, GC виртуальной машины и т. д., в любой момент времени состояния узлов этих одноранговых развертываний не могут быть полностью согласованы, а в случае несогласованного трафика, пока реестр находится в пределах времени, обещанного SLA (например, в течение 1 с). вскоре станут статистически непротиворечивыми, поэтому структура реестра с моделью конечной согласованности вполне приемлема в производственной практике.
-
Анализ допустимости разделов и требований к доступности
Далее рассмотрим влияние недоступности реестра на вызов службы в случае Network Partition, то есть влияние, когда A в CAP не выполняется.
Рассмотрим типичную структуру развертывания ZooKeeper для аварийного восстановления с тремя комнатами и 5 узлами (т. е. структура 2-2-1), как показано на следующем рисунке:
Когда Network Partitioned происходит в компьютерном зале 3, то есть компьютерный зал 3 становится островом в сети, мы знаем, что, хотя служба ZooKeeper в целом доступна, узел ZK5 недоступен для записи, поскольку невозможно связаться с лидером.
То есть в настоящее время служба приложений svcB компьютерного зала 3 не может быть заново развернута, перезапущена, расширена или сокращена, но с точки зрения сети и вызова службы, хотя svcA компьютерного зала 3 не может вызывать компьютерный зал 1. и компьютерный зал 2 svcB, но сеть с svcB в компьютерном зале 3 явно в порядке, почему бы не позволить мне позвонить в службу этого компьютерного зала?
Теперь, поскольку сам реестр отказался от доступности, чтобы обеспечить согласованность данных (C) при разделенном мозге (P), это привело к невозможности вызова служб в одном и том же компьютерном зале, что абсолютно недопустимо!Можно сказать, что на практике реестр не может разрушить связь между сервисами ни по какой причине — это железный закон, которому должен следовать дизайн реестра!Мы продолжим обсуждение аварийного восстановления клиента реестра в будущем.
В то же время, давайте рассмотрим несогласованность данных в этом случае.Если машинный зал 1, 2 и 3 все являются изолированными островами, то если svcA в каждом компьютерном зале получает только список ip svcB в компьютерном зале, то есть в списке ip данные svcB в каждой компьютерной комнате совершенно несовместимы.Какое влияние?
На самом деле это не имеет большого значения, но в этом случае все становится одним и тем же вызовом компьютерного класса.Когда мы проектируем центр регистрации, иногда мы даже берем на себя инициативу использовать данные в центре регистрации, чтобы помочь приложение, чтобы сделать это в упреждающем режиме.Позвоните в тот же компьютерный зал, чтобы оптимизировать эффект вызова службы связи RT!
Из вышеприведенного описания видно, что в компромиссе с CAP доступность реестра более ценна, чем строгая согласованность данных, поэтому общий дизайн должен быть более склонен к AP, а не CP, несогласованность данных находится в пределах допустимый диапазон, и P отбрасывается. Однако A полностью нарушает принцип, согласно которому реестр не может разрушить подключение самой службы по любой причине.
Масштаб услуг, емкость, подключение услугНасколько велики «микросервисы» вашей компании? Сотни микросервисов? Развернули сотни узлов? Так что же через 3 года? В Интернете случаются чудеса, может быть, ваша «услуга» за одну ночь станет нарицательной, ваш трафик удвоится, а ваш масштаб удвоится!
Когда масштаб службы центра обработки данных превышает определенное число (масштаб службы = F{номер паба службы, подномер службы}), ZooKeeper как реестр скоро будет перегружен, как осел на рисунке ниже.
На самом деле, когда ZooKeeper используется в нужном месте, то есть используется в крупномодульных сценариях распределенных блокировок и распределенной координации, tps, поддерживаемых ZooKeeper, и количество поддерживаемых подключений достаточно, потому что эти сценарии не подходят для Масштабируемость и требования к емкости ZooKeeper очень высоки.
Однако в сценарии обнаружения службы и мониторинга работоспособности, с увеличением масштаба службы, будь то запрос на запись, вызванный регистрацией службы, когда приложение часто выпускается, или запрос на запись, вызванный состоянием работоспособности службы на уровне миллисекунд. , или не могу дождаться.Машины или контейнеры во всем дата-центре имеют длительные подключения к центру регистрации, и ZooKeeper скоро не сможет справиться с напором подключений.ZooKeeper пишет не масштабируемо,и проблему горизонтальной масштабируемости не решить путем добавления узлов.
Для решения проблемы роста масштаба сервиса на базе ZooKeeper метод, который можно рассмотреть на практике, заключается в том, чтобы найти способ разобраться в бизнесе, разделить домен бизнеса по вертикали и разделить его на несколько реестров ZooKeeper. , но как общий поставщик услуг. Действительно ли возможно, чтобы группа организации платформы разделила бизнес-управление в соответствии с технологией из-за отсутствия возможностей обслуживания, предоставляемых самой собой?
Более того, это нарушает связность сервиса из-за самого реестра (недостаточная емкость).Например, 1 поисковый сервис, 1 картографический сервис, 1 крупный развлекательный сервис, 1 игровой сервис, Должны ли сервисы между ними быть неотделимы друг от друга? Может быть, сегодня да, но что насчет завтра, через 1 год, через 10 лет? Кто знает, какие замечательные бизнес-инновации откроются в нескольких сферах бизнеса в будущем? В качестве базовой службы реестр не может предсказать будущее, конечно, он не может препятствовать потребности бизнес-службы в неотъемлемом соединении в будущем.
Нужно ли реестру постоянное хранилище и журналы транзакций?Нужно и не нужно.
Мы знаем, что протокол ZAB ZooKeeper будет продолжать записывать журнал транзакций на каждом узле ZooKeeper для каждого запроса на запись, и в то же время он будет периодически зеркалировать данные памяти (Snapshot) на диск, чтобы обеспечить согласованность и надежность данные. И данные могут быть восстановлены после простоя. Это очень хорошая функция, но мы должны спросить, в сценарии обнаружения службы, действительно ли основные данные — список адресов работоспособных служб в реальном времени нуждаются в сохранении данных?
Для этих данных ответ отрицательный.
Как показано на рисунке выше, если svcB прошел службу регистрации (ip1) для расширения до 2 узлов (ip1, ip2) для сокращения из-за простоя (ip1 не работает), в этом процессе генерируются три операции записи в ZooKeeper.
Однако после тщательного анализа нецелесообразно постоянно записывать этот процесс изменений в журнал транзакций, потому что при обнаружении службы инициатор вызова службы больше заботится о списке адресов в реальном времени и состоянии работоспособности в реальном времени. При следующем вызове ему не важны исторический список адресов служб и прошлый статус работоспособности вызываемой службы.
Но зачем вам это нужно, потому что полный реестр, доступный для производства, в дополнение к списку адресов службы в реальном времени и статусу работоспособности в реальном времени также будет хранить некоторые метаданные службы, такие как версию службы, группировку, расположение службы, центр обработки данных, вес, информацию о политике аутентификации, метку службы и другую метаинформацию, эти данные необходимо постоянно хранить, а реестр должен предоставлять возможность извлечения эту метаинформацию.
Service Health CheckПри использовании ZooKeeper в качестве реестра службы мониторинг работоспособности службы часто использует механизм ZooKeeper Session Active Track и механизм в сочетании с Ephemeral ZNode.Короче говоря, мониторинг работоспособности службы привязан к мониторингу работоспособности сеанса ZooKeeper или, как говорят, привязан к TCP long определение жизнеспособности ссылок.
Это также может привести к фатальным проблемам во многих случаях.Когда обнаружение активности длинного соединения TCP между ZK и компьютером поставщика услуг является нормальным, является ли служба работоспособной? Ответ конечно нет! Реестр должен предоставлять более совершенные решения для мониторинга работоспособности, а логика работоспособности сервисов должна быть открыта для поставщиков услуг, чтобы они могли определять их сами, а не для определения активности TCP «один размер подходит всем»!
Базовый дизайн крупного принципа обнаружения здоровья является как истинная обратная связь с реальным состоянием здоровья самого обслуживания, или услуга не может быть вызвана, полагают, что результаты оценки здравоохранения, чем без мониторинга здоровья.
Помощь регистрационного центра при стихийных бедствияхКак упоминалось ранее,На практике реестр не может разрушить связь между сервисом по какой-либо причине.Затем с точки зрения наличия, важный вопрос, если сам реестр полностью пострадал, следует ли повлиять ссылку SVCA SVCB?
Да, не должно влиять.
Ссылка вызова службы (поток запросов-ответов) должна слабо зависеть от реестра и должна полагаться на реестр только тогда, когда служба выпущена, компьютер находится в автономном режиме, а служба расширена или заключена по контракту.
Это требует от реестра тщательной разработки клиента, предоставленного им самим.Клиент должен иметь средства для аварийного восстановления, когда служба реестра полностью недоступна.Например, эффективным является разработка механизма кэширования данных на стороне клиента (мы называем его моментальным снимком клиента). с методом. Кроме того, механизм проверки работоспособности реестра должен быть тщательно разработан, чтобы в этом случае не возникало таких ситуаций, как пустые пуши.
Собственный клиент ZooKeeper не имеет такой возможности, поэтому при использовании ZooKeeper для реализации реестра мы должны задать себе вопрос: если все узлы ZooKeeper будут уничтожены, не пострадают ли все ссылки вызова службы в вашем производстве? И в этом вопросе должны быть регулярные упражнения на отказ.
Есть ли у вас специалисты по ZooKeeper, на которых вы можете положиться?ZooKeeper, казалось бы, простой продукт, но масштабное использование в производстве и использование ну не является чем-то само собой разумеющимся. Если вы решили внедрить ZooKeeper в продакшен, то лучше быть готовым обратиться за помощью к техническим специалистам, чтобы психологические ожидания ZooKeeper, наиболее типично проявлялись в двух направлениях:
-
Трудно понять конечный автомат клиента/сеанса
Родной клиент ZooKeeper определенно не прост в использовании.Curator будет лучше, но он на самом деле ограничен.Полностью понять протокол взаимодействия между клиентом ZooKeeper и сервером непросто.Полностью понять и освоить клиент/сессию ZooKeeper , Конечный автомат (ниже) не так прост:
Однако решение для обнаружения служб, основанное на ZooKeeper, основано на постоянном управлении соединением/сеансом, эфемерном ZNode, событии и уведомлении и механизме проверки связи, предоставляемом ZooKeeper.Поэтому, чтобы эффективно использовать ZooKeeper для обнаружения служб, необходимо понимать механизм и Принцип этих ядер ZooKeeper, который иногда делает вас капризным, я просто хочу открыть сервис, откуда я так много знаю? И если вы все это понимаете и не ступаете на яму, поздравляю, вы стали техническим экспертом ZooKeeper.
-
Невыносимая обработка исключений
Когда мы получаем доступ к ZooKeeper во внутренних приложениях Alibaba, есть WIKI «Доступ к приложениям ZooKeeper должен знать и знать», в котором есть следующее обсуждение обработки исключений:
Хотите выбрать самое важное, что нужно знать разработчикам приложений при использовании ZooKeeper? Затем, согласно нашему предыдущему опыту поддержки, это должна быть обработка исключений.
Когда все (хост, диск, сеть и т. д.), к счастью, работает, приложения и ZooKeeper могут работать нормально, но, к сожалению, в течение дня у нас случаются всевозможные сюрпризы, и по закону Мерфи всегда случаются плохие неожиданные вещи, когда вы беспокоиться больше всего.
Поэтому обязательно внимательно изучите исключения и ошибки, которые ZooKeeper будет иметь в некоторых сценариях, убедитесь, что вы правильно понимаете эти исключения и ошибки и знаете, как ваше приложение правильно обрабатывает эти ситуации.
ConnectionLossException и события Disconnected
Короче говоря, это исключение, которое можно восстановить в том же сеансе ZooKeeper (Recoverable), но за восстановление приложения в правильное состояние отвечает разработчик приложения.
Это исключение может быть вызвано многими причинами, например, сеть между компьютером приложения и узлом ZooKeeper отключена, узел ZooKeeper не работает, время полного GC на стороне сервера слишком велико, или даже процесс приложения зависает, и процесс приложения возобновляется после того, как время полного GC слишком велико.Возможны оба варианта.
Чтобы понять это исключение, вам нужно понять типичную проблему в распределенных приложениях, как показано на следующем рисунке:
В типичном клиентском запросе и ответе сервера, когда долгое соединение между ними разорвано, клиент окажется в затруднительном положении при восприятии разорванного события, то есть невозможно определить, в каком состоянии находится запрос рядом, когда произошло событие, и сервер получил этот запрос? С этим разобрались? Поскольку это невозможно определить, при повторном подключении клиента к серверу также появляется знак вопроса о том, следует ли повторить запрос (Retry).
Следовательно, в обработке события отключения соединения, разработчик приложений должен знать, какой запрос находится рядом с вспышкой (это часто сложно судить), и является ли запрос IDEMPotent. Для бизнес-запросов, обработка серверов для Server. Только «процесс один раз» «» максимально один раз «процесс», по крайней мере, один раз «семантика, необязательно и ожидается.
Например, если предыдущий запрос является операцией создания, когда приложение получает исключение ConnectionLossException, то приложение перехватывает это исключение, возможная логика восстановления приложения состоит в том, чтобы определить, существует ли уже узел, созданный предыдущим запросом, и если да. , то Больше не создавать, иначе создать.
В другом примере, если приложение использует exists Watch для отслеживания события создания несуществующего узла, то во время исключения ConnectionLossException может быть обнаружено, что во время этой прошивки могли быть созданы другие клиентские процессы. удаляется, то для текущего приложения пропускается событие создания соответствующего узла. Как это влияет на приложение? Терпимо или неприемлемо? Разработчикам приложений необходимо оценивать и обрабатывать их в соответствии с бизнес-семантикой.
SessionExpiredException и событие SessionExpired
Тайм-аут сеанса — это неисправимое исключение, которое означает, что когда приложение перехватывает это исключение, приложение не может восстановить состояние приложения в том же сеансе, и новый сеанс должен быть установлен заново.Временный узел, связанный с старая сессия также может быть недействительной. Возможно, срок действия принадлежащей блокировки истек. ...
Пытаясь использовать ZooKeeper для обнаружения сервисов, наши друзья из Alibaba однажды поделились своим опытом на нашем технологическом форуме в интрасети.
Он упоминается в статье уместно:
... Я нашел много возможных подводных камней в процессе кодирования. Я оцениваю, что более 80% людей, которые используют ZK для реализации управления кластером, впервые попадут в ямы. Некоторые ямы относительно скрыты, а в сети Проблемы или ненормальные сценарии оно появится только тогда, когда придет время, и может потребоваться много времени, чтобы быть разоблаченным ...
Эта статья была опубликована в сообществе Yunqi, вы можете нажатьздесьвнимательно прочитайте.
Повернуть налево повернуть направоAlibaba вообще не использует ZooKeeper? Не совсем!
Любой, кто знаком с технологической системой Alibaba, знает, что Alibaba поддерживает крупнейший кластер ZooKeeper в Китае и даже в мире с общим масштабом около 1000 сервисных узлов ZooKeeper.
В то время как Alibaba также поддерживает внутреннее промежуточное программное обеспечение для крупномасштабного производства, высокой доступности, мониторинга и упрощения эксплуатации ZooKeeper и обслуживания ветвей кода TaoKeeper, если мы практикуем почти 10 лет использования ZooKeeper в каждом направлении бизнеса и производства, ZooKeeper оценивается с использованием фраза, то мы думаем, что ZooKeeper должен быть «королем координации для больших данных»!
Он играет незаменимую роль в сценариях, не требующих высокой поддержки TPS, таких как крупномодульные распределенные блокировки, выбор распределенного мастера и переключение между активным и резервным режимами с высокой доступностью.Эти требования часто сосредоточены в связанных областях бизнеса, таких как большие данные. и автономные задачи.Из-за большого поля данных важно разделить набор данных, и большую часть времени эти наборы данных обрабатываются параллельно несколькими процессами/потоками, но всегда есть некоторые точки, которые необходимо координировать задачи и процессы.В это время ZooKeeper играет огромную роль.Место для игр.
Однако в транзакционных сценариях транзакций есть естественные недостатки в доступе к основным бизнес-данным, крупномасштабном обнаружении сервисов и крупномасштабном мониторинге работоспособности.Мы должны сделать все возможное, чтобы избежать внедрения ZooKeeper в этих сценариях.В производственной практике Alibaba , когда приложение подает заявку на использование ZooKeeper, оно должно строго оценивать сценарии, емкость и требования SLA.
Таким образом, вы можете использовать ZooKeeper, но, пожалуйста, идите влево для больших данных и вправо для транзакций, влево для распределенной координации и вправо для обнаружения сервисов.
ЭпилогСпасибо за ваше терпение читать здесь, до сих пор, я думаю, вы поняли, мы написали эту статью не для того, чтобы полностью отрицать ZooKeeper, а просто на основе нашей производственной практики Alibaba в крупномасштабном обслуживании за последние 10 лет, мы находимся в service В этом документе обобщаются опыт и уроки открытия, проектирования и использования реестра, в надежде вдохновить и помочь отрасли в том, как лучше использовать ZooKeeper и как лучше спроектировать собственный реестр сервисов.
Наконец, все дороги ведут в Рим, и я искренне желаю, чтобы ваш реестр родился именно в Риме.
Справочная статья
[1]https://medium.com/knerd/eureka-why-you-shouldnt-use-zookeeper-for-service-discovery-4932c5c7e764
[2]https://yq.aliyun.com/articles/227260
Если, Google не будет долго решать вашу проблему.
Если вы все еще хотите узнать дизайн базовой архитектуры известных отечественных и зарубежных компаний, таких как Apple, Facebook, IBM и Ali.
Приходите, мы подготовили саммит ArchSummit Global Architect в Шэньчжэне и хотели бы поделиться с вами:
-
Как машина с 10 000 уровней, стоящая за десятками миллиардов сообщений WeChat, выполняет планирование ИИ
-
Карта одного из трех основных двигателей Didi, как рассчитать планирование пути и сопоставление дорог.
-
Как Weibo дает совместные рекомендации в режиме реального времени для отношений на триллионном уровне
-
Два конкретных случая главного архитектора Веньхун Блокчана
-
Весь процесс полной трансформации микросервисов языка Go от Luo Jithinking
-
Глобальная междоменная RPC-архитектура Ali для новичков
-
Анализ базовой технологии, представленной бывшим лидером визуального глубокого обучения Tesla.
-
Последние практики Paragon Netflix в области микросервисов в отношении FaaS