Проблемы и эволюция службы именования Meituan

|Эта статья основана на содержании выступления Шу Чао, технического эксперта из отдела инфраструктуры Meituan, на ArchSummit 2019 (Global Architect Summit).

Служба именования в основном решает потребности в обнаружении служб и изоляции маршрутов, вызванных разделением микрослужб, и является краеугольным камнем управления службами. Служба именования Meituan (далее именуемая MNS), являющаяся основным модулем системы управления услугами OCTO, в настоящее время предоставляет десятки тысяч услуг Meituan, при этом средний ежедневный вызов достигает триллионного уровня. Чтобы лучше поддерживать быстро развивающийся бизнес Meituan, MNS начал развиваться с версии 1.0 до версии 2.0. В этой статье основное внимание будет уделено первоначальному замыслу этой эволюции, плану реализации и эффекту реализации.В то же время в этой статье также представлена важная ценность службы именования как технологического компонента промежуточного уровня для бизнеса и некоторые достижения в продвижении модернизации бизнеса. Я надеюсь, что эта статья может вдохновить вас.

1. Введение в MNS 1.0

С архитектурной точки зрения MNS 1.0 в основном делится на три уровня: во-первых, SDK, встроенный в бизнес, который используется для пользовательских бизнес-вызовов; затем SgAgent, размещенный на каждой машине, который преобразует некоторое энергозависимое потребление Расчет производительности логика отделена от бизнес-процесса, тем самым уменьшая вторжение SDK в бизнес и уменьшая влияние изменений политики на бизнес; удаленный конец представляет собой централизованный компонент, включающий модуль проверки работоспособности Scanner, модуль кэширования аутентификации MNSC, и модуль на основе ZooKeeper (далее ZK), компонент согласованности MNS-ZK, в качестве модуля уведомления и хранения. Настраивайте многоуровневые кэши между слоями, используйте идею «пограничных вычислений» для разделения логики, упрощения данных и старайтесь распределять маршрутизацию и другую работу поровну до конца, тем самым снижая нагрузку на центральные компоненты. Для получения более подробной информации см.Крупномасштабная микросервисная коммуникационная среда и система управления Meituan Основные компоненты OCTO с открытым исходным кодом" в разделе OCTO-NS статьи.

Что касается объема, MNS 1.0 был подключен ко всем онлайн-приложениям Meituan, включая десятки тысяч сервисов, сотни тысяч узлов и охватывая все бизнес-направления Meituan, со средним ежедневным звонком в триллионы.открытый источник.

В целом, как основной компонент управления услугами на уровне компании, MNS 1.0 имеет очевидные атрибуты CP в своей архитектуре.Сохраняя простоту архитектуры и ясность процесса, он также поддерживает потребности большого количества бизнес-итераций и лучше помогает компании. Бизнес Достигнута цель обслуживания и стандартизации.

2. Проблемы и проблемы, с которыми сталкивается MNS 1.0

Однако с быстрым ростом бизнеса Meituan количество услуг компании, количество узлов, объем служебной информации, частота изменений услуг и другие параметры быстро растут, а некоторые услуги даже демонстрируют рост на порядок. В такой ситуации служба имен также сталкивается с рядом новых проблем и вызовов:

Доступность: бизнес компании продолжает быстро расти, и многие из них требуют межрегионального развертывания. В архитектуре MNS 1.0 при отключении выделенной линии между регионами общая региональная служба именования будет недоступна, во-вторых, есть проблема в одной точке в сильно согласованном компоненте, лидер выходит из строя, и весь кластер прерывается. сценарий службы имен клиента и передачи больших данных, систему CP трудно восстановить, а RTO достигает часового уровня. В MNS 1.0 одномашинное подключение серверных централизованных компонентов превышало 100 000, а количество активных ссылок составляло более половины После проблемы можно представить себе нагрузку восстановления на месте, что влекло за собой большие риски для наличие системы именования.
Расширяемость: По сравнению с количеством поддерживаемых сервисов общих возможностей параллельного расширения MNS 1.0 недостаточно. Верхний предел размера одного кластера MNS-ZK не превышает 300 (фактически может достигать только около 250, что связано с таким механизмом, как myid внутри ZooKeeper), иначе производительность синхронизации резко ухудшится; во-вторых, кластер запись не масштабируется, и чем больше узлов участвует в записи, тем хуже производительность; кроме того, моментальный снимок служебной информации продолжает расти в фиксированном временном интервале, что увеличивает нагрузку на ввод-вывод и продлевает время синхронизации миграции . Короткая плата в масштабируемости мешает MNS 1.0 справляться с внезапными пиками трафика и склонна к «лавинности».
представление: Операции записи ограничены свойством CP, а производительность последовательного порта низкая. Общая емкость записи MNS-ZK составляет около 7000, что близко к верхнему пределу. Во-вторых, в сценарии с хот-спотом данные распределяются медленно, что также связано с более грубой детализацией данных. Грубая детализация и большой объем данных также приводят к тому, что временные объекты часто генерируются при передаче сообщений между компонентами, вызывая GC. Кроме того, сохраняется баланс нагрузки внутреннего кластера MNS 1.0. Во-первых, из-за отсутствия централизованных служб управления и контроля в исходной архитектуре невозможно выполнить динамическое разделение и масштабирование кластера и данных. Во-вторых, из-за сильный атрибут согласованности, узлы кластера основаны на сессиях, сайт миграции тяжелее, и легко вызвать цепную реакцию из-за отказа узла.

