МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ, СВЯЗИ И
МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ
Ордена Трудового Красного Знамени федеральное государственное
бюджетное образовательное учреждение высшего образования
«МОСКОВСКИЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ
СВЯЗИ И ИНФОРМАТИКИ»
(МТУСИ)
Кафедра «Сетевые информационные технологии и сервисы»
Проект «Логистическая платформа»
по учебной дисциплине:
«Программно-конфигурируемая архитектура приложений и инфраструктуры»
-
Выполнили:
студенты
Архангельский Максим Вячеславович
Ларин Никита Сергеевич
Китова Евгения Александровна
Каширский Александр Александрович
(Ф.И.О.)
группа
БСТ2154
Проверил:
Фильков Ярослав Дмитриевич, ассистент кафедры СИТиС
(Ф.И.О., должность преподавателя)
Оценка
Дата
Москва 2025
Содержание
Введение 3
1. Общая архитектурная схема 4
Описание проектируемых модулей и их ответственности 8
Пример 2. Ansible настройка узла с RabbitMQ и Docker. 18
Ansible-плейбука для конфигурации ВМ под брокер сообщений и Docker-рантайм: 18
Динамическое обновление конфигураций 29
Введение
Данный проект посвящен разработке архитектуры облачной логистической платформы для автоматизации управления курьерской доставкой в городских условиях. Система предназначена для комплексного решения задач управления заказами, курьерами, маршрутизации и отслеживания доставки в реальном времени. Ключевые цели платформы включают: автоматизацию полного цикла доставки - от создания заказа до финального исполнения курьером, оптимизацию маршрутов на основе интеллектуальных алгоритмов, обеспечение прозрачности процесса для всех участников через систему трекинга, а также автоматическую коммуникацию с клиентами посредством SMS и e-mail уведомлений. Бизнес-процесс платформы охватывает все этапы: от создания заказа менеджером через веб-интерфейс, формирования оптимальных маршрутов для курьеров, исполнения доставки с отслеживанием в мобильном приложении, до автоматического уведомления клиентов о завершении заказа.
Программная конфигурируемость является критически важным требованием для системы, поскольку позволяет оперативно адаптировать бизнес-логику платформы к изменяющимся условиям рынка - гибко настраивать тарифные политики для разных зон города, правила расчета стоимости доставки, параметры уведомлений и географические зоны обслуживания без необходимости переписывания кода и длительных простоев. В основе архитектурного решения лежит микросервисный подход, развернутый в облачной среде, что обеспечивает необходимую масштабируемость, отказоустойчивость и независимость компонентов. Управление конфигурацией реализовано через централизованный config-сервер, который предоставляет всем микросервисам настройки из version-controlled YAML файлов, что гарантирует согласованность конфигураций, контроль версий и быстрое развертывание изменений по всему стеку приложения.
1. Общая архитектурная схема
Логистическая платформа построена по микросервисной архитектуре с использованием облачной инфраструктуры. Данное решение обеспечивает масштабируемость, отказоустойчивость и независимость разработки компонентов.
Ключевые принципы:
Геораспределенность: Инфраструктура развернута в нескольких регионах (в г. Москва и г. Санкт-Петербург) для низких задержек и соответствия требованиям Федерального закона от 27.07.2006 №152-ФЗ «О персональных данных».
Разделение ответственности: Каждая бизнес-логика вынесена в отдельный сервис.
Событийный подход: Сервисы обмениваются данными асинхронно через брокера сообщений (RabbitMQ/Kafka), что повышает отказоустойчивость.
API Gateway: Единая точка входа для всех внешних запросов (веб-интерфейс, мобильные приложения).
Централизованная конфигурация: Все сервисы получают настройки из единого Config Server.
Описание имеющихся модулей и сервисов:
API Gateway: Единая точка входа. Маршрутизирует запросы к нужным сервисам, занимается аутентификацией, кэшированием и ограничением запросов (Rate Limiting).
Order Service: Ядро системы. Отвечает за полный жизненный цикл заказа: создание, редактирование, получение статуса. Хранит данные в PostgreSQL.
Courier Service: управляет данными курьеров (профиль, статус "активен/неактивен", текущее задание). Хранит данные в PostgreSQL.
Route Optimization Service: Высоконагруженный сервис. Получает список адресов, вызывает внешний геокодер (например, Yandex Maps API) и строит оптимальный маршрут с помощью алгоритмов (например, TSP-решатель). Для кэширования геоданных и временных результатов использует Redis.
Tracking Service: принимает поток GPS-координат от мобильных приложений курьеров через WebSocket или долгий polling. Агрегирует и сохраняет актуальное местоположение в Redis для быстрого доступа. Отправляет события о значимых перемещениях в брокер сообщений.
Notification Service: слушает события из брокера сообщений (например, "заказ создан", "заказ доставлен"). Отправляет уведомления клиентам через SMS (SMS-шлюз) или E-mail (SMTP-сервер).
Размещение инфраструктуры:
Платформа: Yandex Cloud.
Регионы: Основной регион — Москва, резервный — Санкт-Петербург. Это геораспределенная инфраструктура.
Реализация: В Москве развертываются все сервисы и основные базы данных (PostgreSQL). В Санкт-Петербурге развертываются read-реплики баз данных и инстансы Stateless-сервисов (Order, Courier), которые могут быть перенаправлены туда через Global Load Balancer в случае сбоя в основном регионе.
Управление: Вся инфраструктура описывается как код (IaC) с помощью Terraform (создание виртуальных машин, сетей, баз данных) и Ansible (настройка ПО на этих машинах).
Хранение и загрузка конфигурации:
Хранилище: Конфигурационные файлы (в формате YAML) хранятся в отдельном Git-репозитории (например, GitLab). Это "единый источник истины" для всех настроек.
Сервер конфигураций: В инфраструктуре развернут Spring Cloud Config Server (или аналог). Он подключается к Git-репозиторию и предоставляет REST API для других сервисов.
Загрузка: Каждый микросервис при своем запуске обращается к Config Server по его адресу (указанному в переменных окружениях сервиса) и загружает свою конфигурацию. Например, order-service запрашивает order-service.yml.
Взаимодействие между компонентами выстроено следующим образом:
Все взаимодействия инициируются через API Gateway. Веб-интерфейс, мобильные приложения и клиентский портал не имеют прямого доступа к внутренним сервисам. Все запросы (создание заказа, просмотр статуса) проходят через единую точку входа — API Gateway.
Синхронные взаимодействия (HTTP/REST) выполняются через API Gateway. Gateway маршрутизирует входящие запросы к соответствующему сервису (например, запрос «POST /orders» направляется в Order Service, а «GET /couriers» — в Courier Service).
Сервисы обмениваются данными синхронно для оперативных задач. Order Service вызывает Courier Service, чтобы проверить доступность курьера перед назначением заказа. Order Service вызывает Route Optimization Service для немедленного расчета маршрута по требованию менеджера.
Асинхронные взаимодействия (через события) реализованы через брокера сообщений. Сервисы-«издатели» (например, Order Service) помещают события (ORDER_CREATED) в брокер (RabbitMQ). Сервисы-«подписчики» (например, Notification Service) независимо получают эти события из брокера и выполняют свою логику (отправка SMS). Это исключает прямые зависимости между сервисами.
Внешние интеграции выполняются напрямую специализированными сервисами. Route Optimization Service напрямую обращается к внешнему API геокодера (Яндекс.Карты) для преобразования адреса в координаты. Notification Service напрямую взаимодействует с внешними шлюзами (SMS, email) для отправки уведомлений.
Доступ к данным осуществляется по принципу «один сервис — одна база данных». Каждый сервис работает исключительно со своей базой данных (Order Service → order_db, Courier Service → courier_db). Прямой доступ к чужой БД запрещен.
Разделяемые данные кэшируются в Redis. Route Optimization Service и Tracking Service используют Redis как общее высокопроизводительное хранилище для геоданных и актуальных местоположений курьеров.
Конфигурация загружается централизованно при запуске. Каждый микросервис при старте обращается к Config Server по его адресу (из переменных окружения) и загружает свои настройки (тарифы, правила) из YAML-файлов.
На рисунке 1 представлена схема взаимодействия компонентов.
Рисунок 1 — Схема взаимодействия компонентов