Анализ архитектуры системы заказов торговой платформы Baidu

Управляемое чтение: Являясь инфраструктурой мобильной экологической стратегии группы, транзакционный центр Baidu ориентирован на кассовые операции и сценарии клиринга и расчетов, обеспечивая эффективную транзакционную экосистему для поддержки бизнеса. В настоящее время он поддерживает несколько линеек продуктов в системе Baidu, в основном в том числе: мини-программы, Map Taxi, Baijiahao, Lucky Cat, красивое видео и т. д. В этой статье в основном представлен процесс построения системы заказов с двух аспектов: бизнес-модели и проектирования архитектуры.

**один,**Какими возможностями должна обладать система заказов?

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

Способность системы заказов можно разрезать и разбирать в соответствии со следующими тремя углами:

Перспектива пользователя: расчет оплаты, заказ пользователя, отслеживание логистики, возврат средств, поиск заказа и т. д .;
Бизнес-перспектива: управление статусом заказа, разделение заказов продавца, послепродажное управление жалобами клиентов и т. д.;
Перспектива платформы: Скольжение, комиссия CPS, контроль ветра, анти-грудь и т. Д.

2. Как операционный центр предоставляет услуги?

Центр транзакций абстрагируется и классифицируется на основе существующего бизнеса и в основном делится на следующие три типа доступа:

Универсальный: компания сама хранит такую информацию, как информация о товарах и запасах, и ей нужно только вызвать систему заказов для агрегированного платежа. Система заказов будет обеспечивать функциональную поддержку, такую как маркетинг, возврат средств, отсутствие пароля, продвижение по службе, разделение счетов, клиринг, сверку, контроль рисков и другие функции в соответствии с потребностями бизнеса.
автономный: Система заказов обеспечивает полную поддержку возможностей электронной коммерции, включая продукты, инвентарь, маркетинг, возмещение, послепродажное обслуживание, поиск, отслеживание логистики и другую функциональную поддержку.Основные предприятия включают: Lucky Cat, Kua Kua Dou и т. д.
прямая связь: Бизнес вызывает канал для оплаты. После завершения платежа информация о заказе синхронизируется с системой заказов. Система заказов рассчитывает информацию о продвижении для мастера трафика (в том числе: якорь, автор продвижения, платформа и т. д.). основной бизнес: Dangdang, Amazon.

На приведенном выше рисунке показано сравнение ключевых звеньев обычного бизнеса и собственного бизнеса. можно увидеть:

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

3. Жизненный цикл и процесс заказа

В обычных ссылках электронной коммерции после создания заказа он в основном включает подтверждение заказа, оплату, доставку, успех, отмену, возврат и т. Д. Эти состояния представляют собой конечный автомат.

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

3.1 Процесс авансового платежа

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

Вход: На приведенном выше рисунке четко видно, что заказы могут генерироваться с нескольких порталов, включая обычные мобильные устройства, веб-сайты, коды сканирования и т. д .;
формирование заказа: когда пользователь подтверждает заказ, система заказов должна координировать несколько нижестоящих систем, таких как товары, маркетинг, инвентаризация и контроль рисков для подтверждения;
Выбор канала оплаты: После того, как заказ будет создан, пользователь перейдет к интерфейсу оплаты. В это время система заказов предоставит общие каналы оплаты, которые пользователь может выбрать для обработки. Общие каналы оплаты, такие как WeChat, Alipay, оплата Duxiaoman и т. д. y все интегрированы в систему заказов;
оплата прошла успешно: после того, как пользователь успешно заплатит, система заказов уведомит вышестоящую и нижестоящую системы об изменении статуса и одновременно вычтет запасы и маркетинг.
Деловая доставка, подтвердите получение: после того, как оплата заказа будет завершена, он войдет в процесс обработки продавца.Для сценария покупки физических товаров заказ мидл-офиса войдет в логистическую связь. Для продуктов, у которых нет физического лица, мидл-офис предоставит шаблон транзакции без процесса доставки.
успешная транзакция: Успешная транзакция — это одно из конечных состояний заказа, представляющее окончательное завершение транзакции пользователем и продавцом.

