Эволюция архитектуры приложения торговой системы Ele.me

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

▶Все усилия на архитектурном уровне направлены на удовлетворение потребностей бизнеса в масштабируемости.

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

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

Вот проблемы, с которыми мы столкнулись на протяжении всего процесса эволюции архитектуры.

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

- Бизнес становится все более и более сложным, со все большим количеством интерфейсов и полей.

- Новый бизнес повлияет на старый бизнес, а совместимость всегда является проверкой мастерства.

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

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

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

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

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

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

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

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

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

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

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

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

Развитие бизнес-систем часто следует за сложностью бизнеса, но здесь есть парадокс, то есть, если бизнес не умеет развиваться, то и бизнес-система не будет развиваться.

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

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

На рисунке выше представлена ​​вся архитектура системы. Верхний слой — это служба ресепшн гида по покупкам, которая отвечает за прямое взаимодействие с пользователями и является входом ко всем данным. Ядром службы мидл-офиса в середине транзакции является управление контрактом и обслуживание процесса и возможностей. Самый нижний уровень — это все основные службы поддержки. Ресурсы, такие как магазины, товары и учетные записи, — это все основные службы и часть данных транзакций. На их основе будут генерироваться возможности транзакций, которые затем будут предоставляться внешнему бизнесу.