Из трех аспектов доступности, масштабируемости и производительности MNS 1.0 выявила множество проблем. Основная причина заключается в том, что исходная служба именования, как система CP, в некоторых случаях жертвовала доступностью для достижения «согласованности данных». На самом деле, для служб именования постоянство не так важно. В лучшем случае вызывающий абонент слишком сильно изменился или пропустил службу в течение определенного периода времени. Это последствие связано с предпосылкой ненадежной сети, даже если служба именования делает это. не появляются Проблемы также могут возникать часто. Можно сказать, что благодаря расположенному сбоку механизму самоконтроля его влияние минимально. С другой стороны, если нет проблем с вызывающей стороной и сервером в машинном зале или регионе, но из-за того, что этот регион отключен от основного кластера служб имен, интермодуляция в этом регионе не может быть достигнута. разумно. .

Итак, подводя итоги, мы думаем,Суть службы именования заключается в установлении и расширении возможности подключения самой службы, а не в активном разрушении возможности подключения.. Служба именования должна по существу быть системой AP.

Фактически, в отрасли реализован и применяется режим AP/CP службы имен.Многие предприятия используют режим CP по следующим причинам:

Простое архитектурное поведение: система CP имеет относительно простое поведение при наличии разделов, зависание обработки, грубое, но относительно подверженное ошибкам.
Низкий начальный порог: некоторые зрелые компоненты согласованности с открытым исходным кодом, такие как ZK и etcd, представляют собой системы CP, которые можно использовать «из коробки» и которые могут в основном удовлетворить потребности предприятий, когда масштаб данных находится под контролем.

Кроме того, мы узнали, что некоторые компании используют специальные методы для ослабления этой проблемы, такие как дальнейшее разбиение системы CP на более мелкие домены (например, IDC), уменьшение степени детализации разделов и наличие нескольких глобально автономных систем CP. Конечно, это может быть связано с ограничением пропускной способности поставщика услуг вызывающего абонента или вызовом вспомогательного развертывания, но также может привести к более сложным проблемам (таким как синхронизация данных между системами CP), которые здесь подробно не обсуждаются.

В дополнение к архитектурным дефектам самой MNS 1.0 нам все еще нужно столкнуться с другой проблемой.Когда проект был запущен, облачная нативная концепция все еще находилась в зачаточном состоянии.Теперь некоторые сетевые инфраструктуры, основанные на облачных нативных концепциях, особенно Service Mesh в Meituan Rapid Развитие также требует преобразования MNS для адаптации к новым каналам трафика и компонентам управления, что также является одной из целей этой эволюции MNS 2.0.

Подводя итог, с AP и Mesh в качестве основных целей мы официально начали эволюцию от MNS 1.0 до MNS 2.0.

3. МНС 2.0

1. Общая архитектура

Общая архитектура MNS 2.0 в основном разделена на четыре уровня сверху вниз:

