Технические проблемы экспортной электронной коммерции + трансграничная логистика: пример приложения MongoDB

Резюме

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

Об экспортной легкой логистике

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

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

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

На картинке выше показана наша глобальная логистическая сеть. Эти склады бывают большими и малыми, и склад в Великобритании является нашим основным складом. По состоянию на 2017 год у нас есть в общей сложности восемь складских центров в Китае, в основном в Шэньчжэне, Гуанчжоу и Шанхае.

Платформы, с которыми мы сотрудничаем, рекомендуют наших поставщиков логистических услуг, таких как Amazon, ebay, Wish, Ali International, shopee, AliExpress и LAZADA.

Наша предыдущая система — это структура в левой части рисунка выше, она ориентирована на сторонние ERP мерчантов, набор систем, разработанных некоторыми мерчантами, а некоторые платформы имеют прямое взаимодействие с нашей системой. Доступ к некоторым из них осуществляется через набор пользовательских интерфейсов, предоставляемых ExportEase, и существует большое количество онлайн-доставок, для доступа к которым мы будем использовать API. У нас есть фон управления администратором и отдельная система WMS в фоновом режиме.

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

Есть несколько платежных шлюзов для оплаты, а также есть интерфейсы с paypal, alipay, payoneer и банками.

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

Монолитное приложение: интерфейсные и серверные системы совместно используют набор решений для веб-приложений.

Единая база данных: используется база данных MS SQLServer, и основные бизнес-функции совместно используют одну базу данных.

Полные бизнес-функции: ИТ-система постоянно расширяет новые функции по мере развития бизнеса. Чтобы удовлетворить самые основные функциональные требования для ведения трансграничной логистической электронной коммерции.

Простота тестирования и развертывания: одно решение имеет мало системных зависимостей После развертывания можно протестировать все функции.

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

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

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

Технический долг: Логика системы чрезвычайно сложна, со временем меняется персонал и накапливается технический долг.

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

Дизайн, ориентированный на домен: каждая команда бизнес-модуля отвечает за все разработки, связанные с доменом или бизнес-функцией. Основные домены реализуются в соответствии с четко определенными правилами в DDD.

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

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

Аутентификация: для каждой службы требуется единая аутентификация входа.

Аутентификация: Разным пользователям требуется аутентификация при использовании одного и того же сервисного модуля.

Доступ к страницам осуществляется посредством единого входа, включая API на основе OAuth2. Внутреннее использование — это логическая архитектура, такая как DDD, включая прикладной уровень и доменный уровень. Уровень предметной области также включает в себя модель предметной области, подобъекты сущностей, службы предметной области, события предметной области и спецификации запросов.

На основе складирования для хранения заказа необходимо соединить сущность и подобъект вместе для сохранения и обновления в базе данных.

Когда мы делаем приложения, мы предпочитаем доводить дело до конца, поэтому выбираем mangoDB. У нас есть набор собственной архитектуры, и мы будем инкапсулировать mangoDB в один слой в процессе инкапсуляции.

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

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

1. Нетранзакционная герметичность. Допуск ошибок данных относительно высок.

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

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

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

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

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

Запрос агрегации необходимо запрашивать через конвейер агрегации MongoDB Драйвер MongoDB C# обеспечивает хорошую поддержку, но он относительно громоздкий по сравнению с запросом Linq.

Репозитории ограничены операциями со всем корнем агрегата, обеспечивая сохранение и перестроение или запрос корня агрегата.

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

Простые объекты CLR (простые объекты Java), которые не наследуют какие-либо базовые классы инфраструктуры сохраняемости и не реализуют какие-либо интерфейсы инфраструктуры сохраняемости. Уровень предметной области не ссылается на библиотеку классов MongoDB. Слой хранилища MongoDB использует лямбда-выражение для реализации карты классов.

Существуют различные генераторы идентификаторов на выбор. GuidGenerator, OjbectIdGenerator, String OjbectIdGenerator и т. д. Мы всегда используем тип String для идентификатора. Поэтому используйте MongoDB StringObjectIdGenerator напрямую.

Если вы сопоставляете полиморфные классы (наследование) с MongoDB, вам необходимо указать известный тип.

NamedIdMemberConvention может указать, какие свойства класса можно использовать в качестве идентификаторов.

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

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

Эта функция была представлена ​​в MongoDB 2.2 и представляет собой новую структуру для агрегации данных.

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

На самом деле это альтернатива MapReduce, но более простая, чем MapReduce.

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

$project: проекция данных, в основном используется для переименования, добавления и удаления полей.

$match: операция фильтрации, фильтрация документов, соответствующих условиям, в качестве входных данных следующего этапа.

$limit: ограничение количества документов, проходящих через конвейер.

$skip: количество документов, которые нужно пропустить с начала коллекции, над которой нужно работать.

$unwind: разделить элементы массива на отдельные поля.

$group: сгруппировать данные.

$sort: Сортировка документа в соответствии с указанным полем.

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

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

Он относительно прост в использовании и, как и MapReduce, может работать с сегментированными коллекциями.

Результат вывода может быть сохранен только в одном документе с учетом ограничения размера документа BSON (в настоящее время 16M).

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

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