Практика эволюции архитектуры системы доставки Meituan

написать впереди

С момента своего создания Meituan Delivery претерпела множество рывков в своем бизнесе. Быстрый рост бизнеса выдвигал все более высокие требования к общей архитектуре и инфраструктуре системы.В то же время он также постоянно побуждал техническую группу к глубокому пониманию бизнеса, точному определению модели предметной области и эффективной поддержке. расширение системы. Как добиться быстрого и эффективного обновления архитектуры системы в условиях быстрого роста бизнеса и повышения доступности? Как обеспечить эффективность и качество НИОКР в условиях сложного бизнеса? В этой статье будут представлены некоторые мысли и методы доставки Meituan.

Дистрибьюторский бизнес

От логистики до мгновенной доставки в том же городе

Развитие логистической отрасли неотделимо от развития коммерции, трансформация которой в последние годы создала новые возможности для развития логистики. Рост электронной коммерции фактически способствовал быстрому развитию индустрии экспресс-доставки, непосредственно создавая компании экспресс-доставки, такие как SF Express и Stone Express. В последние годы рост бизнес-модели O2O, особенно разработка сценариев доставки на дом, таких как еда на вынос и свежие продукты, способствовал быстрому развитию доставки в режиме реального времени в одном и том же городе.

В отличие от других направлений в сфере логистики, мгновенная доставка в пределах одного города имеет следующие характеристики:

• Быстрое старение: Среднее время доставки Meituan составляет 28 минут.
• короткая дистанция: Большинство расстояний доставки находятся в пределах 3-5 км, а большие расстояния доставляются в один и тот же город.
• Сильная случайность: Пункт выдачи и пункт доставки случайны во времени и пространстве, а сложность прогнозирования и планирования относительно высока.

Возможности для развития бизнеса мгновенной доставки в том же городе

Реинжиниринг процессов в отрасли, как правило, неотделим от двух факторов:

• Внутреннее: крупные прорывы в технологиях или инфраструктуре.
• Внешние факторы: повышение потребительского спроса или серьезные изменения на рынке.

С точки зрения технологий, применение ИИ и больших данных постепенно популяризируется, и на основе искусственного интеллекта можно точно оценить сложность распределения, ожидаемое время прибытия и возможности гонщика. Быстрое развитие GPS и постоянное открытие возможностей производителей ГИС значительно снизили стоимость разработки приложений на основе LBS. С точки зрения инфраструктуры, благодаря постоянным инвестициям государства, качество мобильных сетей постоянно улучшалось, а стоимость снижалась из года в год, что косвенно способствовало практически повсеместному охвату смартфонами.

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

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

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

технические проблемы

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

• Онлайн-исполнение предъявляет более высокие требования к SLA. Дистрибьюторский бизнес должен учитывать интересы пользователей, продавцов и пассажиров, и последствия любого простоя могут быть катастрофическими. Если опыт не очень хороший, пользователи скажут, почему я все еще голоден, когда я заплатил? Торговец скажет, что это потому, что никто не берет еду, а всадник почувствует, что потратил время и труд, не получив достаточного дохода.
• Оффлайн-бизнес сложнее. Режимы управления нескольких бизнес-направлений различны, и очень сложно принять во внимание общность и дифференциацию системы.

Эволюция системной архитектуры

Эволюцию архитектуры системы доставки Meituan можно разделить на три этапа:

1. Стадия MVP: исследование бизнес-модели, быстрые пробы и ошибки, как иметь возможность быстро выполнять итерации.
2. Стадия масштабирования: бизнес вырос в геометрической прогрессии Как обеспечить развитие бизнеса и решить такие проблемы, как доступность системы, масштабируемость и эффективность НИОКР.
3. Стадия уточнения: бизнес-модель постепенно созревает, операции постепенно совершенствуются, и как стимулировать развитие бизнеса с помощью инноваций в области продуктов.

Стадия лучшего игрока

На этапе проб и ошибок необходимо быстро выяснить, соответствует ли бизнес-модель тому же направлению.На этом этапе не ждите, что вы будете ясно думать о многих вещах, и пользователи и рынок быстро обратят внимание на результаты. Поэтому для технической команды главная способность на данном этапе — быть быстрым. Чтобы захватить рынок, только быстро не срывается.

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

Кстати, отмечу организационную форму команды того времени: команда R&D организована по системе проектов, и все поддерживают систему вместе. На тот момент в команде не было должности QA, а PM и RD совместно обеспечивали качество разработки, выпуск более 20 раз в день был нормой.