Уровень бизнес-системы: этот уровень похож на архитектуру MNS 1.0.Это по-прежнему SDK или фреймворк, встроенный в бизнес-систему, но он больше не воспринимает списки сервисов и расчеты маршрутизации, поэтому становится тоньше и легче.
Уровень прокси-доступа. Основным изменением на этом уровне является добавление Sidecar и MNS-API Service Mesh. Первый подключает некоторые ссылки службы имен к Mesh, второй добавляет более богатые вызовы HTTP к MNS, помогая некоторым компаниям, которые не используют SDK или фреймворки, быстро получить доступ к службе имен. Преобразование всего уровня доступа через прокси делает MNS более удобным для доступа к службам.
Уровень службы управления: добавлена служба управления реестром, которая также является ядром MNS 2.0. В основном он разделен на следующие три модуля:
- Модуль управления и контроля шлюза: обеспечивает централизованную аутентификацию, ограничение тока/объединение, статистику и другие возможности управления и контроля на основе сервисов SOA, избегая при этом прямого подключения массивных прокси-компонентов к уровню хранения.
- Модуль распределения данных: канал данных, включая загрузку регистрационных данных и распространение данных подписки, может выполнять уточненное разделение данных и параллельное расширение для адаптации к услугам точек доступа.
- Модуль сбора изменений: аудит обнаружения регистрации службы, включая уведомление о событии и обратный вызов сторонним системам, для поддержки разнообразных требований к работе с данными службы.
- Кроме того, уровень службы управления также включает новые подмодули, такие как полноканальный мониторинг SLA, а также традиционные компоненты MNS, такие как сканер проверки работоспособности.
уровень хранения данных: мы дополнительно расширили хранилище и носители для распространения службы имен, повысив общую производительность уровня данных. В основном хранилище используется система хранения K/V (система Meituan Cellar) вместо MNS-ZK, которая эффективно повышает пропускную способность данных, поддерживает чтение и запись данных после сетевых разделов и аварийное восстановление после простоя, сохраняя при этом ZK для некоторой облегченной функции уведомления. Недавно добавленная реляционная база данных и очередь сообщений (система Meituan Mafka) вместе с модулем сбора изменений уровня управления обеспечивают более удобную структуру интеллектуального анализа данных и внешнее разветвление.
В обход верхних 4 уровней входят внешние операционные средства, в основном портал визуализации деловой стороны, где пользователи могут отслеживать и управлять своими собственными службами, а базовый отдел исследований и разработок Meituan также может осуществлять централизованное управление и контроль над ним.

Подводя итог, можно сказать, что общая архитектура MNS 2.0 совместима с 1.0, а ключевые изменения заключаются в следующем: добавление уровня службы управления и демонтаж базового носителя данных. Далее давайте взглянем на процесс реализации функции обнаружения регистрации службы в MNS 2.0:

регистрация службы: уровень доступа агента прозрачно передает запрос на регистрацию бизнеса, и после серии процессов SOA и аудита в модуле управления (шлюзе) уровня службы управления регистрационные данные записываются на уровень хранения.
осведомленность о данных: Управление службой для отслеживания изменений данных.После того, как служба регистрации записывает новую информацию, модуль распространения (Доставка) обновляет кэш в памяти, а поток данных проходит через модуль захвата (CDC) для реляционной обработки регистрационной информации и ее сохранения. в БД.
обнаружение службы: После проверки запроса прокси-уровня управляющим модулем (Шлюзом) службы управления он получает информацию о регистрации сервера пакетами из кэша модуля распределения (Доставка). Чтение данных из уровня хранилища в сценарии Cache Miss.
слой внешнего взаимодействия: внешняя система в настоящее время подключена ко всей системе MNS через уровень прокси, чтобы избежать различных рисков, связанных с хранилищем с прямым подключением. В будущем операционная платформа сможет напрямую использовать данные БД в квазиреальном времени для анализа реляционных данных в режиме OLAP.

Далее давайте взглянем на основные результаты эволюции MNS2.0.

2. Эволюционные результаты

2.1 Пик трафика и параллельное расширение

Пики трафика имеют разные периоды времени для разных доменов. Для сферы O2O, такой как Meituan, это пиковый период для еды на вынос каждый день в полдень, затем каждую ночь будет пик для проживания в отеле и так далее. Конечно, исходя из других бизнес-сценариев, также будут разные пиковые источники. Например, с помощью «маркетинга с использованием ситуации» пиковый объем может оказаться намного выше ожидаемого, что вызовет огромную нагрузку на сервис.

MNS 1.0 подчиняется требованиям верхнего предела количества кластеров MNS-ZK и строгой согласованности и не может обеспечить быстрое и параллельное расширение. В центре внимания уровня хранения данных MNS 2.0 находится обеспечение безопасности данных при чтении, записи и распределенной координации, и к нему не должно предъявляться слишком много требований с точки зрения масштабируемости. Возможность параллельного расширения MNS 2.0 в основном отражается на уровне службы управления, и его конкретные функции включают следующие два аспекта:

