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

  • Tutorial

Аgorafreight.com — первый в России сервис для онлайн-расчета стоимости и заказа авиа-, авто- и контейнерных перевозок, сборных грузов всеми видами транспорта, включая ставки «от двери до двери».


image

Об истории проекта Agorafreight рассказывает руководитель проектов Reksoft (входит в ГК «Техносерв») Дмитрий Долгих.


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


Проект сам по себе очень интересный и амбициозный. Интересный как минимум тем, что такого решения в России еще нет. Слово «международный» придавало проекту неоднозначность — с одной стороны, заявлялись амбиции проекта в плане масштабирования на весь мир, а с другой — мы понимали, что проекту предстоит прокладывать дорогу в достаточно конкурентной среде. Частью такой среды всегда являются и способность проекта быстро реагировать на изменения, и неожиданные развороты с точки зрения требований. Все это сразу задавало определенный уровень ответственности в выборе архитектуры решения, тем более что и времени на реализацию первой версии продукта было достаточно мало.


Для начала предстояло выбрать базу данных, а вернее систему управления данными. Выбор пал на MongoDB — документоориентированную базу данных NoSQL с поддержкой геозапросов, полнотекстового поиска на 15 языках, с иерархической структурой данных. Система MongoDB доступна бесплатно под лицензией GNU 3.0. Она масштабируется горизонтально и может быть использована в качестве файлового хранилища с балансировкой нагрузки и репликацией данных.
Плюсы


  1. Иерархичность данных — возможность оптимизировать схему и запросы к иерархическим данным (мультиязычность, тарифы и т. п.).
  2. Schema-less, нежесткая схема данных — дешевые и быстрые изменения в схеме БД, которая не требует миграций.
  3. Масштабируемая — это дешевле, чем у реляционных БД, не требует переработки исходного кода или переписывания запросов к БД.
  4. Поддержка геозапросов и индексов, полнотекстового поиска.
  5. Открытая система с открытым исходным кодом.
  6. Есть возможность купить платную поддержку у авторов MongoDB, enterprise-поддержка.
  7. MongoDB может быть использована в качестве файлового хранилища с балансировкой нагрузки и репликацией данных.
  8. С MongoDB легче и быстрее прототипировать приложения и сервисы.

Минусы
1. Нет поддержки Join'ов, однако эту проблему решает иерархия данных или MapReduce-функционал (но не на 100%).


  1. Транзакции отсутствуют, есть атомарность на уровне документов, можно реализовать эмуляцию транзакций.
  2. Консистентность на уровне БД не реализована, необходимо это делать в исходном коде приложения.
  3. Нет триггеров как в классических БД, однако часто этот функционал не используют.

Особенности


  1. MongoDB не требует администрирования на старте и немного после него, требуется настройка для масштабирования.
  2. Существуют хостинг-провайдеры, которые могут предоставить MongoDB в облаке под нужные масштабы, такие сервисы редко встретишь у MySQL или PostgreSQL.
  3. Лидер среди NoSQL-хранилищ данных на данный момент.
  4. Обладает инструментами для построения MapReduce-запросов, которые можно использовать для построения сложных отчетов, но не в real-time.
  5. Критические недостатки этой БД были решены с выходом 3-й версии.

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


Этот выбор, как показала последующая практика, оказался верным. Все случилось так, как и предполагалось, — постоянные изменения в постановке, доработки из серии «а мы вот это еще хотели реализовать» и все это требовало гибкого и оперативного изменения модели данных. MongoDB позволила проекту не только адекватно реагировать на изменения, но и не «выпасть» из бюджета. Как известно, недоработки на этапе проектирования приводят к существенному реинжинирингу при реализации и повышению рисков непопадания в сроки и в бюджет проекта. Все эти риски удалось минимизировать в том числе и за счет выбранной архитектуры.


Вторым архитектурным выбором стала библиотека ReactJS для реализации фронтенда. Именно популярность технологии и большое сформированное сообщество позволило сделать выбор в пользу ReactJS.


Плюсы данного фреймворка:


  1. Один из самых популярных фреймворков для разработки клиента. Имеет большое сообщество, есть множество примеров его использования, хорошая документация.
  2. Те разработчики нашей компании, которые имеют опыт работы с ним, хорошо о нем отзываются.
  3. Более гибкий в плане разработки в сравнении, например, с Angular.
  4. Поддерживает так называемый Server Rendering, который позволяет индексировать страницы приложения поисковыми системами.
  5. Подходит для приложений с большим количеством динамических страниц. У нас много таких страниц (формы ввода различных видов тарифов, надбавок, комиссий; формы расчета стоимости перевозки и т. д.)

В итоге ReactJS позволил достаточно гибко и динамично менять части фронтенда на фоне меняющихся требований и доработок.


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


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


image
Техносерв
79,00
Компания
Поделиться публикацией

Комментарии 1

    0
    Убер для грузоперевозок — и прям таки первый?:)

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

    Самое читаемое