масштабная сцена

На данном этапе бизнес и продукты прошли предварительную проверку рынком, и верное направление действительно найдено. В то же время темпы роста развития бизнеса также выдвигают более высокие требования к возможностям команды R&D, ведь на этом этапе будет возникать большое количество срочных и важных дел, а проблемы в доступности и масштабируемости системы постепенно станут заметными. Это приведет к частым системным сбоям и низкой эффективности НИОКР, что приведет к истощению НИОКР.

На этом этапе мы сосредоточимся на размышлении о трех аспектах с архитектурного уровня:

• Как должна развиваться общая архитектура? Где проходит граница между комплаенс-системой и операционной системой?
• Как наличие системы соответствия гарантирована? Как планировать емкость системы?
• Как операционная система решает настоящие болевые точки бизнеса? Как повысить эффективность НИОКР при большом количестве «тривиальных потребностей»?

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

Общий архитектурный дизайн

В общей структуре мы разбираем систему распределения на систему исполнения контрактов, операционную систему и платформу мастер-данных.

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

Операционная система(Верхняя левая часть рисунка) С точки зрения долгосрочного спроса необходимо четко подумать о том, чем должна и не должна управлять операционная система распределения. В долгосрочной разработке проекта, начиная с бизнес-стратегии и организационной структуры и уточняя бизнес-стратегические цели и стратегии этапов, мы определяем основные обязанности, цели оценки и процессы сотрудничества между организациями для каждой бизнес-группы/должности, и наконец организуются и появляются Четыре области находятся в центре управления этапами дистрибуции:

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

В дополнение к архитектурному дизайну двух систем эффективности и эксплуатации контракта, существует также очень важнейшая проблема на уровне архитектурного дизайна, то есть как разделить границы и обязанности систем эффективности договора и эксплуатации. Лично я понимаю, что эта проблема может быть наиболее важнейшей проблемой архитектурной конструкции на этапе масштабирования бизнеса O2O. Если его нельзя эффективно решено, он будет оказывать огромную скрытую опасность для использования и масштабируемости системы. Бизнес-требования и технические обязанности в двух направлениях эффективности и эксплуатации договора являются совершенно разными, и большинство продуктов данных находится в операционной системе, а наиболее основное и критическое приложение находится в системе производительности контракта. Хотя их соответствующие обязанности домена ясны, границы конкретных требований не обязательно просты. В связи с этим мы опираемся на идею MDM и выдвинулиплатформа основных данных(нижняя часть рисунка), фокусирующаяся на решении проблем сотрудничества и границ между системой производительности и операционной системой.

платформа основных данных

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

1. Фундаментальный: бизнес-данные растут по размеру основных данных, например: данные заказа — это данные транзакции в двух объектах основных данных пользователя и продавца.
2. Совместное использование: различные системы сильно зависят от основных данных, а вышестоящие бизнес-системы должны воспринимать и связывать изменения в основных данных.

Управление основными данными не достигается в одночасье, но итеративно развивается с развитием бизнеса. Ранние системы были более простыми, а восходящие системы читают данные непосредственно из БД и применили их. После того, как система постепенно сложная, это решение склонна к взаимному влиянию многочисленных групповых разработок, что не способствует расширению системы и имеет большой риск с точки зрения наличия. По этой причине наша специально созданная команда Master Data самостоятельно разделила службу основных данных и восстановила весь доступ к данным на службу. На этой основе после непрерывной итерации и эволюции мы, наконец, впитываем идеи CQRS (сегрегация на ответ на запрос на командование) и MDM (Master Management Data) и постепенно разделены на весь мастер-платформенную платформу на четыре части:

• Производственная система: отвечает за моделирование производства данных и выделение влияния производства данных на основную модель. Например: адаптация гонщика, процесс разделения организации и т. д.
• Базовая модель: изучение взаимосвязей сущностей данных для улучшения возможностей модели. Например: один человек с несколькими постами, двухстрочный репортаж и т. д.
• Центр емкости: поддержка сценариев применения системы исполнения контрактов, абстрагирование многих атрибутов гонщика в модель емкости и сосредоточение внимания на построении удобства использования и пропускной способности.
• Центр управления: обеспечивает стандартизированную структуру для операционных систем и предоставляет унифицированные решения для таких сценариев, как поиск информации, утверждение процессов и контроль полномочий.

доступность системы

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