Разделение кластера: служба управления обеспечивает возможность сегментирования полных регистрационных данных, что устраняет риск того, что служба имен не сможет изолировать бизнес-линию, когда она развернута в одном большом кластере. Модуль шлюза MNS-Control разделен на две роли: Master и Shard, которые взаимодействуют друг с другом для обеспечения больших возможностей сегментирования кластера.

Master: поддерживать связь между информацией о регистрации службы и каждым кластером осколков (Shard) и предоставлять этот тип метаданных компонентам прокси-уровня. Мастер получает каждое событие кластера сегмента, добавляет и очищает регистрационную информацию, хранящуюся в сегменте.
Shard: Разделение данных автономно обеспечивает функции регистрации/обнаружения службы для прокси-компонента, реализует изоляцию служб именования в соответствии с бизнес-направлениями и корректирует содержимое поддерживаемой регистрационной информации в соответствии с инструкциями, изданными Мастером.
Services: бизнес-служба получает доступ к MNS через прокси-компонент. Когда прокси-компонент запускается, он взаимодействует с главным сервером, чтобы узнать информацию о сегментном кластере, к которому он принадлежит, и резервные меры. После этого Агент взаимодействует только с именованными данными Шарда бизнес-направления до тех пор, пока кластер Шарда не станет недоступным, и повторно выполняет процесс «самообнаружения».
Запасные меры: Установите кластер осколков по умолчанию, который предоставляет полную информацию об обслуживании, когда сегмент бизнес-линии неисправен. С одной стороны, агент перезапускает процесс «самообнаружения» и перенаправляет запрос на имя в кластер шардов по умолчанию до тех пор, пока шард бизнес-линии не будет восстановлен, а затем трафик переключается обратно.

сетевой раздел доступен: На этапе MNS 1.0 сетевые разделы оказывают огромное влияние на доступность, и MNS-ZK напрямую отказывается от обслуживания после разделения. После того, как новая архитектура перенесет хранилище в систему KV, каждая область по-прежнему может обеспечивать функцию чтения данных в обычном режиме в экстремальных условиях, таких как джиттер выделенной сети. В то же время мы работаем с группой хранения данных компании над созданием региональных функций чтения и записи C++ SDK. С одной стороны, это повышает производительность междоменной регистрации и обнаружения служб, а с другой стороны, после разделения сети цель сделать службы имен доступными для чтения и записи в каждом регионе повышает доступность системы и снижает чувствительность весь сервис имен в сети.

В настоящее время уровень службы управления достиг минутного уровня с точки зрения времени параллельного расширения и сжатия и времени восстановления кластера на месте, и кластер не имеет верхнего предела узлов, поэтому он может эффективно справляться с внезапным трафиком и предотвращать «лавина» услуг.

2.2 Push Storm и повышение производительности

Другим типичным сценарием является толчковый «шторм», который в случае централизованной публикации сервисов и джиттера сети и т. п. приведет к двум типам эффектов усиления «одной горизонтали и одной вертикали» в службе имен: «сосредоточьтесь на масштабировании», подобно сообщению «Большой V» в социальной сети, которое необходимо распространить среди большого числа поклонников. Вертикаль представляет собой «каскадное усиление». Восходящий и нисходящий поток службы имен будут копироваться и отправляться уровень за уровнем, и даже восходящий и нисходящий потоки первого уровня будут иметь несколько взаимодействий (уведомление + получение) для сообщения.

Неизбежны как «усиление внимания», так и «каскадное усиление», которые определяются свойствами системы, и что мы можем сделать, так это сгладить эффекты с двух сторон:

Положительно улучшите производительность основного модуля, увеличьте пропускную способность и уменьшите задержку

Структурированная агрегированная регистрационная информация: модуль распределения данных, который управляет службой, хранит структурированную регистрационную информацию службы в памяти и обеспечивает возможность считывания пакетных данных; сокращает время, затрачиваемое на многократную сетевую RTT-передачу одиночных данных и преобразование структуры данных. 2. Высокая пропускная способность параллелизма. Служба управления обрабатывает конфликты критических путей посредством программирования без блокировок и обеспечивает распределение данных с высокой степенью параллелизма и малой задержкой с помощью механизма сопрограмм на стороне приложения.
Создан совместно с командой хранения для реализации чтения и записи в близлежащей области системы KV, а также для повышения производительности регистрации службы (записи данных) службы именования.

Кроме того, включение возможности параллельного расширения кластера службы управления, упомянутого выше, на самом деле является способом повышения общей производительности.

Боковые углубления, различение «горячих» и «холодных» данных, уменьшение объема передаваемых данных и повышение производительности.