3.2 Обратный процесс возврата

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

После абстрактного бизнес-процесса мидл-офис разобрался с набором процессов возврата и возврата.Как показано на рисунке выше, после инициирования возврата и возврата он войдет в ссылку проверки продавца.После того, как продавец подтвердит это, он будет обработан пользователем. Если есть логистическая связь, на этот раз речь пойдет о возврате и доставке продавца.

Здесь представлен бизнес-процесс, а затем в основном представлена системная архитектура.

В-четвертых, структура

Цель самой технологии — служить бизнесу, а техническая архитектура, которая подходит самому бизнесу, — самый экономичный выбор. То же самое и с системой заказов: архитектура постепенно оптимизируется и расширяется по мере развития бизнеса.

В начале бизнеса архитектура показана на следующем рисунке:

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

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

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

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

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

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

4.1 Архитектура оркестрации инструкций

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

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

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

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

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

Ниже приведен пример бизнеса по разделению заказа для иллюстрации.

Заказать сплит-инструкцию

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

Как правило, есть две причины для разделения заказа:

(1) Комбинированный платеж в сценариях электронной коммерции: товары пользователя поступают от разных продавцов, и необходимо разделить заказ для совместного использования аккаунта;

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

Этот вид бизнеса может быть абстрагирован в инструкции по разделению заказа.

Разделение заказа посредством оркестровки инструкций

Создать единую инструкцию можно разобрать снос, демонтаж двух инструкций: + снос разделенной односпальной стратегии. Комбинация в соответствии с инструкциями по потребностям бизнеса, правилам и генерирует абстрагированные два типа шаблонов (шаблон Одиночная расщетка Cart, консультируя один шаблон Q-разделения Q) и примеры внешнего выхода модели доступа.

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

Когда есть необходимость в консультации или разборке после оплаты, вы можете использовать шаблон разборки вопросов и ответов, таких как: медицина, карта Baidu, перезарядка мобильного телефона унция и т. д.

4.2 Оптимизация производительности архитектуры

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

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

Проблемы, которые можно увидеть, следующие:

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

Для проблемы, мы ломаем один за другим.

4.2.1 Проблемы с длинным последовательным соединением

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

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

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

4.2.2 Давление повторного сбора базы данных

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

Один и тот же поток повторно запрашивает данные для передачи на уровне потока и использует ThreadLocal для передачи данных между потоками.

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

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

TransmittableThreadLocal наследует InheritableThreadLocal и используется аналогичным образом. По сравнению с InheritableThreadLocal добавлено:

(1) Метод копирования используется для настройки поведения копирования значения ThreadLocal, когда задача отправляется в пул потоков и передается на выполнение задачи.По умолчанию передается ссылка. Примечание. Если ссылка на объект передается между потоками, потому что больше нет закрытия потока, как в случае с InheritableThreadLocal.childValue, пользовательская/бизнес-логика должна обратить внимание на потокобезопасность переданного объекта.

(2) Защищенный метод beforeExecute/afterExecute выполняет обратный вызов задачи до/после жизненного цикла (Runnable/Callable).

4.2.3 Повышение производительности базы данных

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

Во-первых, изолируйте и разделите данные для различных бизнес-потребностей. Необходимо следить за бизнесом, чтобы изолировать различные бизнес-данные и разделить их по вертикали на разные библиотеки и машины, чтобы повысить производительность базы данных и емкость различных предприятий. (например: заказ, возврат, послепродажное обслуживание, жалобы клиентов, товары, запасы и т. д.)

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

Чтобы разделить таблицу заказов по горизонтали, сначала необходимо определить поля разделяемой таблицы.

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

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

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

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

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

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

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

V. Резюме

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

читать оригинал: |Анализ архитектуры системы заказов торговой платформы Baidu

Архитектор Байду

Официальный технический общедоступный аккаунт Baidu доступен онлайн!

Технические галантереи · Отраслевая информация · Интернет-салон · Отраслевая конференция

Информация о найме · Внутренняя информация · Технические книги · Периферийные устройства Baidu