Как продукт электронной коммерции транзакции играют важную роль в бизнесе Yanxuan. С непрерывным развитием бизнеса все большее значение приобретают индивидуализация и дифференциация сценариев транзакций, а также расширяется доступ сторонних платежных партнеров. a В прошлом году Yanxuan сосредоточился на размышлениях и практике архитектуры распределенных транзакций.
Для InfoQ большая честь взять интервью у Ма Чао, технического менеджера NetEase Yanxuan и лектора ArchSummit Global Architect Technology Summit, чтобы представить практику распределенной технологической архитектуры Yanxuan Mall в канале транзакций с точки зрения итерации базовой модели данных и эволюции сервисной архитектуры. . (Ма Чао также поделится темой «Дорога к простоте — строгий отбор практики развития архитектуры послепродажного обслуживания» на саммите ArchSummit в Шэньчжэне в июле)
(Чтобы полностью продемонстрировать итеративный процесс технологии Yanxuan, в статье переписан диалог от первого лица без изменения исходного смысла)
Краткая история развития архитектуры распределенных транзакций YanxuanYanxuan определяет процесс транзакции как динамический процесс, который может помочь покупателям и продавцам заключить контракт, а не просто приравнять транзакцию и платеж. В большинстве областей электронной коммерции, за исключением особых сценариев, таких как наложенный платеж, контракты обычно заключаются в форме успешных платежных поручений, поэтому структура транзакции должна быть в состоянии хорошо поддерживать основные заказы и платежные ссылки электронной почты. торговля.
На начальном этапе подсечно-огневого культивирования объем бизнеса Yanxuan Mall невелик, количество продуктов невелико, а разница невелика, а режим транзакций пользователей от корзины покупок до заказа и оплаты относительно прост.Таким образом, когда заказ создается на странице расчета, запись, связанная с платежом, является избыточной в базе данных, поэтому сумма платежа соответствует сумме расчета заказа. Затем используйте его в качестве посредника для подключения трех платежных учреждений WeChat, Alipay и NetEase через простой платежный сервис, помогите пользователю завершить оплату заказа на стороне клиента и, наконец, синхронизируйте статус платежной записи с заказом. Вся архитектура проста и понятна, и работает очень эффективно.
На ранней стадии выскабливания и заживления костей, с развитием бизнеса, сценарии транзакций Yanxuan стали диверсифицироваться и дифференцироваться.Вначале это было в платежной ссылке. Например, создание системы совместной учетной записи для входа в систему предоставило больше доступа к сторонним платежным учреждениям. Мы обнаружили, что стандарты доступа и методы этих сторонних платежных учреждений сильно различаются. , и даже режимы взаимодействия были разными.В то же время быстро развивались и самостоятельные бизнес-модули, представленные закупками предприятий и групповыми группировками.Жизненный цикл заказов и правила у этих бизнесов разные, а хранение относительно дискретное. сложно установить сопоставление с платежными записями в исходном платежном сервисе. Многочисленные функциональные модули оригинальной архитектуры смешаны вместе, что раздувает и затрудняет расширение, а онлайн-качество не может быть гарантировано. Поэтому мы быстро скорректировали структуру и разделили услугу, разделили платежную систему на платежную систему и кассовую систему и сузили область платежной системы до управления статусом оплаты заказа на главной станции; в то время как касса, возврат и другие виды деятельности внешних платежных учреждений. Он передается в кассовую систему, и связь между информацией о заказе и платеже заменяется уникальным серийным номером транзакции в Yanxuan.
Строгий выбор схемы структуры кассира
Благодаря обновлению архитектуры могут быть достигнуты более гибкие возможности конфигурации.Разные учетные записи могут видеть разные настраиваемые страницы кассира в разных модулях продукта и терминалах, что в значительной степени удовлетворяет требованиям бизнес-партнеров верхнего уровня. В то же время кассовый аппарат скрывает различия моделей и сложность подключения к третьим сторонам.В дизайне служба уведомления о платеже и служба возврата объединены в асинхронный режим обратного вызова, что снижает сложность бизнеса верхнего уровня. доступ.
На среднесрочном этапе разработки, когда необходимо вести себя сдержанно и сдержанно, в то время как канал оплаты подвергся структурным обновлениям, различия в товарах также начали влиять на канал транзакции заказа, например атрибуты категории товаров и стоимость доставки товаров. .Если взять подарочную карту в качестве примера, подарочная карта - это особый товар, который может быть использован в качестве средств в ссылке транзакции после покупки и привязки пользователя Электронная подарочная карта не требует выполнения договора на доставку, но должна быть связана с дополнительными услуги по изготовлению карт.В процессе покупки также необходимо определить, требуется ли аутентификация по реальному имени в зависимости от суммы. В исходной архитектуре мы применяем специальную обработку для этого товара в каждом звене транзакции, но связь относительно глубокая, с виртуальными товарами (карты очков, телефонные счета) и нестандартными товарами (очки, индивидуальные продукты). Техническая группа обновила исходную структуру и абстрагировала концепцию шаблона транзакции.Шаблон транзакции может предоставлять возможности настройки на странице расчетов, например, использовать ли подарочные карты, использовать ли купоны/красные конверты, использовать ли пользователя. дополнительная дополнительная информация. Заказы, сгенерированные по разным шаблонам транзакций, также будут привязаны к разным идентификаторам транзакций для последующей стыковки бизнес-модуля и обработки в центре заказов.
На текущем этапе цветения мы работаем над платформизацией подарочных карт, предоставляя настраиваемые стратегии потребления и реверса для подарочных карт, чтобы он мог построить строго выбранную базовую матрицу обслуживания транзакций вместе с платежной системой и кассиром. система.В то же время мы также рассматриваем возможность расширения шаблона транзакций, который может эффективно связать ссылку расчета заказа с базовой матрицей обслуживания транзакций и поддерживать сценарии транзакций в рамках различных бизнес-моделей за счет возможностей конфигурации платформы.
В будущем Yanxuan Planning может сделать еще один шаг вперед, в то время как существующая структура транзакций постепенно становится трехмерной, и сформировать полную платформу торгового центра Yanxuan.Платформа торгового центра включает в себя не только услуги корзины покупок, услуги заказа и платежные услуги. Общие возможности транзакций также обеспечат возможность оркестрации полных транзакций, обеспечивая более надежную поддержку предприятий верхнего уровня. В то же время, с расширением модели строгого отбора до офлайн, он также активно изучает офлайн-сценарий модели транзакций, реализуя связь онлайн- и офлайн-данных и предоставляя потребителям лучший опыт покупок.
Техническое накопление в процессе практики структуры сделкиВ процессе эволюции вся распределенная архитектура Yanxuan, с одной стороны, удовлетворяет требованиям высокой доступности системы и высокой пропускной способности, с другой стороны, как и большинство интернет-компаний, также сталкивается с общей непротиворечивостью данных, балансом ресурсов и т. д. В процессе решения этих проблем постепенно осаждается некоторое промежуточное ПО собственной разработки Yanxuan.
Управление транзакционным процессом — распределенные блокировки и распределенные транзакцииВо-первых, давайте поговорим о распределенных блокировках. dlock — это промежуточное программное обеспечение распределенной блокировки, которое является строго реентерабельным, блокируемым, тайм-аутом, высокодоступным, высокопроизводительным, недорогим и эластично масштабируемым (общая архитектура показана на рисунке ниже). Его дизайн преследует в основном две цели:
-
Синхронизируйте доступ к ресурсам в распределенной среде, подходящей для таких сценариев, как несколько машин, несколько процессов, несколько потоков и один поток;
-
Замените дорогостоящие, плохо масштабируемые блокировки базы данных с большими накладными расходами.
dlock можно адаптировать к различным типам инфраструктуры кэширования, таким как Redis, Memcached, Zookeeper и т. д. Емкость dlock можно масштабировать по горизонтали в соответствии со спросом.
dlock поддерживает 3 различных типа стратегий повторного входа в блокировку, а именно: повторный вход на уровне потока, повторный вход на уровне процесса и распределенный повторный вход Эти стратегии повторного входа могут полностью удовлетворить требования распределенных блокировок в сложных сценариях бизнеса Yanxuan.
Второй — распределенные транзакции. Чтобы обеспечить согласованность данных между распределенными системами в процессе транзакций, Yanxuan разработал промежуточное программное обеспечение для распределенных транзакций DTS. DTS соответствует типу BASE и представляет собой типичную транзакцию типа TCC (Try/Confirm/Cancel).Вся архитектура DTS показана на следующем рисунке:
DTS оптимизирован для двухэтапной фиксации, называемой оптимизацией последнего участника (LPO): инициатор распределенной транзакции не имеет двух фаз, а только одну фазу, то есть после того, как все участники будут готовы к первой фазе, результат ее фиксации непосредственно определяется Успех или неудача распределенных транзакций.
Управление ресурсами транзакций — механизм и стратегия изоляции основных ресурсовЧтобы перехватывать аномальный трафик, такой как пролистывание и атаки, и в то же время разумно ограничивать обычный пользовательский трафик, eudemon строго выбран для исследований и разработки промежуточного программного обеспечения ограничения трафика и аварийного предохранителя. eudemon перемещает абстракцию доступа к таким ресурсам, как CPU, MEM и DB, на уровень вызовов методов и доступа к страницам и косвенно защищает от перегрузки ресурсов, ограничивая вызовы методов и доступ к страницам. Общая архитектура eudemon показана на следующем рисунке:
eudemon контролирует трафик на двух уровнях:
-
Перехват мошеннического и атакующего трафика: анализируя поведенческие характеристики субъектов трафика, можно перехватить более 99% мошеннического и атакующего трафика, предотвращая конкуренцию этого черного трафика с обычным трафиком за системные ресурсы и снижая влияние последующего контроля рисков. системы давление.
-
Управление и автоматический выключатель для нормального трафика: разумно ограничивайте обычный пользовательский трафик, срезайте пики и заполняйте спады, всегда следите за тем, чтобы приток трафика не превышал нагрузку на систему, и в то же время предохраняйте службы в чрезвычайных ситуациях.
Как сделать изоляцию ресурсов? Система становится все более и более распределенной архитектурой.Чем больше сервисных узлов, тем больше каскадных сбоев приводит к усилению сбоев отдельных узлов в распределенной архитектуре. В дополнение к сосредоточению внимания на эвдемоне управления входящим потоком, Yanxuan разработала эгиду промежуточного программного обеспечения для изоляции ресурсов, которая фокусируется на управлении исходящим потоком.
В распределенном канале, когда служба зависит от нескольких нисходящих служб, текущая служба может быть затронута или даже вызвать лавинный эффект из-за недоступности нисходящей службы или медленного отклика. Типичным, с которым мы столкнулись в Интернете, был медленный SQL.Появление медленного SQL приводило к резкому увеличению нагрузки на базу данных, что приводило к базовой кратковременной внезапной недоступности БД, что приводило к недоступности всей службы или системы.
Процесс изоляции ресурсов Aegis показан на рисунке выше и использует механизм динамической изоляции, который можно изолировать в соответствии с бизнес-измерениями. Например, в сценарии использования распределенной базы данных вместо изоляции всей распределенной базы данных можно изолировать только один из отказавших узлов БД.
Резюме и размышления - основная концепция практики промежуточного программного обеспечения YanxuanYanxuan Middleware всегда придерживалась концепции решения наиболее основных технических проблем с наименьшими затратами, придерживаясь убеждения в том, что бизнес основан на технологиях, и всегда предоставляла всестороннюю поддержку, в основе которой лежит бизнес.Построение промежуточного программного обеспечения следует двухдвигательной модели «открытый исходный код + самоисследование», с открытым исходным кодом в качестве опоры, самоисследованием в качестве дополнения и обратной связью по открытому исходному коду.Стоя на плечах гигантов с открытым исходным кодом, можно снизить затраты на исследования и разработки Yanxuan и компенсировать недостатки открытого исходного кода за счет самоисследования.Благодаря отзывам об открытом исходном коде он может вернуть техническую мощь Yanxuan для процветания. мира с открытым исходным кодом.
Проблемы и контрмеры в продвижении транзакцийБольшое продвижение в электронной коммерции — лучшая проверка архитектурного дизайна и накопления технологий. В особом сценарии с высокой степенью параллелизма пиковое значение часто бывает в несколько раз или даже на несколько порядков.Некоторые, казалось бы, стабильные системы и службы также могут вызывать проблемы в экстремальных ситуациях параллелизма.
В мероприятиях по продвижению с коротким циклом особенно важна ссылка на транзакцию: от корзины до заказа и оплаты любой сбой в любой ссылке может повлиять на эффект операционной деятельности. Оглядываясь назад на производительность Yanxuan в предыдущих рекламных акциях, основные проблемы, с которыми столкнулась торговая система, заключаются в следующем:
-
Разумное использование ресурсов базы данных
-
Стабильность и своевременность платежных услуг
-
Защита от внешних атак
База данных является сильно зависимым компонентом системы транзакций и требует очень высокой согласованности данных. Например, мы обычно используем транзакции для обеспечения строгой согласованности. Однако с развитием бизнеса транзакции становятся раздутыми, производительность снижается в сценариях с высоким уровнем параллелизма, ресурсы базы данных могут легко стать узкими местами, а некоторые узлы данных затрагиваются сразу. что повлияет на всю службу заказа и даже на весь процесс транзакции. Чтобы обеспечить большое продвижение, Yanxuan разобрала транзакцию, разобрала основной бизнес и непрофильный бизнес.Непрофильный бизнес должен быть максимально дополнен асинхронным и компенсационным механизмом.Дробление транзакций основного бизнеса сведен к минимуму, и распределенная блокировка Лендинг с распределенными транзакциями. После демонтажа размер транзакций имеет тенденцию быть разумным.В то же время в DDB (распределенная база данных NetEase) выбирается соответствующая стратегия разделения пользователей для эффективного распределения транзакций разных пользователей по разным узлам базы данных, чтобы избежать горячих точек.
Стабильность и своевременность оплаты является еще одной большой проблемой.Если платежная служба дрожит или обратный вызов не своевременный во время большой акции, это может привести к относительно большой потере интереса пользователей за короткий период времени, а также жалобы клиентов. увеличивать. В рамках расширенного мониторинга мы также будем строго изолировать и разделять ресурсы, сохраняя определенную степень гибкости и своевременно изолируя некоторые каналы с нестабильными услугами. В то же время будут подготовлены активные стратегии запросов и повторных попыток, чтобы вы могли переключиться в режим резервного копирования вовремя, когда обратный вызов не удастся. При этом была сделана небольшая оптимизация на стороне пользователя, а для успокоения пользователей добавлена ожидающая копия в обработке платежей.
Кроме того, торговой системе также могут угрожать внешние атаки.Время от времени происходят вредоносные действия, такие как считывание онлайн-заказов и считывание купонов.Если торговый интерфейс напрямую подвергается атакам, торговые ресурсы будут искажены, что может серьезно тянуть вниз всю систему обслуживания системы. Поэтому мы выстраиваем надежный щит вне торговой системы для защиты интересов основных пользователей.Подобно общепринятой практике в отрасли, защита Yanxuan также начинается с начального уровня и выявляет вредоносные запросы с помощью функций доступа для первой защиты. злонамеренные запросы через синтаксис mvel Ключевой интерфейс ссылки на транзакцию вмешивается, логика бизнес-службы основной транзакции обычно связана с интерфейсом запроса управления рисками для точного анализа пользователей.Благодаря этим трем уровням защиты тщательно отобранные основные соединения надежно защищены.
Наконец, давайте поговорим о процессе и стратегии большой гарантии продвижения Yanxuan, которая в основном разделена на три этапа.
Первый этап — это этап оценки, на котором основное внимание уделяется подготовке к оценке ресурсов и стресс-тестированию. Путем декомпозиции показателей, рассчитанных по большому продвижению, установки показателей пропускной способности интерфейса и показателей отклика ключевых транзакционных звеньев системы, оценки соответствия существующей пропускной способности системы требованиям и формулирования соответствующих планов расширения. При этом в стресс-тесте модуля и полнолинковом стресс-тесте разбираются существующие показатели сервиса, а на основе отчета о тестировании анализируется узкое место и формулируется план оптимизации.
Затем наступает этап подготовки. На этом этапе мы подробно сформулируем текущий лимит, план понижения и аварийного восстановления для крупной транзакции по продвижению. Например, для сценария транзакции seckill мы также подготовим как минимум два набора управления запасами. планы, чтобы мы могли вовремя переключиться, когда сервис выйдет из строя. . Все ссылки на транзакции подтверждают отсутствие мониторинга, от корзины покупок до страницы расчетов и завершения работы кассира, формулируют соответствующие планы обнаружения, разрешения и компенсации для каждого потенциального сценария сбоя транзакции и реализуют его конкретному лицу в обвинение. После того, как план будет завершен, он пройдет полный стресс-тест и частичный модульный тест вместе с тестом для проверки достоверности.
Последний этап -этап реализации.Даже при полной подготовке в онлайне все равно могут возникать различные непредвиденные ситуации.При возникновении сбоя в ходе акции своевременный стоп лосс - первый принцип.В это время готовятся текущие лимитирующие и даже фьюжн планы все может пригодиться, и в то же время необходимо сразу проанализировать причину и составить план ремонта с наименьшими затратами, и сразу же опубликовать его в сети.
об авторе
Ма Чао, технический менеджер NetEase Yanxuan, присоединился к подразделению NetEase Mail в 2013 году и последовательно участвовал в исследованиях и разработках различных продуктов NetEase для почтовых ящиков. С 2015 года он отвечает за исследования и разработки торгового центра Yanxuan.За последние два года он руководил и завершил множество преобразований и усовершенствований технической структуры, способствуя быстрому развитию бизнеса Yanxuan. В то же время он провел команду через множество повышений, чтобы обеспечить стабильность системы. Он имеет богатый практический опыт в области высокой параллелизма, распределения, оптимизации бизнес-систем, а также исследований и разработок промежуточного программного обеспечения.