«Правило 80/20» распространено повсеместно, и службы имен не являются исключением. Среди элементов в структуре регистрационной информации службы 80 % изменений приходится в основном на 20 % участников, и типичным является статус службы. Поэтому мы разделяем один блок структуры служебной информации на несколько более мелких структур для отдельного хранения; когда происходят изменения данных, соответствующие новые структуры распределяются по запросу, что может уменьшить объем передаваемых данных и эффективно уменьшить занимаемую полосу пропускания сети, избегая Накладные расходы ЦП, вызванные повторным вычислением прокси-компонента, и накладные расходы памяти также значительно снижаются после того, как структура данных становится меньше.

Нужно ли полностью «обновлять по требованию» и добавлять только те элементы, которые изменяются в структуре данных? Мы считаем, что полное «обновление по требованию» требует очень тонкого архитектурного проектирования и вводит дополнительные вычислительные затраты на хранение. Например, нам нужно хранить изменяющиеся элементы отдельно, чтобы реализовать детализированные наблюдатели, или использовать специализированные сервисы для идентификации изменяющихся элементов и отправки их.

В то же время также необходимо следить за тем, чтобы при смене разных участников push каждый раз был успешным, иначе возникнут такие проблемы, как несогласованность. Когда данные, требуемые логикой расчета компонента, изменяются, это также приведет к дополнительным изменениям. В большой распределенной системе, такой как служба имен, «сложность» и «изменчивость» означают снижение стабильности и увеличение риска. Поэтому, согласно «правилу 80/20», мы разделяем горячие и холодные данные с разумной шкалой, что является результатом взвешивания эффективности и риска программы.

После преобразования пропускная способность MNS 2.0 была улучшена более чем в 8 раз по сравнению с MNS 1.0, процент успешных push-уведомлений увеличился с 96% до 99%+, среднее время, затрачиваемое на обнаружение службы для списка 1K услуг, было уменьшено с 10 с до 1 с, а TP999 уменьшено с 90 с. К 10 с общий эффект оптимизации очень очевиден.

2.3 Интеграция в Service Mesh

В MNS 2.0 мы объединили функции регистрации и обнаружения прокси-сервиса SgAgent с плоскостью данных Mesh.Процесс показан на следующем рисунке:

Что касается технических деталей комбинации функции управления услугами Meituan и Service Mesh, мы создадим отдельную тему, чтобы поделиться этой частью контента в этом году.Заинтересованные студенты могут обратить внимание на общедоступную учетную запись WeChat «Техническая команда Meituan», так что оставайтесь настроен.

2.4 Миграция без потерь

Помимо этих ключевых результатов эволюции MNS 2.0, упомянутых выше, мы также хотим поговорить о процессе миграции всей службы имен. Крупномасштабная распределенная система, такая как MNS, которая включает в себя несколько компонентов, развернута на сотнях тысяч машинных узлов в компании и поддерживает десятки тысяч бизнес-систем, как выполнить плавную миграцию данных, не прерывая нормальные бизнес-сервисы, или даже позволить бизнесу воспринимать , является ключевым моментом дизайна MNS 2.0. Сосредоточившись на требованиях неосведомленности о бизнес-сервисах, возможности быстрого отката и отсутствии потери данных при взаимном резервном копировании новых/старых систем, мы разработали процесс миграции, как показано на следующем рисунке:

В целом, MNS 2.0 выполняет операцию миграции со службой в качестве гранулярности.Бит флага устанавливается для указания состояния службы, а компонент уровня агента доступа идентифицирует флаг и выполняет соответствующую обработку. Флаги включают:

Флаг «Не перенесено»: регистрация/обнаружение службы выполняется в соответствии с процессом MNS 1.0, а регистрационная информация хранится в MNS-ZK перед реконструкцией.
Флаг миграции: выполняются процессы регистрации службы и MNS 1.0 и MNS 2.0, данные записываются в новое и старое места одновременно, а обнаружение службы выполняет процесс MNS 2.0.
Флаг миграции: регистрация/обнаружение службы следуют процессу MNS 2.0, а регистрационная информация хранится только на уровне данных MNS 2.0. Этот этап не может быть плавно откатан и является окончательным состоянием миграции после длительной проверки проекта.

Вышеизложенное можно резюмировать следующим образом:Сосредоточьтесь на одной услуге, поэтапно переносите трафик обнаружения служб, чтобы добиться возможности «оттенка серого в Интернете» при выпуске новых функций системы.. Конечно, эта стратегия также включает в себя некоторые детали.Например, необходимо сосредоточиться на обеспечении эвентуальной согласованности в нештатных ситуациях, когда он хранится отдельно в двойной записи.Из соображений объема мы не будем здесь подробно обсуждаться, и отрасль нацелена на такого рода ситуация имеет некоторые зрелые практики.