Повышение доступности — это долгосрочный проект. Принимая во внимание рентабельность инвестиций, сосредоточьтесь на завершении начального этапа процесса строительства заранее, что проводы - и ряд оперативных онлайн-процессов, это может работать в начале онлайн, чтобы избежать 80% отказов. Пройдя через стандартизированные процессы и доказав свою эффективность, люди постепенно повышают эффективность за счет построения системы.

Возможность аварийного восстановления

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

На втором этапе мы предлагаем возможность сквозного аварийного восстановления. Во-первых, мы построили бизнес-рынок и определили мониторинг основных бизнес-показателей в режиме реального времени (единичный объем, количество онлайн-райдеров и т. д.), благодаря которому мы можем быстро судитьЕсть проблема с системой. Во-вторых, мы расширили ключевые параметры (город, версия приложения, оператор и т. д.) для основных показателей для быстрой оценки.Насколько велика проблема. Наконец, мы используем систему трассировки для визуализации вызывающей связи между службами и скоростью успеха уровня связи, позволяя быстрому позиционированию.где корень проблемыСпособность.

На третьем этапе мы планируем интегрировать план аварийного восстановления в систему и создать индивидуальные и интегрированные инструменты аварийного восстановления на основе различных сценариев аварий, что может еще больше сократить время реагирования на сбои, время обработки и затраты на обучение НИОКР. Например, чтобы еще больше улучшить SLA системы распределения, мы глубоко оптимизировали возможность сквозного аварийного восстановления, сосредоточившись на решении проблемы сквозного взаимодействия, когда у гонщика слабая сеть или ее нет. В некоторых районах Китая очень плотное скопление людей, но качество сети мобильных операторов оставляет желать лучшего, что приведет к тому, что водитель будет работать с приложением после прибытия в этот район с большой задержкой или даже с неработоспособностью, что оказывает большое влияние на нормальная работа райдера. Таким образом, на уровне соединения мобильной сети мы продолжаем укреплять возможности длительного соединения и многоканального взаимного резервного копирования, а также интегрируем инструменты сетевой диагностики, обработки и проверки, чтобы сквозная скорость прибытия приложения гонщика был дополнительно улучшен.

Емкость системы

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

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

Что касается расширения мощностей, мы реализовывали его поэтапно.избыточное резервное копирование(разделение ведущий-ведомый),вертикальное разделение(разделить основные атрибуты и неосновные атрибуты),разделить по горизонтали(подбиблиотека и подтаблица),Автоматическая подача.

Эффективность итерации операционной системы

Операционная система включает в себя все аспекты управления бизнес-операциями.Цель,процесс,емкость,фондыВ дополнение к четырем направлениям был создан набор операционных системных интеграционных решений. Благодаря непрерывным инвестициям в долгосрочное создание сервисов или компонентов платформы, исследования и разработки обеспечивают масштабируемость каждой вертикальной операционной системы, тем самым постоянно повышая эффективность исследований и разработок. Возьмем в качестве примера сценарий рабочего процесса.динамическая форма + Технологическая платформаОн объединяет инженерную реализацию различных бизнес-потоков и потоков согласований, количественно определяет эффективность и качество различных управленческих действий, находит узлы блокировки процессов, автоматизирует некоторые звенья процессов, непрерывно снижает трудозатраты за счет технических средств.

этап уточнения

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

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

платформа моделирования

Ядром платформы моделирования является создание «песочницы».Атрибут индустрии услуг, связанный с распространением, требует от пользователей, продавцов и райдеров активного участия в процессе обслуживания, поэтому стоимость алгоритма проб и ошибок в Интернете чрезвычайно высока. Для построения платформы моделирования мы удалили детали системы планирования и построили систему микропланирования в крупнозернистой форме.воспроизведение счета,Моделирование сущности пользователя, продавца, пассажира,Моделирование поведения всадникаи другие методы моделирования онлайн-сценариев. Каждое моделирование будет генерировать отчет KPI алгоритма для автономной оценки эффекта алгоритма.

Платформа алгоритмических данных

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

Платформа LBS

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

Эпилог

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

об авторе

Йонг Джун, старший технический эксперт Meituan, руководитель группы бизнес-систем распределения. Он долгое время занимался обеспечением качества распределительных систем, построением операционных систем и обновлением системной архитектуры.

Набор персонала

Эта статья является кристаллизацией коллективного разума технической команды доставки Meituan, и я хотел бы поблагодарить каждого члена команды за их усердную работу. Если вас интересуют бизнес-анализ и модели предметной области, обращайтесь по адресу yinyongjun@meituan.com.