Чжай Ян, архитектор China Merchants Huimin Platform Group, участвовал в процессе строительства промежуточной платформы от 0 до 1 и в основном отвечал за строительство, исследования и разработку промежуточной платформы для транзакций, товарной промежуточной платформы, и поисковая платформа.
Традиционный режим работы отрасли FMCG больше не может соответствовать требованиям развития новой эры, и невозможно добиться качественного развития общественной торговли, просто продвигая модернизацию конца цепочки поставок. Zhongshang Huimin продолжает концентрироваться на обслуживании заказов миллионов общественных супермаркетов, переходя от обслуживания розничных терминалов к продвижению цифровой трансформации всей отраслевой цепочки FMCG, созданию замкнутой операционной системы данных B2B2C и обслуживанию брендов и дистрибьюторов. , Местные супермаркеты предоставляют решения для преобразования и модернизации всей производственной цепочки закупок, продаж, маркетинга и дистрибуции, а также продолжают способствовать развитию бизнеса и инновациям. Все это благодаря мощной системе мидстейджа.
Знакомство с торговым центром
Zhongshang Huimin прошла через несколько технических итераций: с 2016 по 2017 год стек технологий PHP был переведен на стек технологий Java и реализованы микросервисы, а в 2018 году началось построение мидл-платформы.
Будет запущена первая фаза транзакционного мидл-офиса, завершенная в начале 2021 года, а вторая очередь — в марте 2022 года.
С ростом бизнеса и изменениями в разнообразии необходимо своевременно реагировать на новые потребности и в то же время избегать воздействия на существующие предприятия.Основываясь на принципах повышения эффективности человеческого труда и снижения затрат, Zhongshang Huimin запустила разработку стратегия усиления Китая и Тайваня. Для систем необходимо уменьшить связь между системами, повысить масштабируемость и обеспечить низкую задержку при извлечении общего бизнеса. В начале 2021 года была завершена реконструкция предыдущей системы управления заказами (OMS) и запущен проект транзакционного мидл-офиса, ориентированный на процесс транзакций заказа, который разделен на следующие четыре основных модуля: статус заказа система обращения, система управления заказами, система выполнения заказов, система расчета стоимости заказа. В то же время, на основе бизнес-стратификации, он делится на систему запросов заказов, систему отчетов, фон управления заказами и т. д.
В процессе реконструкции системы, чтобы технические требования не мешали бизнес-требованиям, онлайн-процесс делится на два этапа: разделение системы приложений и разделение данных.
разделение системы
Поскольку система управления заказами находится в «наиболее пострадавшей области» бизнеса, в процессе быстрого роста бизнеса частые корректировки системы также должны адаптироваться к нескольким направлениям бизнеса, что сделает студентов, изучающих исследования и разработки, истощенными и истощенными ... На основе этих проблем сформулируйте следующие принципы разделения и реконструкции системы:
-
Избегайте логического связывания различных бизнес-направлений, включайте друг друга и влияйте друг на друга, а также уменьшите логическую сложность.
-
Разделите обязанности в соответствии с жизненным циклом заказа, чтобы гарантировать, что каждая область системы несет единую ответственность.
-
Выполните разделение чтения и записи, чтобы обеспечить стабильность основных функций и избежать частых итераций, влияющих на основные функции.
-
Внедрите ElasticSearch, чтобы решить проблемы с внешними индексами и снизить нагрузку на индексы базы данных.
разделение данных
Цель разделения данных — уменьшить нагрузку на обслуживание одной таблицы.Когда объем данных достигает десятков миллионов, обслуживание индексов и полей таблицы базы данных окажет большое влияние на онлайн-среду. При принятии решения о разделении таблицы данных необходимо ответить на следующие вопросы:
-
Сформулируйте принципы разбиения: какая таблица требует больших объемов данных? Как определяется количество сплитов?
-
Проблема чтения и записи данных: как решить проблему чтения и записи после разделения таблицы?
-
План запуска: как добиться плавного запуска?
принцип разделения
Взяв 3 года в качестве итеративного цикла, количество разбиений = ((количество новых добавленных данных в месяц * 36) + количество исторических данных) / верхний предел количества данных в одной таблице
По нашему опыту сопровождения Alibaba Cloud RDS MySQL, основанном на использовании движка Innodb, при выполнении DDL-операций объем данных составляет менее 5 млн, а время выполнения — около десяти секунд; больше 5 млн — меньше объем данных более 10 миллионов, время выполнения около 500 секунд, объем данных более 10 миллионов, объем менее 50 миллионов, время выполнения более 1000 секунд, объем данных более 50 миллионов, время выполнения более 2000 секунд .
Верхний предел выделения одной таблицы может зависеть от влияния операций с одной таблицей на бизнес.Конечно, существуют некоторые решения для решения проблемы блокировки таблиц операций DDL, такие как синхронизация с двумя таблицами, и метод переключение имен таблиц может уменьшить воздействие до секунд.
Количество разделений библиотечного стола предпочтительно равно 2 в степени N, что способствует горизонтальному расширению на более позднем этапе.
Технический отбор
После разделения таблицы данных необходимо решить проблему хэширования данных и запросов. Как малому и среднему предприятию, стоимость самостоятельно разработанного промежуточного программного обеспечения для подбазы данных и подтаблиц слишком высока, и оно столкнется с различными рисками наступить на яму на начальном этапе.Разумным решением является использование набор подбаз данных с открытым исходным кодом и промежуточного программного обеспечения подтаблиц.
Apache ShardingSphere
Apache ShardingSphere — это экосистема решений для распределенных баз данных с открытым исходным кодом. Она состоит из трех продуктов: JDBC, Proxy и Sidecar (в стадии планирования), которые можно развертывать независимо или использовать в сочетании с гибридным развертыванием. Оба продукта обеспечивают стандартизированное расширение уровня данных. , распределенные транзакции и распределенные функции управления, и применимы к различным сценариям приложений, таким как изоморфизм Java, гетерогенные языки и облачная среда.
Версия Apache ShardingSphere 5.x предлагает концепцию Database Plus. База данных Plus — это концепция дизайна системы распределенной базы данных, которая создает стандартные слои и экологические уровни для использования и взаимодействия поверх фрагментированных однородных или гетерогенных баз данных, а также накладывает и расширяет дополнительные вычислительные возможности, такие как сегментирование данных, шифрование и дешифрование данных, и т. д., сделать так, чтобы взаимодействие между всеми приложениями и базами данных было обращено к стандартному уровню, созданному Database Plus, тем самым защищая дифференцированное влияние фрагментации базы данных на бизнес верхнего уровня.
Новая версия начинает ориентироваться на подключаемую архитектуру, а функциональные компоненты проекта можно гибко расширять подключаемым образом. В настоящее время такие функции, как сегментирование данных, разделение чтения и записи, шифрование данных, проверка давления теневой библиотеки и поддержка SQL и таких протоколов, как MySQL, PostgreSQL, SQL Server и Oracle, вплетены в проект с помощью подключаемых модулей. могут настраивать свои собственные уникальные системы так же, как с помощью кредитов. В настоящее время Apache ShardingSphere предоставляет десятки SPI в качестве точек расширения системы, и их количество продолжает расти.
Есть несколько причин для выбора Apache ShardingSphere:
-
Apache ShardingSphere функционирует, как и ожидалось, может решать текущие проблемы и обладает широкими возможностями масштабирования.
-
Сообщество Apache ShardingSphere очень активно, и в случае возникновения проблем будет назначен специальный человек, который будет своевременно реагировать на возникающие проблемы.
-
Компания использует стек технологий SpringCloud, который легко интегрируется и имеет низкую стоимость.
-
Производительность соответствует ожидаемой со ссылкой на официальную документацию и может полностью поддерживать существующий бизнес.
ShardingSphere поддерживает следующие 3 режима:
Текущий стек серверных технологий компании включает только язык Java и временно не требует рассмотрения разнородных сценариев.Учитывая гибкость, вторжение в код и стоимость развертывания, окончательно выбран метод реализации ShardingSphere-JDBC.
Техническая реализация
Самая сложная часть процесса — это не часть интеграции плагина, а онлайн-ссылка.
Чтобы избежать «жалоб» со стороны бизнес-команды во время онлайн-процесса, необходимо максимально избежать воздействия на конечных пользователей, чтобы оно было невосприимчивым и могло быть отброшено.Наконец, мы разбираем онлайн-процесс на следующие шаги, как показано на рисунке:
Вот объяснение этого пошагового процесса:
Шаг 1: В процессе обработки полных данных необходимо обеспечить согласованность данных в новой базе данных. Из-за стратегии сегментирования данных в настоящее время на рынке нет инструмента синхронизации, поддерживающего стратегию сегментирования данных.Мы разработали инструмент синхронизации данных, поддерживающий настройку стратегии сегментирования.
Шаг 2. Обработка добавочных данных для обеспечения согласованности данных между старой и новой базами данных. Наш план реализации здесь состоит в том, чтобы использовать канал компонента с открытым исходным кодом для мониторинга binlog базы данных, синхронизировать изменение базы данных с очередью сообщений, а затем использовать инструмент синхронизации данных для мониторинга записи сообщений в новую базу данных. Архитектурное решение не сложное, но в этом звене следует обращать внимание на согласованность данных, инкрементальные данные не могут терять данные, в то же время необходимо контролировать последовательную запись однострочных данных, чтобы предотвратить проблемы ABA.
Шаг 3: Обработайте оттенки серого трафика чтения и подключитесь к сети. В соответствии с конфиденциальностью бизнеса компании, подключитесь к сети в оттенках серого, чтобы проверить, является ли трафик чтения нормальным, пока не будет завершен процесс переключения всего трафика чтения на новую базу данных. На данный момент состояние нашего сервиса — это библиотека записи для базы данных, считывающая состояние новой библиотеки. В этой ссылке следует обратить внимание на чувствительность бизнеса к согласованности данных, поскольку задержка от старой базы данных к новой базе данных составляет около секунд.В некоторых чувствительных сценариях, требующих высокой согласованности, необходимо учитывать базу данных чтения.
Шаг 4. Переключите весь трафик чтения приложения на новую библиотеку и сохраните состояние библиотеки записи, читающей новую библиотеку.
Шаг 5: В процессе обработки пишущего трафика, в целях снижения сложности программы, сценарий релиза градаций серого не рассматривается.Конечно, решение в градациях серого тоже может быть достигнуто, но я не буду его здесь распространять. Наш подход заключается в обратной записи данных новой базы данных в старую базу данных для поддержки стратегии отката, а затем выпуске всего трафика в новую базу данных в одном выпуске. (Это решение имеет высокие риски и может повлиять на большое количество пользователей. Попробуйте полностью оценить его в тестовой среде, и вам нужно обратить внимание на то, соответствуют ли тесты покрытия кода и производительности стандарту.)
На данный момент весь процесс выпуска и онлайн-процесса завершен.Благодаря использованию промежуточного программного обеспечения ShardingSphere-JDBC для перезаписи SQL и слияния результатов стоимость завершения всего преобразования невелика, оно практически не затрагивает код. , и онлайн-процесс также относительно гладкий.
Кроме того, есть некоторые проблемы, на которые, возможно, следует обратить внимание при доступе к решению ShardingSphere-JDBC.
-
ShardingSphere-JDBC имеет логику обработки по умолчанию для вставки данных.Если в SQL нет сегментированного столбца для вставки данных, это приведет к тому, что каждая сегментированная таблица будет вставлять один и тот же фрагмент данных.
-
Для пакетного семантического анализа SQL ShardingSphere-JDBC анализирует только логическую таблицу первого SQL, что приведет к ошибке выполнения. Об этой проблеме было сообщено официальному лицу, и она должна быть устранена в ближайшее время. Кроме того, официальный также предоставляет подробные примеры SQL, которые подробно перечислены в рамках поддержки.Перед разработкой необходимо подробно прочитать документацию.
-
Выбор режима подключения ShardingSphere-JDBC.
С точки зрения управления ресурсами количество подключений, которые бизнес-сторона может получить к базе данных, должно быть ограничено. Это может эффективно предотвратить использование слишком большого количества ресурсов определенной бизнес-операцией, что приведет к истощению ресурсов подключения к базе данных, что повлияет на нормальный доступ других предприятий. Особенно, когда в экземпляре базы данных много сегментированных таблиц, логический SQL, не содержащий сегментированных ключей, будет генерировать большое количество реальных SQL в разных таблицах одной и той же базы данных.Если каждый реальный SQL занимает одно отдельное соединение, то запрос несомненно отнимет слишком много ресурсов.
С точки зрения эффективности выполнения поддержка отдельного подключения к базе данных для каждого разделенного запроса может более эффективно использовать многопоточность для повышения эффективности выполнения. Открытие отдельного потока для каждого подключения к базе данных может обрабатывать потребление ввода-вывода параллельно, поддерживать отдельное подключение к базе данных для каждого сегмента и избегать преждевременной загрузки данных результатов запроса в память. Независимое соединение с базой данных может содержать ссылку на позицию курсора в наборе результатов запроса, и курсор можно перемещать, когда необходимо получить соответствующие данные.
Метод слияния результатов путем перемещения курсора набора результатов вниз называется потоковым слиянием, при этом не требуется загружать все данные результата в память, что позволяет эффективно экономить ресурсы памяти и снижать частоту сборки мусора. Если не гарантируется, что каждый сегментированный запрос содержит независимое соединение с базой данных, необходимо загрузить весь текущий набор результатов запроса в память перед повторным использованием соединения с базой данных для получения набора результатов запроса следующей сегментированной таблицы. Таким образом, несмотря на то, что можно использовать потоковое слияние, в этом сценарии оно сведется к слиянию памяти.
С одной стороны, это контроль и защита ресурсов подключения к базе данных, с другой стороны, он использует лучший режим слияния для экономии ресурсов памяти промежуточного программного обеспечения. нужно решить вопрос. В частности, если часть SQL должна работать с 200 таблицами в экземпляре базы данных после разделения с помощью ShardingSphere. Итак, что вы выберете: создать 200 соединений для параллельного выполнения или одно соединение для последовательного выполнения? Как выбрать между эффективностью и контролем ресурсов?
Для описанных выше сценариев ShardingSphere предоставляет решение. Он предлагает концепцию режима соединения (Connection Mode) и делит его на два типа : СТРОГО ПАМЯТЬ и СТРОГО СОЕДИНЕНИЕ .
режим ограничения памяти
Предпосылкой использования этого режима является то, что ShardingSphere не ограничивает количество подключений к базе данных, потребляемых одной операцией. Если фактически выполняемый SQL должен работать с 200 таблицами в экземпляре базы данных, создайте новое соединение с базой данных для каждой таблицы и обрабатывайте его одновременно с помощью многопоточности, чтобы максимизировать эффективность выполнения. А когда SQL удовлетворяет условиям, предпочтение отдается потоковому слиянию, чтобы предотвратить переполнение памяти или избежать частой сборки мусора.
Режим ограничения подключения
Предпосылка использования этого режима заключается в том, что ShardingSphere строго контролирует количество подключений к базе данных, используемых для одной операции. Если фактически выполняемый SQL должен работать с 200 таблицами в экземпляре базы данных, будет создано только уникальное соединение с базой данных, и 200 таблиц будут обрабатываться последовательно. Если шарды в одной операции разбросаны по разным базам данных, многопоточность по-прежнему используется для обработки операций над разными библиотеками, но каждая операция каждой библиотеки по-прежнему создает только уникальное соединение с базой данных. Это может предотвратить проблему, вызванную тем, что слишком много подключений к базе данных занято для одного запроса. Этот режим всегда выбирает объединение памяти.
Режим ограничения памяти подходит для операций OLAP, что может повысить пропускную способность системы за счет ослабления ограничений на соединения с базой данных; режим ограничения соединений подходит для операций OLTP.OLTP обычно имеет ключ раздела и направляется в один раздел, поэтому — это разумный выбор для управления подключениями к базе данных, чтобы гарантировать, что онлайн-ресурсы системной базы данных могут использоваться большим количеством приложений.
Мы обнаружили, что в режиме с ограниченным объемом памяти операция будет интенсивно выполнять операции ввода-вывода из-за стратегии загрузки кэш-буфера движка MySQL innodb во время процесса, что приводит к большому количеству тайм-аутов SQL.Решение этой проблемы состоит в том, чтобы не изменить ресурсы базы данных.Программа многоуровневая.Если обнаружено отсутствие ключа сегмента, сначала подтвердите ключ сегмента во внешнем индексе, а затем используйте ключ сегмента для поиска в базе данных.
прирост стоимости
- повышение производительности
Благодаря реконструкции схемы объем данных в одной таблице эффективно контролируется, а медленный SQL значительно сокращается почти на 50%.
- Экономьте ресурсы НИОКР и сокращайте расходы
Внедрение зрелой версии Apache ShardingSphere устраняет необходимость в повторной разработке компонентов подтаблиц, что снижает затраты на НИОКР и количество ошибок.Студентам, занимающимся исследованиями и разработками, нужно сосредоточиться только на решении бизнес-проблем.
- Богатая расширяемость
Apache ShardingSphere обладает хорошей масштабируемостью для шифрования данных, распределенных транзакций, теневых библиотек и т. д.
пиши до конца
В книге «Микросервисный дизайн» Сэма Ньюмана он однажды написал: «По сравнению со строительством зданий, в программном обеспечении мы сталкиваемся с большим количеством изменений в требованиях, и используемые инструменты и методы также разнообразны. Природа вещей. не создавать что-то, что не меняется после определенного момента, даже после запуска в производство, программное обеспечение продолжает развиваться.Для большинства продуктов, которые мы создаем, они доставляются заказчику.После этого еще необходимо реагировать на меняющиеся потребности клиента, а не просто передать клиенту статичный пакет.Поэтому архитектор должен изменить идею проектирования идеального продукта с самого начала, вместо этого мы должны разработать разумную основу, в которой правильная система может быть медленно развивается, и как только мы узнаем больше, его будет легко применить к системе». Apache ShardingSphere — именно такая система. Продукт с большим потенциалом, будущее определенно многообещающее.