Кроме того, оптимизировав форму выпуска системы выпуска службы имен, мы реализовали стратегию автоматической передачи трафика в оттенках серого, сократив трудозатраты, и в то же время мы создали инструменты автоматической миграции и инструменты проверки для эффективной автоматизации работы по миграции данных. который может быстро проверить риски канала после миграции, чтобы обеспечить стабильный запуск нового MNS 2.0.

2.5 Резюме эволюции

В процессе оптимизации крупномасштабной распределенной системы, такой как служба имен Meituan, мы также пошли на множество компромиссов с точки зрения архитектуры и функционального дизайна.Как мы упоминали ранее, мы отказались от постепенное точное изменение информации push.way. Исходя из соображений производительности, MySQL, обладающая лучшими возможностями работы с многомерными данными, не используется в качестве основного средства доступа и так далее. Основной принцип компромисса состоит в том, чтобы подчеркнуть преимущества для бизнеса при преобразовании цели и уменьшить восприятие бизнеса в процессе внедрения.

В настоящее время основными достижениями MNS 2.0 являются следующие:

Реконструировали 5 существующих основных компонентов, разработали 2 новые системы и завершили адаптацию и трансформацию десятков сервисов на уровне PaaS компании.В настоящее время более 80% сервисов компании успешно мигрированы, и в процессе миграции Есть крупных аварий не было.
RTO было уменьшено с часов до минут, RPO равно 0; время полносвязной отправки TP999 сократилось с 90 до 10 секунд, а показатель успешности отправки увеличился с 96 % до более чем 99 %, что в основном завершает создание сервиса уровня миллиона. возможности управления узлом.
Кластерные данные разделены в соответствии с несколькими измерениями, такими как бизнес-направления, и установлены индикаторы SLA и механизмы регулярной проверки на основе градуированной окраски.В то же время многие функции контроля и аудита сервисных рисков добавляются в соответствии с реальными сценариями компании, безопасность.
С точки зрения собственного облака, поддерживается Service Mesh, а процесс регистрации и обнаружения интегрирован в базовую инфраструктуру Mesh.

В-четвертых, расширение возможностей услуг именования для бизнеса

Сама служба именования служит базовым техническим промежуточным офисом.Придерживаясь «ориентированности на клиента» и модернизируя собственную структуру, она также расширяет возможности нескольких предприятий Meituan в следующих аспектах.

4.1 Юнитизация и плавательные дорожки

Unitization (SET) — это популярное в отрасли решение для расширения аварийного восстановления.Подробности об объединении Meituan см. в другой теме, которой поделилась команда OCTO на этом ArchSummit «Технология SET и расшифровка практики обзора Meituan». Здесь в основном ответ на этот вопрос с точки зрения поддержки унификации службой имен.

Как показано на рисунке выше, после того, как внешний сетевой трафик из различных источников бизнеса попадет во внутреннюю сеть через шлюз, он будет использовать возможности (SDK/агент), предоставляемые службой имен, и маркировать трафик в соответствии с ядром. Измерения данных и атрибуты компьютеров, настроенные бизнесом Унифицированные метки, а затем маршрутизация к следующему переходу с соответствующими метками, таким образом реализуя изоляцию трафика между единицами. Внутри единицы, от сервисных узлов до различных компонентов хранения, все полагаются на возможности идентификации и маршрутизации, предоставляемые службой именования для завершения изоляции, поэтому служба именования в основном играет роль базовой поддержки в унификации. В настоящее время ключевые бизнесы юнитизации в Meituan, такие как вынос и дистрибуция, выстроены относительно хорошо.При определенной избыточности юнитов, когда возникает проблема в одном юните, его можно переключить на другой доступный зеркальный юнит, что значительно улучшило общую доступность бизнеса.

Далее, давайте взглянем на сцену с дорожкой. В настоящее время дорожка для плавания в основном используется на этапе автономного интеграционного тестирования после того, как бизнес завершил код UT.В то же время в сочетании с контейнером реализуется готовая и работающая среда восходящего и нисходящего вызовов для проверки логики. . Роль службы именования аналогична роли унификации: в соответствии с конфигурацией машины платформой публикации дорожки восходящие и нисходящие отношения вызова устанавливаются автоматически. Как показано ниже:

Когда для следующего перехода существует узел дорожки, тестовый трафик входит в дорожку. Вместо этого тестовый трафик возвращается в магистраль. Повторите вышеуказанный процесс для каждого узла.

4.2 Плавное высвобождение и эластичное масштабирование

Другим важным сценарием услуг именования является плавный выпуск услуг.Мы сотрудничаем с платформой публикации, чтобы контролировать автоматическое удаление и восстановление трафика публикации, а также реализовать автоматизацию и прозрачность операций публикации услуг. Конкретный процесс показан на следующем рисунке:

В процессе раннего выпуска существует риск аномальных вызовов. Во время онлайн-процесса существует «временное окно», когда экземпляр службы недоступен. В это время повторный ввод трафика может привести к сбою вызова и то будет сообщено об ошибке. Чтобы обеспечить стабильность выпуска, операторам необходимо вручную очищать поток, что неэффективно и подвержено ошибкам в процессе и тратит время бизнес-группы. В ответ на эту проблему бизнеса служба именования предоставляет системе публикации возможность управлять и контролировать трафик экземпляров службы. Она может автоматически удалять и очищать исходный запрос перед перезапуском процесса. После завершения обновления она предоставляет плавная функция публикации с автоматическим восстановлением трафика. Разумно решите проблему ненормального вызова в процессе выпуска, повысьте эффективность онлайн-сервиса компании и сократите затраты на эксплуатацию и обслуживание бизнес-группы.

Эластичное масштабирование — большое преимущество контейнеров. Однако в процессе масштабирования необходимо учитывать множество вопросов, таких как стратегии масштабирования, в том числе конфигурация привязки вызовов, балансировка маршрутизации и т. д. Служба именования взаимодействует с контейнеризацией для предоставления таких услуг, как восходящие и нисходящие отношения вызова, группировка информации о настройках и неразрушающее удаление автономного трафика контейнера, обеспечивая при этом своевременную и эффективную регистрацию служб масштабирования. Как показано ниже:

4.3 Служебные данные

Предоставление бизнесу данных службы MNS в основном делится на две части: первая заключается в раскрытии рабочего состояния службы MNS в понятном соглашении об уровне обслуживания, которое удобно для бизнеса, чтобы оценить состояние работоспособности службы имен. Для службы имен показатели SLA в основном включают в себя процент успешных push-уведомлений и время push-уведомлений (на самом деле время push также можно рассматривать как меру показателя успешности, и мы пока не будем проводить здесь слишком детальных различий). ).

Трудность точной количественной оценки рабочего состояния MNS 1.0 заключается в том, что, с одной стороны, механизм публикации/подписки MNS сильно зависит от ZK, который ограничен реализацией самого ZK и неоднородностью многих различных компонентов на ссылка, так что данные о поведении полной ссылки могут быть получены вовремя. Очень сложно. С другой стороны, из-за большого количества узлов полный сбор данных об обнаружении сервисов также является большой нагрузкой для системы мониторинга и отчетности компании, а также для расчетов после сбора.

В MNS 2.0 мы впервые значительно ослабили позиции ZK в архитектуре, и он в основном служит лишь компонентом уведомления о согласованности. Наша собственная разработка MNS-Control может полностью самостоятельно реализовать встроенную точечную сцену, обеспечивая управляемость захвата основного поведения нажатия. Во-вторых, мы внедрили расчет иерархической выборки.После всестороннего анализа соотношения количества существующих сервисных узлов в компании, типичный номер списка услуг делится на несколько классов.Например,1000 узлов-это один класс, а 100 узлов-другой класс. создать соответствующую некоммерческую дозорную службу, а затем выбрать соответствующее количество машин для выборки в разных компьютерных залах для регулярной регистрации + извлечения для оценки общей работы. Это не только обеспечивает упрощение сообщаемой суммы, но также учитывает достоверность сообщаемых данных. Подробный процесс работы показан на следующем рисунке:

Уровень управления периодически изменяет данные службы в службе выборки, запуская процесс отправки данных для обнаружения службы. Для машинных узлов, участвующих в статистике индикатора, после того, как процесс локального агента получает регистрационную информацию и отправляет ее, он сообщает о времени доставки на платформу эксплуатации и обслуживания и записывает ее на уровень хранения. Уровень управления агрегирует и вычисляет данные в базе данных и, наконец, передает данные индикатора в систему мониторинга. Кроме того, благодаря сотрудничеству с группой мониторинга решается проблема мониторинга полностью развернутой скрытой точки Агента.

