Проектирование и практика архитектуры хранения для десятков миллионов заказов в день | Команда JD Logistics Technology

1. Обзор системы заказов

1.1 Сфера деятельности

Бизнес-направления обслуживания: экспресс-доставка, экспресс-доставка, мелкие и средние товары, крупные товары, холодовая цепь, международная, контрактная логистика B2B, CLPS, Jingxi, три входа и три выхода (закупка, возврат, распределение, распродажа, снятие поставок, аллокация)) )подождите

1.2 Значение центра заказа

1. Развязка ( повышение стабильности системы )

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

Новая система: разделение транзакций и производственных операций: требования, связанные с транзакциями, решаются в области заказов; требования на стороне производства решаются в производственной области, сокращая взаимодействие вверх и вниз по течению.

Связь бизнес-линий: разные бизнес-линии имеют разные бизнес-процессы. Изменения в требованиях одной бизнес-линии будут итеративно обновляться только в конкретном процессе и не повлияют на другие бизнес-линии. Повысьте стабильность всего процесса и бизнеса.

2. Улучшить скорость доступа к новым сервисам

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

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

3. Обеспечьте глобальную унифицированную модель данных.

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

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

2. Введение в архитектуру

2.1 Общий архитектурный проект

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

2.2 Проектирование архитектуры уровня данных реального времени

2.2.1 Схема взаимодействия системы

Взаимодействие системы происходит следующим образом:



В стандартном интерфейсе центра заказов есть закрытие документов на верхнем уровне, также мы сделали унифицированное закрытие на уровне данных.

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

Система сохранения : используется для поддержки сохранения данных, таких как получение заказа, изменение заказа, отмена заказа, удаление заказа и т. д.

Система поиска : предоставляет такие услуги, как запрос деталей заказа, запрос списка заказов, запрос статуса заказа и оценка того, сделаны ли заказы Baichuan.

Релейная система : концентратор данных, который записывает данные заказа в Elasticsearch, HBase и MySQL через очередь сообщений о потреблении.

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

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

2.2.2 Схема технической архитектуры



• [Архитектура разделения чтения и записи] Применяет режим архитектуры разделения чтения и записи (CQRS) для разделения порядка чтения и записи трафика для повышения производительности запросов и масштабируемости, одновременно обеспечивая развязку чтения и записи.

• [Кэширование] Используйте распределенный кэш Redis для кэширования популярных данных о заказах и информации, связанной с заказами, чтобы улучшить параллелизм и скорость ответа, а также уменьшить доступ к HBase . В то же время три набора высокопроизводительных кэшей: основной, резервный и временный, используются для повышения устойчивости системы к катастрофам.

• [Очередь сообщений] Используйте очередь сообщений JMQ для реализации асинхронной обработки заказов для повышения пропускной способности системы, а сокращение пикового трафика снижает нагрузку на прямые запросы к ES, HBase и базам данных. Изоляция различных бизнес-сценариев (таких как заказы и возврат) с использованием разных тем может способствовать лучшему управлению и обслуживанию; использование разных тем для изоляции разных предприятий может обеспечить параллельную обработку и горизонтальное расширение сообщений, а также улучшить пропускную способность системы и производительность.

• [Сложный запрос] Используйте поисковую систему Elasticsearch для решения сложных запросов заказов. Сначала получите номер заказа через Elasticsearch, а затем запросите распределенный кэш Redis + столбчатую базу данных HBase на основе номера заказа.

• [Недорогое постоянное хранилище] Использует столбчатую базу данных HBase для поддержки хранения больших объемов данных и высокой масштабируемости.

• [Согласованность данных] достигается за счет надежных транзакций, конечной согласованности, идемпотентности, компенсации, распределенных блокировок, номеров версий и т. д.

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

2.3 Преимущества конструкции

2.3.1 Высокая доступность

• Серверы приложений, MySQL, Redis, HBase, JMQ и т. д. развертываются в компьютерных залах; развертывание одного компьютерного зала ES, создание главного ES и резервного кластера с двумя компьютерными залами

• Изоляция, ограничение тока, плавкие предохранители, ограничение пиков, мониторинг

2.3.2 Высокая производительность

• Высокопроизводительное кэширование.

• Асинхронный

2.3.3 Массовая обработка данных

• Подбаза данных и подтаблица

• Горячее и холодное разделение

• Хранилище столбцов ( HBase).

2.3.4 Безопасность данных

Конфиденциальная информация шифруется и хранится. Log, Redis, ES, MySQL, HBase и т. д. используют зашифрованное хранилище. «Тот, кто ее хранит, шифрует ее, а тот, кто ее использует, расшифровывает ее».

3. Модель данных заказа

3.1 Модель ДПМ

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







3.2 Масштабируемость модели

3.2.1 Проект расширения стандартной модели

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

3.2.2 Масштабируемость персонализированной бизнес-модели

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



4. Будущее и вызовы

4.1 Заказать индивидуальный запрос

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

4.2 Унифицированная архитектура

Текущая длительность порядка TP99 составляет 47 мс, а TP99 — 20 мс, когда он не находится в компьютерных залах. С точки зрения данных, межкомпьютерные залы оказывают большое влияние на производительность.

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

4.3 Контроль затрат на оборудование

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

Автор: Ван Вэйдун из JD Logistics

Источник: Сообщество разработчиков JD Cloud Ziyuanqishuo Tech. При перепечатке указывайте источник.

Оштрафован на 200 юаней и конфисковано более 1 миллиона юаней Ю Юйси: важность высококачественных китайских документов Жесткий сервер миграции Маска Solon для JDK 21, виртуальные потоки невероятны! ! ! Контроль перегрузки TCP спасает Интернет Flutter для OpenHarmony уже здесь Срок LTS ядра Linux будет восстановлен с 6 до 2 лет Go 1.22 исправит ошибку переменной цикла for Svelte построила «новое колесо» — руны Google отмечает свое 25-летие

{{o.name}}

{{м.имя}}