Проект «Логистическая платформа»
Облачное решение для автоматизации городской курьерской доставки
Наша логистическая платформа — это простое и эффективное облачное решение, которое автоматизирует все ключевые этапы курьерской доставки: от создания заказа до его финального исполнения. Мы обеспечиваем полную прозрачность и контроль для менеджеров и клиентов.
Ключевые функции платформы
Управление заказами и курьерами
Централизованное создание и отслеживание заказов. Эффективное управление статусами доставки и текущей загрузкой курьеров.
Оптимизация маршрутов
Автоматическое построение самых быстрых и коротких маршрутов для каждого курьера, минимизируя время в пути и расход топлива.
Трекинг в реальном времени
Отслеживайте текущее местоположение курьеров на интерактивной карте, обеспечивая полный контроль над процессом доставки.
Автоматические уведомления |
Гибкая тарификация |
SMS и e-mail оповещения клиентов на каждом этапе доставки, |
Легкая настройка правил расчета стоимости доставки для |
повышая их удовлетворенность и снижая нагрузку на службу |
различных районов города и типов услуг. |
поддержки. |
|
Архитектура системы управления доставкой на основе
микросервисов
Представляем платформу для автоматизации процессов логистики и доставки, разработанную с учетом современных требований к масштабируемости, гибкости и отказоустойчивости. Наш подход основан на передовых принципах микросервисной архитектуры.
Микросервисная |
Слабая связанность |
архитектура |
|
Централизованная конфигурация
Декомпозиция системы на микросервисы
Система состоит из независимых, но взаимодействующих сервисов, каждый из которых отвечает за свою область функциональности.
Order Service |
Courier Service |
Route Optimization Service |
Полный жизненный цикл заказа, назначение |
Управление профилями, статусами курьеров, |
Расчет оптимальных маршрутов (TSP/VRP), |
курьеров, валидация бизнес-правил. |
контроль загрузки и статистика. |
определение ETA, геокодирование. |
Notification Service |
Tracking Service |
|
Отправка уведомлений (SMS/email), управление |
Прием и обработка GPS-координат, генерация гео- |
шаблонами и каналами. |
событий. |
Управление поведением системы без переписывания
кода
Гибкость бизнес-логики достигается за счет вынесения критически важных параметров в централизованно управляемые конфигурационные файлы.
1Config Server
Централизованный сервер конфигурации для всех микросервисов.
Примеры Параметров
2Макс. вес заказа, порог рейтинга курьера, выбор алгоритма оптимизации маршрутов, каналы уведомлений.
Преимущества
3Быстрая адаптация к изменениям, повышенная безопасность чувствительных данных, согласованность конфигураций.
Сценарий: Создание и выполнение заказа
Рассмотрим типичный сценарий, демонстрирующий взаимодействие микросервисов для обработки заказа.
Клиент |
Order Service |
Оптимизация |
Курьерская служба |
Трекинг |
|
маршрута |
|
•Создание заказа: Клиент формирует заказ через Order Service.
•Оптимизация: Order Service запрашивает Route Optimization Service для расчета маршрута и ETA.
•Назначение курьера: Order Service выбирает и назначает доступного курьера через Courier Service.
•Отслеживание и уведомления: Tracking Service отслеживает курьера, а Notification Service информирует клиента о статусах заказа.
•Завершение: После доставки Order Service обновляет статус, передавая данные в Courier Service для статистики.
Выводы и достигнутые результаты
Масштабируемость
Независимое масштабирование каждого сервиса.
Гибкость
Настройка бизнес-логики через конфиги, быстрое внедрение функций.
Надежность
Изоляция сбоев, устойчивость к отказам.
Поддержка DevOps
Независимые циклы разработки и развертывания.
Наша инфраструктура включает централизованное управление конфигурацией (Config Server + Git), брокер сообщений для асинхронной связи, выделенные БД для каждого сервиса, а также интеграцию с CI/CD и системами мониторинга.
Инфраструктурные компоненты логистической платформы
Наша логистическая платформа построена на надёжной и масштабируемой инфраструктуре, использующей современные облачные технологии.
Облачная среда
Yandex Cloud, с развертыванием в двух ключевых регионах для обеспечения высокой доступности: Москва (основной) и Санкт-Петербург (резервный).
Вычислительные ресурсы
Используем Yandex Compute Cloud и Managed Kubernetes для управления микросервисами: Order, Courier, Route Optimization, Tracking, Notification, API Gateway и другими.
Базы данных
Managed PostgreSQL с отдельными БД для каждого сервиса. Мастер-узлы расположены в Москве, а read-реплики — в Санкт-Петербурге для геораспределённого чтения.
Кэш и очереди
Redis, RabbitMQ и Kafka используются для обработки геоданных, позиций курьеров и событий, обеспечивая быструю и надёжную передачу информации.
Сети и балансировщики |
Мониторинг и логирование |
Виртуальные частные облака (VPC), подсети по регионам, Security Groups, балансировщики нагрузки L4/L7 и Global Load Balancer для эффективного распределения трафика.
Prometheus и Grafana для метрик, Loki/ELK для централизованного логирования и Cloud Monitoring для общего контроля состояния системы.
Инструменты Infrastructure as Code
Для автоматизации управления инфраструктурой мы используем подход Infrastructure as Code (IaC), что позволяет повысить надёжность и скорость развёртывания.
1 |
2 |
3 |
Terraform |
Ansible |
Pulumi |
Описание сетей, виртуальных машин, кластеров БД и Kubernetes в облаке. Terraform обеспечивает декларативность, управление состоянием и модульную структуру для повторного использования компонентов (VPC, БД, кластеры).
Используется для пост-провизионирования: настройки ОС, RabbitMQ, Redis, Config Server. Его агентless-архитектура удобна для гибкой конфигурации программного обеспечения.
Позволяет описывать инфраструктуру на привычных языках программирования, таких как TypeScript или Python, интегрируясь с существующей экосистемой разработки.
Все изменения автоматически применяются через GitLab CI с использованием Docker Registry и Terraform pipelines, обеспечивая непрерывную доставку инфраструктуры.
Пример IaC: Terraform — сети и регионы
Terraform позволяет эффективно управлять распределённой инфраструктурой, автоматизируя создание ресурсов в разных регионах.
variable "cloud_id" {} variable "folder_id" {} variable "regions" {
type = list(string)
default = ["ru-central1", "ru-central2"] # Москва, Санкт-Петербург
}
provider "yandex" {
cloud_id |
= var.cloud_id |
folder_id |
= var.folder_id |
zone |
= var.regions[0] # регион по умолчанию |
}
resource "yandex_vpc_network" "main" { name = "logistics-network"
}
resource "yandex_vpc_subnet" "subnets" {
for_each |
= toset(var.regions) |
name |
= "subnet-${each.value}" |
zone |
= "${each.value}-a" |
network_id |
= yandex_vpc_network.main.id |
v4_cidr_blocks |
= ["10.${index(var.regions, each.value) + 10}.0.0/24"] |
}
•var.regions: Определяет список активных регионов, например, Москва и Санкт-Петербург.
•При добавлении нового региона в этот список Terraform автоматически создаст необходимые подсети, что значительно упрощает масштабирование.
•Использование конструкции for_each позволяет динамически создавать ресурсы VPC для всех указанных регионов без дублирования кода, обеспечивая чистоту и поддерживаемость конфигурации.
Этот подход гарантирует консистентность и снижает вероятность ошибок при расширении географии развёртывания.
Примеры IaC: Ansible и Pulumi
Ansible и Pulumi дополняют Terraform, управляя конфигурацией и динамическим масштабированием ресурсов.
Ansible: Настройка RabbitMQ
-hosts: rabbitmq_nodes become: yes
-name: Установка RabbitMQ apt:
name: rabbitmq-server state: present
-name: Настройка имени кластера RabbitMQ lineinfile:
path: /etc/rabbitmq/rabbitmq.conf
regexp: '^cluster_name'
line: "cluster_name = {{ rabbitmq_cluster_name }}"
Pulumi: Кластер Redis
import * as yc from "@pulumi/yandex";
const redisSizeGb = Number(process.env.REDIS_SIZE_GB || "4");
const cache = new yc.mdb.RedisCluster("geo-cache", { name: "geo-cache",
config: {
version: "7.0",
}, resources: {
resourcePresetId: "hm1.nano", diskSize: redisSizeGb, diskTypeId: "network-ssd",
},
});
•Размер диска для кластера Redis динамически задаётся через переменную окружения REDIS_SIZE_GB.
• |
Масштабирование кластера RabbitMQ упрощается до добавления |
• Изменение этого параметра в системе CI/CD (например, с 4 ГБ на 16 |
|
|
новых хостов в группу rabbitmq_nodes. |
ГБ) автоматически инициирует масштабирование хранилища, |
|
• |
Имя кластера задаётся через переменную rabbitmq_cluster_name, что |
обеспечивая гибкость и адаптивность инфраструктуры к меняющимся |
|
требованиям. |
|||
|
позволяет легко управлять конфигурациями для различных окружений |
||
|
|
||
|
(dev/stage/prod) без изменения самого плейбука. |
|