Служебная информация, хранимая службой имен, имеет высокую ценность для бизнеса, из которой вы можете узнать о развертывании службы, частоте выпуска, а также информацию о топологии восходящего и нисходящего потоков. Следовательно, вторая часть «включения» заключается в том, что с помощью этой информации мы можем откопать необоснованные места или точки риска в развертывании, эксплуатации и обслуживании бизнес-сервисов и постоянно продвигать оптимизацию, чтобы избежать ненужных потерь. Среди уже реализуемых проектов:

Однопроцессное многопортовое преобразование: предприятия используют этот метод для различения различных портов вызовов, что приводит к пустой трате ресурсов портов, а нижестоящим по цепочке вызовов необходимо получать информацию о развертывании. облачная эра. Мы помогаем бизнесу изменить поведение вызова в форме одного порта и нескольких интерфейсов, а также выделить логику вызова в протоколе.
Разделение большого списка услуг: с развитием бизнеса количество узлов одной службы резко увеличилось, и даже у службы есть количество узлов, близкое к 7 Вт, что оказывает большое влияние на базовые средства, такие как как публикация, мониторинг и управление услугами. Благодаря общению с бизнесом мы обнаружили, что есть две основные причины большого списка: 1. Производительности одной машины недостаточно, и противостоять ей может только экземпляр; 2. Сервисный контент недостаточно сфокусирован. . Другими словами, поскольку служба недостаточно «микро», логика становится все больше и больше, соответственно увеличивается количество вызывающих и нуждающихся экземпляров, а также увеличивается риск кода. Поэтому мы прочесали и проанализировали структуру и вызов вместе с бизнесом, отделили основные общие модули от группы бизнес-логики, сократили избыточный вызов и, наконец, сократили количество некоторых крупных сервисных узлов с десятков тысяч до тысяч, добившись порядка уменьшения величины.
Сбалансированное развертывание восходящего и нисходящего потоков: это относительно легко понять.В сочетании с такой информацией, как отношение вызывающего абонента к серверу, производительность машины сервера и частота отказов вызовов, его можно использовать в качестве эталона для обслуживающий бизнес, чтобы сбалансировать количество машин в каждом машинном зале. С другой стороны, мы также уменьшаем детализацию базовой стратегии вызова поблизости.В настоящее время сохраняются только два типа «тот же IDC» и «тот же город», а предыдущая «стратегия того же центра» была удалена, чтобы уменьшить умственное бремя развертывания бизнес-сервисов. На более позднем этапе, с сокращением количества компьютерных залов и контролируемой задержкой компьютерных залов в одном регионе, окончательным решением может стать внутригородская маршрутизация.

С точки зрения архитектуры, MNS 2.0 опирается на БД и другие носители хранилища данных для свертки и детализации данных в нескольких измерениях, а также сочетает в себе некоторую настраиваемую логику стратегии управления рисками, помогающую компаниям обнаруживать и избегать проблем, которые в настоящее время находятся в процессе .

V. Перспективы будущего

В дальнейшем сервис нейминга Meituan в основном будет развиваться в двух направлениях:

Продолжайте собирать и анализировать ценность сервисных данных, создавать платформу сервисных данных и расширять возможности бизнес-модернизаций. От простого понимания потребностей в регистрации бизнеса и обнаружения маршрутов до содействия трансформации и модернизации процессов бизнес-архитектуры посредством реверса данных — это также является проявлением основной ценности Meituan — «ориентированность на клиента».
Он глубоко интегрирован с эволюцией облачной инфраструктуры, такой как Service Mesh. Быстрое развитие облачных концепций и связанной с ними архитектуры объектов неизбежно приведет к изменениям в процессе традиционных компонентов управления службами. услуги по именованию. .

об авторе

Шу Чао, старший технический эксперт Meituan, основной член группы управления услугами OCTO по исследованиям и разработкам.
Чжан Сян, старший инженер Meituan, основной член группы управления услугами Meituan OCTO по исследованиям и разработкам.

Предложения о работе

Команда управления услугами Meituan OCTO ищет старших инженеров и технических экспертов C++/Java. Мы стремимся к исследованиям и разработке ведущих в отрасли компонентов инфраструктуры на уровне компании, охватывающих распределенные платформы, службы именования, сервисную сетку и другие технические области. Заинтересованные студенты могут отправлять свои резюме по адресу tech@meituan.com (почтовое примечание: команда Meituan OCTO).

Чтобы прочитать больше технических статей, отсканируйте код, чтобы подписаться на общедоступную учетную запись WeChat — техническая команда Meituan!