Технический отбор
Структура RPC компанииdubbo, используемый с ним компонент обнаружения служб всегдаzookeeper, давно не большая проблема. Что касается того, почему вы должны подумать о замене zookeeper, то это не из-за его узкого места в производительности, а из-за云原生эволюция направления.
Cloud Native Computing Foundation (CNCF) определяет облачные вычисления как:
❝Облачные технологии позволяют организациям создавать и запускать эластично масштабируемые приложения в новых и динамичных средах, таких как общедоступные, частные и гибридные облака. Репрезентативные облачные технологии включают контейнеры, сервисные сетки, микросервисы, неизменяемую инфраструктуру и декларативные API. Эти методы позволяют создавать слабосвязанные системы, которые являются отказоустойчивыми, простыми в управлении и легко наблюдаемыми. В сочетании с надежной автоматизацией облачные технологии позволяют инженерам легко вносить частые и предсказуемые критические изменения в систему.
❞
Если вы хотите приземлиться в облаке, ключевыми шагами являютсяmesh化, текущее основное обсуждениеservice mesh(Сервисная сетка), предложение, описывающее сервисную сетку.
❝Service mesh — это протокол TCP в эпоху микросервисов.
❞
Наиболее очевидным преимуществом Service Mesh по сравнению с существующими микросервисами является то, что он снижает нагрузку на инфраструктуру и отделяет управление сервисами от развития бизнеса.
Чтобы привести простой пример, если вы хотите хорошо управлять службами в микросервисной архитектуре, вам необходимо ввести большое количество сторонних компонентов, таких как ограничение тока, слияние, мониторинг, обнаружение служб, балансировка нагрузки и т. д. отслеживание ссылок и ряд компонентов. И эти компоненты, вероятно, будут зависеть от бизнес-кода в виде пакетов jar, и даже разные языки разработки должны поддерживать разные компоненты. Связь бизнеса и инфраструктуры делает сервис управление крайне затруднено.
Сервисная сетка управляет связью между сервисами и обычно состоит из ряда прокси-сетей, которые прозрачны для приложений. Все, что касается управления услугами (включая, помимо прочего, упомянутое выше ограничение тока, отключение цепи, мониторинг, обнаружение услуг и т. д.), может быть погружено в сетевой агент.
Сказав так много, какое это имеет отношение к замене смотрителя зоопарка?
В структуре dubbo есть три основных компонента: поставщик услуг (поставщик), потребитель услуг (потребитель) и реестр (реестр).
После запуска провайдера он регистрирует IP, порт, имя службы, имя метода и другую информацию, которую он предоставляет в реестре.Когда потребитель инициирует вызов, имя службы и имя метода находятся в реестре, чтобы найти соответствующий ip. и порт, чтобы инициировать удаленный вызов.
Механизм регистрации и обнаружения служб в облачной системе сильно отличается от механизма регистрации и обнаружения служб dubbo.k8sОбнаружение регистрации службы основано наDNS, то есть найти соответствующий ip через доменное имя.
Таким образом, очень сложно перенести службу dubbo в облачную систему. Существует ли компонент, совместимый с регистрацией и обнаружением двух служб? После исследования накос.
Во-первых, nacos, как и zookeeper, предоставляет методы регистрации и обнаружения для традиционных микросервисов, во-вторых, nacos также предоставляет подключаемый модуль на основе coreDNS DNS-F (DNS-фильтр), который действует как прокси для перехвата DNS-запросов на хосте. .Если сервис Если его можно найти на nacos, то он сразу вернет прописанный ip, в противном случае продолжите искать DNS.
После завершения наша сервисная сетка-архитектура выглядит примерно следующим образом.
Политики доступа внутри и снаружи сетки следующие:
- автономный даббо -> сетевой даббо: реестр
- автономный даббо -> автономный даббо: реестр
- Даббо в сети -> Даббо вне сетки: доменное имя => dns-f => реестр
- внутрисетевой dubbo -> внутрисетевой dubbo: доменное имя => dns-f => dns
- Гетерогенные языки (PHP, Node) могут вызываться напрямую через имя службы, перехватываться DNS-F, разрешаться в правильный IP-адрес, а стратегия балансировки нагрузки может быть скорректирована.
В то же время высокая доступность режима nacosAP, масштабируемость записи и возможность подключения к CMDB также являются одними из факторов, которые следует учитывать.
План миграции
Если вы хотите плавно перейти с zookeeper на nacos, есть два варианта:
- Преобразуйте приложение dubbo, измените регистрацию службы на двойную регистрацию (одновременно зарегистрируйтесь в zookeeper и nacos), а затем переключитесь на nacos после преобразования всех приложений.
- Используйте инструмент миграции для единообразной миграции служб, зарегистрированных в zookeeper, в nacos, а затем медленно изменяйте приложение. Вам не нужно ждать полной миграции, чтобы пользоваться новыми функциями, представленными nacos.
Вариант 1 прост в реализации, но стоимость трансформации высока. Мигрировать некоторые старые и неподдерживаемые сервисы сложно. Даже такие сервисы, как PHP и Node на уровне компании, также полагаются на zookeeper, поэтому завершить миграцию на уровне компании невозможно. один раз.
Вариант 2 требует мощного инструмента миграции, что усложняет технологию.К счастью, nacos предоставляетnacosSync.
Конечно, мы выбрали вариант 2 и заодно сделали небольшую оптимизацию. Чтобы снизить риск миграции, благодаря превосходной масштабируемости dubbo, набор настраиваемых态注册中心, центр динамической регистрации считывает конфигурацию из центра конфигурации при запуске службы, выбирает, регистрироваться ли в zookeeper или nacos (или в обоих), и выбирает nacos или zookeeper при использовании службы.Для потребления можно указать только один центр регистрации. .
По умолчанию он будет регистрироваться в двух реестрах одновременно и потреблять zookeeper.После введения пакета jar бизнес-сторона не воспринимает.При переключении нужно изменить только конфигурацию.Центр регистрации для регистрации и потребления может будет изменено в следующем выпуске, и поддерживается конфигурация для одного приложения. , для упрощения оттенков серого.
Оптимизация инструмента миграции
Принцип nacosSync очень прост: если zookeeper синхронизирует данные с nacos, nacosSync действует как клиент zookeeper при запуске, сбрасывает все службы на zookeeper, анализирует их в формате службы nacos, регистрируется в nacos и отслеживает каждый узел службы на в то же время., обновите данные nacos, когда есть изменения.
Стратегия односторонней синхронизации
nacosSync может реализовать функцию двусторонней синхронизации от zookeeper к nacos, но мы считаем двустороннюю синхронизацию рискованной.В конце концов, nacos — это новая вещь, и стабильность не может быть гарантирована.Если данные в nacos неверны, синхронизация с zookeeper приведет к проблемам с производством. Поэтому была принята консервативная стратегия односторонней синхронизации от зоопарка до нако.
Высокая доступность
Как инструмент миграции, который должен быть онлайн в течение длительного времени, он должен обеспечить собственную стабильность и высокую доступность.Представьте, что если инструмент миграции выйдет из строя, все службы будут удалены из nacos, что будет сокрушительным ударом. nacosSync помещает хранилище данных в базу данных.Сам компонент не имеет состояния и может быть развернут в нескольких единицах, чтобы предотвратить единую точку отказа. Но это также приносит другие проблемы.Нагрузка на сервер nacos для развертывания N единиц составляет N раз, потому что служба будет зарегистрирована N раз, и она также будет обновляться N раз после модификации.Эта оптимизация будет обсуждаться позже.
Полная поддержка синхронизации
nacosSync не поддерживает полную синхронизацию и может быть настроен только для одной службы.Для служб 3k+ невозможно вручную настроить одну службу для одной службы. Так что разработайте полную конфигурацию, это не сложно, но очень полезно.
Внеочередная обработка событий zookeeper
После того, как nacosSync отслеживает узел zookeeper, при изменении узла zookeeper nacosSync синхронизирует измененные данные с nacos.
Но во время тестирования мы обнаружили проблему: после отключения службы dubbo, если она не будет отключена изящно (например, процесс убит -9), узел будет отключен zookeeper в течение нескольких секунд до несколько минут (в зависимости от конфигурации).Если служба перерегистрируется в это время, событие удаления узла может поступить после события добавления нового узла, что вызовет очень важную проблему.Вновь зарегистрированная служба отключена от старой удалить событие.
Решение также относительно простое: в информации о зарегистрированном узле dubbo содержится информация миллисекундного уровня.timestampИнформация, отметка времени будет сравниваться каждый раз при обработке события.Если она больше или равна текущему значению, событие будет считаться действительным, в противном случае событие будет считаться старым событием и не будет обработано.
После такого логического суждения такие проблемы больше никогда не возникали.
Активное обнаружение сердцебиения
Поскольку развертываются два nacosSync, если служба отключается, в одном из nacosSync возникает неизвестное исключение, которое сделает службу недоступной, но она всегда существовала в nacos, и при вызове будет сообщено об ошибке.
Во избежание такой ситуации в nacosSync добавлено определение порта машины, и соединение устанавливается со всеми машинами через равные промежутки времени, если не получается, проверьте, существует ли нода в zookeeper, и если есть, удалите машину не существует.
Почему его нельзя устранить сразу после сбоя определения сердцебиения? Потому что иногда сервер отказывается подключаться или истекает время ожидания, но служба в это время все еще находится в сети, поэтому она все еще находится в zookeeper. Что касается того, почему вы не сканируете зоопарка напрямую, это также связано с производительностью зоопарка.
оптимизация nacos
Инструмент миграции почти оптимизирован, и мы начинаем синхронизировать все онлайн-сервисы с nacos.
Сначала мы построили nacos-кластер с 3 нодами, в результате из-за большого количества сервисов загрузка процессора nacos-машины долгое время была на очень высоком значении, превышающем 50%. Вот набор данных для справки:
- Количество услуг: 3k+
- Количество экземпляров сервиса: 30 000+
- Количество узлов nacosSync: 2
- Количество узлов nacos: 3 (50%~80% загрузки процессора)
Идеальный мониторинг
Как оптимизировать? Во-первых, найдите узкое место в производительности. Nacos изначально отслеживает на основе spring-boot, но это очень безвкусно и не имеет нужных данных. Поэтому мониторинг улучшается с двух измерений клиента и сервера. Вот те, которые я считаю более важными Несколько индикаторов мониторинга
- сервер nacos: соотношение ЦП, количество сервисов, количество экземпляров, количество принятых запросов (отличных от API), время ответа на запрос (по API), скорость обработки сердцебиения, время отправки (собственно), количество отправки (собственно)
- клиент nacos: объем запроса (для различения API), время запроса (для различения API), скорость отправки сердцебиения
Оптимизация сердцебиения
После того, как вышеуказанный мониторинг был улучшен, узкое место можно было увидеть с первого взгляда: слишком много запросов пульса, и 99% запросов являются запросами пульса.
Это связано с дизайном nacos и dubbo. Регистрация Dubbo — это сервисное измерение.Один IP-адрес регистрирует множество экземпляров службы, в то время как сердцебиение nacos основано на экземпляре, а по умолчанию — одно сердцебиение для одного экземпляра каждые 5 секунд.
Для экземпляра, близкого к 40k, есть 40k запросов сердцебиения каждые 5 секунд, что составляет 8k/s при преобразовании в qps, и используются два nacosSync, то есть удваивают запрос heartbeat 16k/s, и это HTTP-запрос, а есть еще внутренние ноды.Для задачи синхронизации данных странно что ЦП не высокий.
Поэтому мы подумали о ряде способов оптимизации:
Отрегулируйте интервал сердцебиения
Время пульса настраивается вдвое по сравнению со значением по умолчанию, то есть на 10 секунд, а время автономной работы узла без пульса (с 30 с до 60 с) также корректируется за счет обнаружения автономного экземпляра в реальном времени.
Расширение
Расширение накосов серверов с 3 до 5, эффект хороший, но не очевидный.
уменьшить сердцебиение
Так как нам нужно постепенно мигрировать сервис, мигрированный сервис, если сам сервис отправляет пульс, а два nacosSync также отправляют пульс, у перенесенного сервиса в три раза больше запросов пульса, и это также приводит к отключению сервиса. риск того, что служба все еще будет онлайн, если одна из сторон не устранена.
Поэтому в упомянутом выше центре динамической регистрации часть информации метаданных добавляется к сервису, зарегистрированному на nacos.withNacos=true, а затем изменить логику nacosSync, игнорируя службу withNacos=true, синхронизированную zookeeper. Таким образом, поскольку перенесенная служба будет отправлять контрольные сообщения только самой службой, количество запросов контрольных сообщений будет уменьшено.
объединить сердцебиение
В nacosSync зарегистрировано большое количество сервисов. Из предыдущих расчетов известно, что в секунду отправляется около 8 000 сердцебиений. пакетная обработка также может быть ускорена.
Прежде чем внедрять объединенное сердцебиение, вам необходимо понять протокол дистрибутива в режиме точки доступа nacos.Для этой части см.«Введение в дистрибутив протокола согласованности Nacos»
Кратко обобщить путь обработки одного сердцебиения:
Клиент случайно находит узел NACOS, чтобы иметь сердцебиение для экземпляра обслуживания. Поскольку каждый узел сервера NACOS отвечает только за часть службы, когда он получает запрос, он определяет, является ли это услуга, за которое она отвечает. Если это Это будет обработано. Если нет, то передан на ответственный узел.
Один маршрут пульса легче обрабатывать. Если объединенная служба отправляет пульс, сервер должен классифицировать полученные запросы в соответствии с ответственным узлом. После классификации обрабатываются только службы, принадлежащие его собственному, а службы, которые не свои запарочены на другие ноды. Необходимо обратить внимание на то, обрабатывается ли запрос с клиента или с сервера.
Клиент буферизует объекты, которым нужны пульсации, в очередь, каждую секунду считывает пакет из очереди и отправляет их пачками.Необходимо обратить внимание на настройку размера этого буфера.Если он слишком мал, пульсация может быть потеряно. Если оно слишком велико, пульсация может быть потеряна. Слишком много памяти.
Эффект слияния немедленный, не только ЦП сервера упал с 50%+ до менее чем 10%, но потребление ЦП nacosSync также снизилось вдвое.
Сохранилась только эта картинка.На тот момент ЦП был еще около 20% из-за бага.После решения проблемы ЦП был в пределах 10%.
Длинное соединение
На самом деле проблема heartbeat здесь решена только наполовину, потому что при большом количестве сервисов в nacosSync эффект пакетного heartbeat более очевиден. Если это мигрированная служба, на одной машине всего 10 экземпляров, и несколько запросов пульса нельзя сохранить за одну секунду, поэтому эффект должен быть значительно уменьшен. Итак, я проанализировал установление соединения HTTP-запросов, и веб-фильтр, который занимает много времени для каждого запроса, потребляет производительность, поэтому я хочу увидеть эффект от его модификации на длинное соединение.
Для быстрой проверки догадки модифицируется только интерфейс heartbeat, этот интерфейс имеет наибольший объем и может решить 80% задач.
Что использовать для достижения длинного соединения, есть два решения, netty и grpc, которые рассматривались в начале. Заблокировано для быстрой проверкиgrpc, При этом упомянутый выше DNS-F на самом деле является клиентом nacos.Он реализован на языке go и просто поддерживает grpc нативно, поэтому я не раздумывая внедрил версию с grpc.
Используйте конфигурацию, чтобы выбрать использование собственного пульса, пакетного пульса, пульса grpc.
Проблема, возникающая при реализации постоянных подключений, заключается в том, что пульс перенаправляется на ответственный узел в протоколе дистрибутива, который является внутренним ретранслятором. Рассмотрите возможность написания логики в клиенте.Как и в случае с redis, когда за это отвечает не сервис, он будет запрашиватьredirectОтветственному узлу клиент повторно инициирует запрос.
Первоначально клиент случайным образом выбирает узел для отправки.Если получено перенаправление, целевой узел службы будет кэширован, и кеш будет очищен в следующий раз, когда будет сообщено о перенаправлении или ошибке, чтобы обеспечить правильность выбранный узел, если серверный узел Если нет изменений, клиент может одновременно поразить узел, что просто и эффективно В то же время логика не очень сложна, и относительно просто реализовать в DNS-F.
Окончательный результат измерения заключается в том, что если nacosSync полностью использует пульсацию grpc, он будет немного выше, чем у процессора пакетной синхронизации, ненамного. Это однотактовая передача, что очень хорошо, это означает, что даже при переносе всех сервисов можно приблизиться к эффективности пакетной передачи.
Ключевой интерфейс длинное соединение
После вкуса сладости сердцебиения оптимизации длительного соединения несколько важных интерфейсов, таких как регистрация службы, получение службы и т. д., были изменены на длительное соединение, а DNS-F также адаптирован для длительного соединения, эффект очень хороший, достигающий us Ожидания от производительности nacos.
Элегантно на линии и вне ее
nacos предоставляет элегантный автономный интерфейс, то есть автономный сервис, но это, например, широта. Он не очень дружелюбен к внутренней системе публикации компании. Система публикации не знает, какие службы находятся в машине, поэтому ей нужно укажите широту IP.Автономный интерфейс также можно понимать как пакетный автономный интерфейс.При реализации пакетного интерфейса пульса также необходимо обратить внимание на протокол дистрибутива.
Улучшения DNS-F
Длинное соединение
Об этом уже говорилось выше и здесь повторяться не буду.
Имя домена службы Dubbo является незаконным
Услуги, зарегистрированные dubbo на nacos:
providers:com.xx.yy.zzОбычно мы используем имя службы в качестве имени домена, чтобы инициировать вызов dubbo, но кавычки в имени домена недопустимы.Прямой доступ через это имя домена сообщит об ошибке, поэтому код DNS-F изменен, и вызов осуществляется с помощью
providers.com.xx.yy.zzDNS-F внутри доменного имениproviders.заменитьproviders:Это наименьшая точка изменения.
Высокая доступность
Поскольку сам DNS-F действует какagentПроцесс выполняется на машине, поэтому высокая доступность гарантируется двумя способами.
- Следите за процессом DNS-F и вовремя подтягивайте его после того, как он зависнет
- Создайте централизованный кластер DNS-F.Когда локальный DNS-F недоступен, разрешение DNS сначала пройдет через кластер DNS-F, а затем перейдет к обычному кластеру DNS.
наконец
Как относительно новый компонент с открытым исходным кодом, nacos неизбежно столкнется с различными проблемами при его использовании.Эта статья посвящена более важным ямам, с которыми столкнулся автор при миграции zookeeper на nacos.Я надеюсь, что это будет полезно для всех.Конечно, есть и другие детали, которые не могут быть перечислены из-за нехватки места.