Автор: Сунь ЯньОригинальный адрес Dada Group Technology
предисловие
Товарная система является одной из самых основных и основных систем системы электронной коммерции. Данные о товарах можно найти во всех компаниях. Домашняя страница, страница магазина, корзина, заказ, расчет, послепродажное обслуживание, запасы, цена и т. д. — все это неотделимо от товаров. Информация о товарах должна стабильно предоставляться каждому узлу цепочки поставок Daojia, поэтому она должна поддерживаться стабильной и высокопроизводительной системой обслуживания товаров.
С быстрым развитием товарного бизнеса JD Daojia бизнес изменился с единичного на диверсифицированный, а дизайн системных функций также эволюционировал от первоначальной крупной и всесторонней функциональной поддержки до микрофункциональной и доменной.
Стандартные системы также претерпели эволюцию нескольких версий архитектуры под постоянным влиянием высокой доступности и высокой степени параллелизма. Первоначальная версия 1.0 использовала подходящие и простые дизайнерские идеи для быстрого итеративного запуска бизнеса; с быстрым ростом объема бизнеса версия 2.0 эволюционировала для улучшения высокой доступности и высокой производительности. Последующее увеличение сложности бизнеса привело к увеличению сложности системы.Чтобы решить проблемы, вызванные сложностью системы, родилась конструкция поля товарной системы 3.0.
Daojia Commodity Architecture Первоначальная модель 1.0 Подходящие и простые идеи дизайна
Прототип товарной системы
В начале создания Daojia Commodity System, чтобы соответствовать быстрому развитию бизнеса, была разработана и запущена система Daojia Commodity 1.0. Услуги товарной системы основаны на идее крупного и всеобъемлющего и используют набор услуг для предоставления агрегированных данных о товарах вышестоящим бизнес-сторонам, как бизнес-конец B, так и бизнес-конец связаны вместе, в ответ на быстрое итеративный запуск бизнеса и экономия затрат на разработку, что в полной мере отражает преимущества простоты.
С повышением уровня бизнеса выделяются и недостатки оригинальной конструкции, которые в основном отражаются в следующих моментах:
· Онлайн-сервисы на стороне B/C связаны друг с другом, что приводит к тому, что онлайн-сервисы чтения/записи влияют друг на друга.Особенно в период большой рекламной акции модифицируется большое количество продуктов, что приводит к нестабильности служб на стороне C. Стабильность может улучшаться только за счет непрерывного горизонтального расширения, что, в свою очередь, приводит к серьезной трате ресурсов;
· Производительность сервера сильно колеблется;
Простая архитектура кеша, проблема разбивки кеша Redis при высоком уровне параллелизма;
· Неполный контроль и своевременное предупреждение;
В ответ на вышеуказанные проблемы в товарной системе реализована эволюция архитектуры 2.0 с точки зрения высокой доступности и высокой производительности;
Домашняя товарная архитектура — 2.0, высокая доступность, высокая производительность, эволюция шаблонов архитектуры
После того, как товарная система прошла стадию быстрой итерации 1.0, онлайн-трафик также удвоился с ростом бизнеса.Высокая связанность услуг на стороне B/C привела к большим колебаниям в товарных услугах, а неполный мониторинг также привел к несвоевременное обнаружение системного исключения.
Для повышения доступности услуг товарной системы товарная система сформулировала следующую итеративную схему.
· Принцип AP + идея конечной согласованности
· Разделение услуг B/C
· Удаленная многоактивная двухмашинная архитектура
Sentinel ограничение тока
· платформа мониторинга
Эволюция высокой доступности
(1) принцип AP + идея окончательной согласованности
Чтобы повысить высокую доступность стандартной службы чтения на стороне C, была принята идея дизайна по принципу AP + согласованность в конечном итоге, представлен распределенный кеш-кластер Redis для повышения доступности службы чтения и согласованности данных в конечном итоге. гарантируется через асинхронные сообщения.
Принцип AP соответствует бизнес-сценарию службы C-стороны товарной системы. Например, из-за таких проблем, как сетевая задержка, база данных не синхронизирует данные в кэш Redis вовремя, что приводит к несоответствию между текущими считанными товарные данные и данные в базе данных.Это краткосрочное несоответствие вызвано бизнесом.
После появления распределенного кластера Redis стандартная функция чтения на стороне C не только повышает доступность, но и очень хорошо работает с точки зрения производительности.
(2) Разделение услуг B/C
Продавцы будут регулярно изменять информацию о продукте, изображения и другие атрибуты, подключаясь к интерфейсу открытой платформы. Например: в большой акции мы столкнулись с тем, что продавцы централизованно модифицировали информацию о товарах, в результате чего служба записи отнимала много системных ресурсов, что приводило к повреждению доступности службы чтения.
Чтобы улучшить соответствующую доступность стороны B/C товарных услуг, стороны B/C независимо развертываются для предоставления услуг внешнему миру. После разделения услуги B/C услуги B/C товарной системы стабильно работали в последующих акциях товарной системы, что значительно улучшило доступность товарных услуг. Последующая операция записи продавца, товарная система никогда не была повреждена службой чтения.
(3) Удаленная многоактивная двухмашинная архитектура
Жить в разных местах- Физический компьютерный зал, в котором находится докер для обслуживания домашних продуктов, развертывается по методу нескольких местоположений.Компьютерный зал распределяется по многим различным регионам по принципу «не класть яйца в одну корзину». Когда проблема возникает в одной компьютерной комнате, есть две другие компьютерные комнаты для предоставления услуг, что значительно улучшает масштабируемость стандартной системы для работы с событиями черного лебедя.
Двухмашинная архитектура- Кластер Redis, промежуточное программное обеспечение, поддерживающее основную службу чтения товаров, использует режим ведущий-ведомый, а главный и подчиненный сегменты принадлежат разным компьютерным комнатам.Когда главный сегмент неисправен, главный-ведомый автоматически переключается.
MongoDB использует метод 1 главного и 2 резервных для резервного копирования данных.Если основная база данных ненормальна, главный и резервный узлы можно быстро переключить через доменное имя.Весь процесс переключения плавный и незаметный.
(4) Ограничение тока Sentinel
Служба чтения товаров представляет компонент управления потоком Sentinel, который может настраивать различные политики управления потоком в режиме реального времени в зависимости от источника вызова через Zookeeper.После возникновения экстремального трафика неосновные источники вызовов могут быть ограничены по току и взорваны, чтобы стремиться к достаточной пропускной способности онлайн. расширение.Время, избегайте внезапного аномального трафика, который делает общую службу продукта недоступной, и повышайте доступность службы чтения продукта.
Путем настройки имени метода и источника вызова стандартная служба выполняет направленное ограничение тока для пограничных бизнес-вызовов и методов. В крайних случаях, жертвуя доступностью пограничных сервисов, достигается цель обеспечения высокой доступности основного метода.
(5) Платформа мониторинга
Товары и услуги используют платформу мониторинга и сигнализации Jingdong. Товарный интерфейс API, вы можете отслеживать распределение производительности в разные периоды времени через UMP и статистику в реальном времени TP99, TP999, AVG, MAX и других показателей измерения. Он может контролировать систему, сеть, диск, контейнер и другие индикаторы докера сервера и уведомлять назначенное ответственное лицо в режиме реального времени, устанавливая порог срабатывания сигнализации.
Эволюция высокой производительности
После эволюции стандартных системных сервисов за счет обеспечения высокой доступности у нас появилось время улучшить производительность стандартных сервисов. Из-за ухудшенного запроса версии 1.0 стандартной службы C-стороны и поломки кэша Redis производительность стандартной системы сильно снижается.
Например: в период продвижения в сценариях с высокой степенью параллелизма производительность запроса часто снижается -> поток ответа ожидает -> пул потоков ожидает заполнения очереди -> стратегия отклонения, которая, в свою очередь, вызывает общая производительность службы продукта, чтобы замедлить.
В целях повышения производительности службы товарной системы товарная система сформулировала следующую итеративную схему.
· Запрос на стороне C к зависимости MongoDB
· Постоянный кеш Redis
· Сервис асинхронной обработки данных
· Кэш памяти
(1) C-сторона переходит к зависимости от MongoDb
В версии продукта 1.0, если запрос на стороне C не попадает в кеш Redis, запрос будет понижен до базы данных Mongodb, а данные будут записаны обратно в Redis. Один запрос подвергся множеству взаимодействий в стандартной системе, и часть логики не связана с поведением пользователя, например, обратная запись Redis. В то же время существует серьезный риск проникновения в кеш. сильно колеблется, и риск также относительно высок.
Стандартная служба чтения на стороне C удаляет операцию понижения версии запроса Mongodb и обрабатывает операцию записи в кэш Redis на стороне B. После удаления зависимости от Mongodb производительность стандартной службы чтения на стороне C снизилась. был значительно улучшен.
(2) Постоянный кеш Redis
После того, как стандартная система преобразуется запросом на стороне C для перехода на более раннюю версию, KV, хранящийся в кластере Redis, преобразуется в постоянное хранилище KV по сравнению с предыдущим сроком действия в один месяц.
Чтобы удалить время истечения срока действия KV для Redis, ключевой вопрос заключается в том, как обеспечить согласованность данных между базой данных MongoDb и кластером Redis. Модификация информации о товарах на стороне B использует асинхронную задачу для сохранения данных в кэше Redis, а KV, который пропускает запрос Redis на стороне C, считается несуществующим, что не только снижает количество взаимодействий. внутри товарной системы, но также эффективно предотвращает проблему проникновения в кэш, что в конечном итоге сокращает время отклика сервера.
(3) Служба асинхронной обработки данных
Первоначальные B/C/асинхронные задачи продукта связаны друг с другом.После разделения службы B/C асинхронные задачи соответственно связаны.Когда продукт изменяет информацию, изображения, атрибуты и службы состояния, он будет выполнять асинхронную обратную запись в кэш Redis, чтобы MongDb и Redis кэшировали окончательную согласованность данных KV, но большое количество асинхронных задач будет занимать ресурсы службы, что замедляет производительность службы B/C.
Поэтому в стандартной системе создан набор независимых служб асинхронной обработки данных, включая асинхронные задачи и очереди сообщений, которые выполняют все асинхронные операции записи, обратной записи и другие операции с данными стандартной службы B/C.
Разделенная платформа асинхронных задач не только обеспечивает целостность функции асинхронных задач, но также устраняет колебания производительности службы B/C, вызванные большим количеством записываемых асинхронных задач.
(4) Кэш-память ehcache
В товарных сервисах есть много словарных данных, таких как словарь категорий и словарь бизнес-классификации.Эти словари часто являются важными ключами бизнес-измерения. Кроме того, ключевой хэш мерчанта относительно сконцентрирован в шардах, и в случае большого трафика может возникнуть проблема с горячими клавишами, что приводит к переполнению входных и выходных буферов некоторых шардов, влияя на весь Redis. кластер.
В товарной системе представлен кеш-память ehcache, который хранит такие данные через память клиент-сервера, что не только решает проблему больших ключей и горячих клавиш, но и снижает взаимодействие сетевых запросов с промежуточным ПО Redis, а скорость ответа на запрос составляет значительно улучшилась.
резюме:
После того, как стандартная система претерпела эволюцию системы с высокой производительностью и высокой доступностью, стандартная система становится стабильной и высокодоступной, а также хорошо работает при последующей проверке крупномасштабного трафика.
С итерацией товарного бизнеса и увеличением сложности системы стали заметными проблемы высокой связанности бизнеса, сложного расширения системы и высокой стоимости обслуживания.
Daojia Commodity Architecture - Полевая конструкция товарной системы 3.0
Товарный бизнес изначально был линейным, и по мере усложнения бизнеса товарный бизнес постепенно менялся от линейного к нелинейному.
Например, после того, как продавец создает продукт, из-за неправильной эксплуатации и обслуживания неправильной информации о продукте, что приводит к созданию неправильных данных о продукте, необходимо найти способ мониторинга и обработки данных в режиме реального времени.
Другой пример: продавцы остановились на платформе Daojia и хотят быстро синхронизировать свои продукты с Daojia.Как мы можем предоставить быструю и полную систему создания продуктов для использования продавцами?
По мере увеличения сложности требований увеличивается сложность стандартных систем, а также растут наши затраты на развитие бизнеса, расширение и обслуживание.
Кроме того, увеличение сложности системы также приводит к следующим проблемам:
· Плохая изоляция системных ошибок и плохая доступность, ошибки в каком-то одном модуле могут привести к простою всей системы;
Плохая масштабируемость, расширение может расширить только все приложение, а не всю функциональную точку;
Все службы используют одну систему, и проникновение трафика определенного метода приведет к недоступности всех служб;
Чтобы улучшить масштабируемость системы, сократить циклы развития бизнеса, сократить расходы на техническое обслуживание и снизить системные риски, при условии обеспечения стабильности и высокой доступности услуг товарной системы, версия 3.0 эволюции архитектуры товарной системы: построение поля товарной системы. был запущен.
(1) Построение товарной системы
Прежде всего, необходимо уточнить точки спроса товарного бизнеса, а затем разделить поля из агрегированного бизнеса по точкам спроса разных предприятий, разделить систему по вертикали на основе сферы бизнеса и использовать концепцию Разделяй и властвуй, чтобы создать товарную систему, а затем разделяй и объединяй.Независимо разверните следующие системы бизнес-доменов.
· Стандартная библиотечная система
Уникальная система шаблонов UPC Daojia предоставляет продавцам шаблоны продуктов одним щелчком мыши и стандартизирует стандартные продукты продавцов, чтобы расширить возможности продавцов для создания продуктов.
· Лучшая система продуктов
С помощью анализа больших данных, в зависимости от типа продавцов, масштаба бизнеса и т. д., дополните и предоставьте список недостающих продуктов продавцов и помогите продавцам расширить продукты.
· Система управления
В соответствии с правилами продукта Daojia управляйте основной информацией о продукте, стандартизируйте правильные данные и формулируйте спецификацию продукта.
· Система ограничения покупок
Для товарного пользовательского терминала и терминала мобильного телефона он поддерживает ограничение покупки количества товаров и помогает продавцу поддерживать лимит покупки одного продукта.
· Система атрибутов
Разделение систем граничных атрибутов, таких как атрибуты категорий и специальные атрибуты товаров.
После разделения товарной системы нам нужно рассмотреть, как разделить систему на основе исходной системы.
Разделение товарной системы в основном сталкивается со следующими проблемами: С чего начать разделение? По какому измерению разбиваются данные? По какому измерению делятся услуги? Как обеспечить стабильность системы в сплите?
В ответ на вышеуказанные проблемы, мы провели следующие операции:
· Логическое наслоение сверху вниз
· Декомпозиция восходящего подхода
· Разделение бизнес-полей
· Разделение кеша Redis
(1) Логическое наслоение сверху вниз
первый, выберите логическое разделение на уровни, чтобы изолировать проблемы — компоненты на каждом уровне обрабатывают только логику этого уровня. На бизнес-уровне необходимо обрабатывать только бизнес-логику, чтобы при расширении определенного уровня не затрагивались другие уровни.Таким образом, систему можно быстро расширить на определенном уровне.
Второй, разделение на исходном уровне вызовет большую неопределенность исходной логической функции продукта. Недавно добавленный уровень бизнес-агрегации может играть роль записи агрегации для верхнего уровня и метода разделения для нижнего. Структурированная декомпозиция «сверху вниз» гарантирует, что риски, связанные с итерациями обновления системы, в значительной степени управляемы, и в то же время поддерживает лучший ритм для последующего разделения бизнеса;
(2) Декомпозиция восходящего подхода
Разбивка метода:
После нисходящего логического разделения все бизнес-методы извлекаются на бизнес-уровень для агрегирования, а следующим шагом является логическая разборка восходящего метода. Сохраните исходную логику метода обслуживания без изменений, параллельно новый набор уровней обслуживания и убедитесь, что метод соответствует принципу единой ответственности. Этот процесс отнимает много времени и сил, поэтому постарайтесь определить приоритет направления разделения (приоритетный и второстепенный бизнес) в соответствии с уровнем агрегации бизнеса, чтобы избежать конфликтов с разработкой обычных бизнес-требований. , Это не может быть сделано за один шаг. Метод разделения должен быть полностью протестирован и проверен, чтобы убедиться, что бизнес-логика до и после не изменилась.
Переключатель метода:
Добавьте переключатель Zookeeper на уровень бизнес-агрегации, чтобы переключаться между вызовами старого и нового методов.Если возникнут проблемы с новым методом, вы можете переключиться на старый метод в любое время, чтобы обеспечить стабильность в сети. После периода достаточной стабильности на линии переключение метода и старый метод могут быть удалены в последующих выпусках.
(3) Разделение бизнес-направлений
На основе логического расслоения он делится по вертикали в соответствии с товарным бизнесом, а бизнес-модули, такие как бренд, атрибут, классификация, информация и изображение, разделяются, а бизнес-модули разъединяются. В настоящее время иерархия бизнеса и кода очень ясна, а поле системного микросервиса можно разделить в соответствии с приоритетом модулей.
(4) Разделение кеша Redis
Данные товарной системы хранятся в кластере Redis. При непрерывных высоких одновременных запросах трафик входного и выходного буфера Redis будет достигать пика, что приведет к прерыванию соединений сервера и клиента, что повлияет на стабильность служб чтения. Хотя насущную потребность можно решить путем горизонтального расширения шардинга, с непрерывным ростом объема данных возрастает и риск одиночного кластера Redis.
Продукт основан на различных KV данных в кластере Redis и разделяет независимые кластеры Redis, такие как KV основной информации, KV деталей, KV атрибутов и т. д., и постепенно обновляет данные кластера Redis с помощью асинхронных задач.
(5) Эволюция микросервисной архитектуры — сервис-ориентированная
В соответствии с бизнес-доменом, после разделения независимого кластера кэша Redis, затем разделения сервисов в соответствии с бизнес-доменом, разделения основной службы информационной системы, службы системы изображений, службы графической системы, службы системы атрибутов и т. д.
Демонтированные бизнес-сервисы развертываются независимо, а разумные машинные ресурсы распределяются в соответствии с их собственными бизнес-функциями. Вертикальная изоляция между сервисными системами улучшает общую доступность и масштабируемость сервиса, а также решает проблему недоступности всего сервиса, вызванную определенным модулем.
Перспектива
Систематическое построение товарной системы постоянно совершенствуется.Заглядывая в будущее, товарная система Daojia имеет много направлений для расширения в построении интеллекта, автоматизации и обслуживания, а также во взаимодействии с алгоритмами и полями больших данных.
Например:
· Как стандартная библиотека товаров создает набор интеллектуальных данныхСистема сбора, проверки, обзора и ввода;
· Как управление сырьевыми товарами использует поле алгоритмовДля достижения интеллектуального исправления ошибок продукта, быстрой идентификации чувствительных карт и чувствительных слов;
Для приведенного выше примера у нас есть следующие идеи:
· Расширить данные о продукте стандартной библиотеки, Целью создания комнаты с моделью продукта является создание основной конкурентоспособности самодельных продуктов - возможность быстро создавать продукты, и для целей интеллектуального сбора, проверки, обзора и ввода была сформулирована следующая структура процесса проектирования. . Исходные данные о товаре поступают по нескольким каналам: сначала они фильтруются системой для очистки мусорных данных, затем данные просеиваются и сортируются по домашним правилам, а затем данные разнородны, а данные, которые отвечает требованиям, объединяется и объединяется в домашнюю предварительную проверку.Данные взвешиваются с помощью больших данных, сравнения данных, оценки алгоритма и других операций и, наконец, реализуют цель автоматического интеллектуального быстрого просмотра и ввода.
· Сила управления товаром определяет качество товара платформы, поэтому, как использовать систему и алгоритм для решения стоимости рабочей силы, является направлением нашего рассмотрения проекта. Основная идея дизайна состоит в том, чтобы использовать область алгоритмов для достижения конечной цели управления товарами посредством взвешивания алгоритмов и оценок.
Суммировать
Каждая эволюция архитектуры товарной системы JD Daojia соответствует развитию бизнеса, и цель состоит в том, чтобы решить различные проблемы, вызванные сложностью бизнес-системы. Этап 1.0 касается быстрой итерации бизнес-системы, этап 2.0 — стабильности и высокой доступности бизнес-системы, а этап 3.0 — построения системы бизнес-системы. Старайтесь использовать подходящий и простой дизайн на каждом этапе, чтобы чрезмерное проектирование не приводило к более сложным проблемам.
Основываясь на идее о том, что архитектура представляет собой дизайн высшего уровня и соответствует бизнесу, на пути проектирования оптимизации системы, поддерживать правильный и простой принцип и направление непрерывной эволюции, а также продолжать повторять и оптимизировать Система домашних продуктов. В ближайшие дни будет больше проблем, больше бизнес-сценариев и больше нераскрытых скрытых опасностей Я считаю, что нет лучшего дизайна, есть только самый подходящий дизайн для бизнеса!