Внешними провайдерами SMS/email — отправка сообщений.

7. С инфраструктурой (IaC):

• Каждый сервис имеет выделенную БД (PostgreSQL).

• Config Server развертывается как отдельный микросервис.

• Stateless-сервисы развертываются в нескольких регионах.

• Redis используется для кэширования и хранения сессий.

8. С CI/CD:

• Отдельные конвейеры сборки для каждого сервиса.

• Автоматическое тестирование API между сервисами.

• Canary-деплойменты для критических сервисов.

• Изменения в конфигах проходят code review в GitLab.

9. С мониторингом:

• Метрики по количеству заказов, времени доставки, SLA.

• Трассировка запросов через цепочку сервисов.

• Audit log всех изменений конфигурации.

• Централизованное логирование всех бизнес-событий.

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

3. Ларин Никита Сергеевич – Роль: инженер инфраструктуры (IaC)

Основные задачи:

• Проектирование и автоматизацию развёртывания гео-распределённой инфраструктуры в двух регионах.

• Обеспечение масштабируемости, отказоустойчивости и безопасности инфраструктуры.

• Обеспечение повторяемости и контроля версий инфраструктуры с помощью инструментов IaC.

Инфраструктурные компоненты логистической платформы

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

Таблица 1 — Инфраструктурные компоненты

Ключевая особенность все stateful-компоненты (PostgreSQL, Redis) спроектированы с учётом работы в двух регионах, а stateless-микросервисы развёрнуты в нескольких зонах отказа и могут быть перераспределены через Global Load Balancer при сбое в основном регионе.

Инструменты Infrastructure as Code (IaC)

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

Таблица 2 — Инструменты IaC

Дополнительно используются:

• CI/CD-системы (GitLab CI) — для автоматического применения Terraform / Ansible плейбуков по merge в main-ветку.

• Модули Terraform — для повторного использования типовых блоков (VPC, БД, Kubernetes-кластер, Redis-кластер).

Примеры конфигураций

Пример 1. Terraform: базовая сеть и два региона.

Упрощённый пример описания VPC и подсетей в двух регионах:

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 — список регионов. Добавив новый регион, мы автоматически получаем новую подсеть в конфигурации.

• for_each позволяет масштабировать VPC во все регионы без копирования кода.

• Изменение региона (например, добавление "ru-central3") приведёт к созданию новой подсети и возможностей деплоя сервисов туда без ручных шагов.

Пример 2. Ansible настройка узла с RabbitMQ и Docker.

Ansible-плейбука для конфигурации ВМ под брокер сообщений и Docker-рантайм:

- hosts: rabbitmq_nodes

become: yes

vars:

rabbitmq_cluster_name: "logistics-mq"

tasks:

- name: Обновление пакетов

apt:

update_cache: yes

upgrade: dist

- name: Установка Docker

apt:

name: docker.io

state: present

- 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 }}"

- name: Перезапуск RabbitMQ

service:

name: rabbitmq-server

state: restarted

enabled: yes

Примечания:

• Через переменную rabbitmq_cluster_name можно управлять именами кластеров для разных окружений (dev/stage/prod).

• Добавляя новые хосты в группу rabbitmq_nodes, масштабируется кластер без изменения логики плейбука.

• Этот же подход используется для настройки Redis, Config Server, API Gateway и других инфраструктурных компонентов.

Пример 3: Pulumi (TypeScript) создание Redis-кластера.

Небольшой пример Pulumi для создания Redis-инстанса, с параметром size:

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_SIZE_GB.

• Изменение параметра в CI/CD (например, с 4 на 16 ГБ) автоматически масштабирует хранилище без ручной переконфигурации.

Изменение параметров влияющие на развёртывание

Развёртывание напрямую зависит от параметров в IaC-конфигурации: региона и зоны, количества инстансов (узлы Kubernetes, ВМ, реплики БД), типов и размеров ресурсов (CPU, RAM, диски), объёма кэша, настроек репликации и отказоустойчивости. Изменение этих значений пересчитывает план и приводит к созданию, изменению или удалению соответствующих ресурсов.

Смена или добавление региона автоматически создаёт сети, подсети и при необходимости новые кластеры БД и узлы приложений. Рост числа инстансов масштабирует кластеры горизонтально, изменение характеристик ВМ и БД — вертикально, влияя на производительность. Так параметры в конфигурации становятся управляемым механизмом эволюции инфраструктуры: все изменения хранятся в системе контроля версий, проходят code review и применяются через CI/CD, что позволяет предсказуемо адаптировать инфраструктуру без ручных операций в облаке. Данные о параметрах и их влиянии представлены в таблице 3.

Таблица 3 — Параметры и их влияние

Инфраструктура облачной логистической платформы на базе IaC

Инфраструктура логистической платформы для курьерской доставки развернута в облаке и полностью описана с помощью подхода Infrastructure as Code (IaC). Все ресурсы (сети, базы данных, кластеры, сервисы) задаются в виде конфигураций Terraform/Ansible/Pulumi и хранятся в системе контроля версий, что обеспечивает воспроизводимость и единообразие окружений (dev, stage, prod).

Облачная инфраструктура гео-распределена: используется основной регион (Москва) и резервный (Санкт-Петербург). В IaC-конфигурациях параметризуются регионы и зоны доступности, создаются VPC, приватные подсети для микросервисов и баз данных, а также публичные точки входа для API Gateway. Правила безопасности (firewall, security groups) также описаны как код, что упрощает аудит и изменение политик доступа.

Микросервисы (Order, Courier, Route Optimization, Tracking, Notification, API Gateway, Config Server) запускаются в кластере Kubernetes или на группах ВМ, которые управляются через IaC: задаются типы инстансов, количество узлов, политики авто-масштабирования. Изменение параметров (например, числа узлов или их характеристик) выполняется через изменение переменных в конфигурации и автоматически применяется пайплайнами CI/CD.

Каждый сервис использует собственную базу данных PostgreSQL; в основном регионе располагаются мастер-узлы, в резервном — read-реплики. Для кэша и временных данных используется кластер Redis, а для событийного обмена — брокер сообщений (RabbitMQ/Kafka). Топология этих кластеров (число узлов, объёмы дисков, схемы репликации) управляется IaC, что позволяет быстро масштабировать и переносить их между регионами.

Централизованный Config Server и менеджер секретов разворачиваются теми же инструментами IaC и обеспечивают микросервисам доступ к бизнес-настройкам (тарифы, временные окна, правила уведомлений) и чувствительным данным (пароли, ключи API). Мониторинг, логирование и алертинг также описаны как код (дашборды, правила, экспортёры), что позволяет стандартизировать наблюдение за всеми компонентами платформы. Благодаря этому изменение любых инфраструктурных параметров (регион, количество инстансов, ресурсы БД и кэша) становится контролируемым, повторяемым и прозрачно отражается в истории изменений.

Ключевой момент автоматизации инфраструктуры

Ключевой момент автоматизации инфраструктуры в логистической платформе — управление всеми ресурсами кодом. Сети, БД, кластеры, кэш, брокер сообщений, балансировщики и мониторинг описаны декларативно IaC и хранятся в Git. Любые изменения (регион, типы ВМ, параметры репликации) вносятся через правку конфигураций и применяются пайплайнами CI/CD. Это делает инфраструктуру воспроизводимой, предсказуемой, легко масштабируемой и позволяет быстро подключать новые регионы или изменять топологию без ручных операций.

4. Китова Евгения Александровна – Роль: Разработчик конфигурационной системы

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

• Сократить время внесения изменений.

• Делегировать настройку конфигураций бизнес-аналитикам.

• Упростить тестирование различных сценариев. YAML был выбран благодаря:

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

2. Минимализу. Отсутствие избыточных символов делает файлы более лаконичными и аккуратными по сравнению с JSON или XML.

3. Поддержке сложных структур. YAML позволяет легко описывать многоуровневые и сложные структуры данных с помощью вложенных отступов, что сохраняет структуру и читаемость.

4. Разнообразию типов данных. Формат поддерживает широкий спектр типов данных, включая списки, словари, строки, числа и другие.

Для работы с файлами конфигураций был выбран Spring Cloud Config. Это набор инструментов для централизованного управления настройками в распределенных системах и микросервисах. Он представляет собой отдельное Spring Boot-приложение (сервер конфигураций), которое предоставляет настройки приложениям через REST API. В качестве источника данных для конфигураций используются такие системы, как Git-репозитории или файловая система.

Настройка Spring Cloud Config Server

Для начала нам нужно создать новый Spring Boot проект и подключить зависимость spring-cloud-config-server.

Пример для Maven:

<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-server</artifactId> </dependency>

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

application.yml:

server: port: 8888 spring: application: name: config-service cloud: config: server: git: uri: "https://gitlab.com/logistics-platform/config-repo.git"

username: username password: password default-label: main search-paths: "{application}"

И к главному классу приложения добавить аннотацию @EnableConfigServer:

@SpringBootApplication @EnableConfigServer public class ConfigServiceApplication { public static void main(String[] args) { SpringApplication.run(ConfigServiceApplication.class, args); } }

Репозиторий с конфигурациями приложений

Все конфигурации находятся в своих папках, где имя папки является именем микросервиса.

У нас есть следующие микросервисы: gateway, order-service, courier-service, route-optimization-service, tracking-service, notification-service. Также нам нужно предусмотреть возможность изменения конфигураций в зависимости от контура развертывания - stage/dev/prod. Файлы конфигурации, которые мы можем разместить в репозитории, должны соответствовать соглашению об именовании. Основная часть соглашения об именовании заключается в том, что файл должен быть назван в соответствии с именем приложения Spring, которому он соответствует. Это будет выглядеть следующим образом:

<spring.application.name> — <profile>.yml или .properties Свойство spring.application.name задаётся файлом application.yml клиентского приложения. «Profile» — это активный профиль клиентского приложения, то есть spring.profile.active. Этот параметр может быть задан при запуске исполняемого jar файла.

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

config-repo/

├── .git/

├── .gitignore

├── README.md

├── encryption/

│ ├── keys/

│ └── README.md

├── order-service/ # Order Service конфигурации

│ ├── order-service-dev.yml

│ ├── order-service-stage.yml

│ └── order-service-prod.yml

├── courier-service/ # Courier Service конфигурации

│ ├── courier-service-dev.yml

│ ├── courier-service-stage.yml

│ └── courier-service-prod.yml

├── route-optimization-service/ # Route Optimization Service конфигурации

│ ├── route-service-dev.yml

│ ├── route-service-stage.yml

│ └── route-service-prod.yml

├── tracking-service/ # Tracking Service конфигурации

│ ├── tracking-service-dev.yml

│ ├── tracking-service-stage.yml

│ └── tracking-service-prod.yml

├── notification-service/ # Notification Service конфигурации

│ ├── notification-service-dev.yml

│ ├── notification-service-stage.yml

│ └── notification-service-prod.yml

└── gateway/ # API Gateway конфигурации

├── gateway-dev.yml

├── gateway-stage.yml

└── gateway-prod.yml

Пример файла order-service-dev.yml:

logging:

pattern:

console: '%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n'

level:

com.company.logistics: INFO

org.springframework.cloud: INFO

datasource: url: jdbc:postgresql://localhost:5432/orders username: username password: password driver-class-name: org.postgresql.Driver hikari: maximum-pool-size: 10 minimum-idle: 0

delivery: # Настройки тарифов tariffs: standard: name: "Стандартная доставка" price: 300 min_order_amount: 0 max_order_amount: 5000 estimated_days: min: 2 max: 5 express: name: "Экспресс доставка" price: 1500 min_order_amount: 5000 max_order_amount: 10000 estimated_days: min: 1 max: 2 free: name: "Бесплатная доставка" base_price: 0 min_order_amount: 2000 max_order_amount: null estimated_days: min: 3 max: 7

# Зоны доставки zones: moscow: name: "Москва” available_tariffs: ["standard", "express", "free"] restrictions: max_weight: 50 moscow_region: name: "Московская область” available_tariffs: ["standard", "express"] restrictions: max_weight: 30 russia: name: "По России" available_tariffs: ["standard"] restrictions: max_weight: 20 # Временные ограничения time_restrictions: cutoff_time: "18:00" # время окончания приема заказов на сегодня working_hours: start: "09:00" end: "21:00" holidays: # нерабочие дни - "2024-01-01" - "2024-01-02" - "2024-01-07"

Таблица 4 – Примеры влияния изменения параметров конфигурации на поведение системы

Процесс загрузки конфигураций

Рассмотрим процесс загрузки конфигураций на примере микросервиса order-service. Для начала в order-service необходимо подключить зависимость spring-cloud-starter-config.

Пример для Maven:

<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-config</artifactId> </dependency>

В application.yml нужно задать имя приложения, за это отвечает свойство spring.application.name:

spring: application: name: order-service

Далее нужно указать откуда приложению получать конфигурации, то есть uri сервиса конфигураций, за это отвечает свойство spring.cloud.config.uri:

spring:

cloud:

config:

uri: http://localhost:8888

При запуске исполняемого jar файла нашего сервиса указываем нужный профиль (dev/stage/prod) с помощью параметра spring.profile.active:

java -jar order-service.jar --spring.profiles.active=dev

При запуске order-service фактически выполнит HTTP-запрос к config-service, используя имя своего приложения в качестве ключа, а затем добавит активный профиль. Запрос будет выглядеть следующим образом:

http://localhost:8888/order-service/dev

При получении этого запроса config-service выполнит поиск директории, наименование которой совпадает с наименованием приложения, которое инициировало запрос. Поиск будет выполняться в репозитории, который указан в application.yml config-service. Далее в найденной директории будет выполнен поиск файла, который соответствует формату:

<spring.application.name> - <profile>.yml

Таким образом будет найден файл order-service/order-service-dev.yml, содержимое которого config-service вернет order-service в качестве ответа на HTTP запрос в формате JSON.

Динамическое обновление конфигураций

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

Для возможности динамического обновления конфигураций необходимо добавить в pom.xml order-service следующую зависимость:

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>

Spring Boot Actuator добавляет эндпоинты мониторинга и управления приложением.

Чтобы обновления применялись без перезапуска, нужно использовать аннотацию @RefreshScope. Она "перезагружает" бины, если конфигурация обновилась.

Например, добавим аннотацию @RefreshScope в класс сервиса order-service

java

@Service @RefreshScope public class OrderService {

@Value ("${delivery.tariffs.standard.price}") private String standartDeliveryPrice; String getStandartDeliveryPrice () { return standartDeliveryPrice; } }

Теперь мы можем обновлять конфигурации, делая POST-запрос к /actuator/refresh:

curl -X POST http://localhost:8080/actuator/refresh

После этого изменённые значения будут динамически применяться, без какого-либо перезапуска.

5. Каширский Александр Александрович – Роль: DevOps / Интегратор

Схема CI/CD-конвейера для логистической платформы

Для обеспечения безопасного развертывания конфигураций тарифных политик в разные регионы спроектирован специализированный CI/CD-пайплайн, интегрированный с Spring Cloud Config Server.

Рисунок 2 — Схема CI/CD-пайплайна для конфигураций.

Этапы пайплайна для конфигураций:

1. Валидация конфигураций:

• Проверка синтаксиса YAML-файлов.

• Валидация по JSON-схеме для каждого микросервиса.

• Проверка обязательных полей тарифной политики.

2. Тестирование тарифных правил:

• Unit-тесты расчета стоимости доставки.

• Проверка корректности зон доставки.

• Тестирование бизнес-логики для валидации заказов.

3. Деплой в Staging:

• Пуш изменений в Git-репозиторий конфигураций.

• Автоматическое обновление Config Server.

• Вызов /actuator/refresh для сервисов в staging-окружении.

4. Интеграционное тестирование:

• Сквозные тесты создания заказа с новыми тарифами.

• Проверка расчета маршрутов.

• Тестирование уведомлений.

5. Ручное подтверждение:

• Подтверждение ответственным лицом.

• Проверка корректности тестовых данных.

6. Деплой в Production:

• Последовательное обновление сервисов через /actuator/refresh.

• Пуш изменений в production-ветку репозитория.

• Мониторинг применения конфигураций.

7. Верификация после деплоя:

• Smoke-тесты в production-среде.

• Проверка метрик в мониторинге.

• Контроль отсутствия регрессий.

Условия запуска этапов:

yaml

# .gitlab-ci.yml

variables:

CONFIG_REPO: "https://gitlab.com/logistics-platform/config-repo.git"

stages:

- validate

- test

- deploy-staging

- integration-test

- approve

- deploy-production

- verify

validate-order-config:

stage: validate

script:

- python scripts/validate_config.py order-service/order-service-prod.yml

only:

changes:

- "order-service/order-service-prod.yml"

validate-courier-config:

stage: validate

script:

- python scripts/validate_config.py courier-service/courier-service-prod.yml

only:

changes:

- "courier-service/courier-service-prod.yml"

test-tariffs:

stage: test

script:

- python scripts/test_tariff_rules.py

dependencies:

- validate-order-config

deploy-staging:

stage: deploy-staging

script:

- python scripts/deploy_configs.py --environment staging

only:

changes:

- "**/*-stage.yml"

- "**/*-prod.yml"

integration-tests:

stage: integration-test

script:

- python scripts/run_integration_tests.py --environment staging

dependencies:

- deploy-staging

deploy-production:

stage: deploy-production

script:

- python scripts/deploy_configs.py --environment prod

when: manual

only:

changes:

- "**/*-prod.yml"

Механизм деплоя конфигураций представлен следующим образом:

Архитектура деплоя на основе Spring Cloud Config:

yaml

# Конфигурация для сервисов с поддержкой @RefreshScope

apiVersion: apps/v1

kind: Deployment

metadata:

name: order-service

spec:

template:

spec:

containers:

- name: order-service

image: order-service:latest

env:

- name: SPRING_CLOUD_CONFIG_URI

value: "http://config-server:8888"

- name: SPRING_PROFILES_ACTIVE

value: "prod"

lifecycle:

postStart:

exec:

command:

- "/bin/sh"

- "-c"

- "sleep 30 && curl -X POST http://localhost:8080/actuator/refresh"

Процесс деплоя конфигураций:

1. Измененные YAML-файлы пушатся в Git-репозиторий config-repo.

2. Config Server автоматически обновляет кэш конфигураций.

3. Вызывается эндпоинт /actuator/refresh для каждого обновленного сервиса.

4. Сервисы с аннотацией @RefreshScope перезагружают конфигурацию без перезапуска.

Реализация тарифных политик для разных регионов

Структура конфигурации для order-service:

# order-service/order-service-prod.yml

delivery:

# Настройки тарифов (общие для всех регионов)

tariffs:

standard:

name: "Стандартная доставка"

price: 300

express:

name: "Экспресс доставка"

price: 1500

free:

name: "Бесплатная доставка"

base_price: 0

min_order_amount: 2000

# Региональные настройки

zones:

moscow:

name: "Москва"

available_tariffs: ["standard", "express", "free"]

restrictions:

max_weight: 50

# Московские специфичные настройки

peak_hours_surcharge: 1.3

center_zone_multiplier: 1.5

spb:

name: "Санкт-Петербург"

available_tariffs: ["standard", "express"]

restrictions:

max_weight: 40

# Питерские специфичные настройки

bridge_surcharge: 1.2

historical_center_multiplier: 1.4

# Временные ограничения

time_restrictions:

cutoff_time: "18:00"

working_hours:

start: "09:00"

end: "21:00"

Механизм применения региональных настроек:

java

// В коде OrderService

@RefreshScope

@Service

public class DeliveryCalculator {

@Value("${delivery.zones.moscow.restrictions.peak_hours_surcharge:1.0}")

private double moscowPeakHoursSurcharge;

@Value("${delivery.zones.spb.restrictions.bridge_surcharge:1.0}")

private double spbBridgeSurcharge;

public double calculatePrice(String city, String tariff, double basePrice) {

double price = basePrice;

if ("moscow".equals(city)) {

price *= getMoscowMultipliers();

} else if ("spb".equals(city)) {

price *= getSpbMultipliers();

}

return price;

}

}

Деплой и проверка конфигураций

Скрипт деплоя конфигураций:

python

# scripts/deploy_configs.py

def deploy_configs(environment):

# Валидация всех конфигов для целевого окружения

config_files = find_config_files(environment)

for config_file in config_files:

if not validate_config_schema(config_file):

raise Exception(f"Validation failed for {config_file}")

# Пуш в Git (если изменения еще не запушены)

git_add_commit_push(f"Update {environment} configurations")

# Ожидание обновления Config Server

wait_for_config_server_update()

# Постепенное обновление сервисов

services = detect_changed_services()

for service in services:

refresh_service_config(service, environment)

# Проверка здоровья после обновления

if not check_service_health(service):

rollback_service_config(service)

raise Exception(f"Health check failed for {service}")

def refresh_service_config(service_name, environment):

# Получение эндпоинтов сервиса из service discovery

endpoints = get_service_endpoints(service_name, environment)

for endpoint in endpoints:

response = requests.post(f"http://{endpoint}/actuator/refresh")

if response.status_code != 200:

logger.error(f"Refresh failed for {service_name} at {endpoint}")

Проверки после деплоя:

bash

#!/bin/bash

# Скрипт верификации деплоя. Проверка доступности сервисов

SERVICES=("order-service" "courier-service" "pricing-service")

for service in "${SERVICES[@]}"; do

response=$(curl -s -o /dev/null -w "%{http_code}" http://$service/actuator/health)

if [ "$response" != "200" ]; then

echo "Health check failed for $service"

exit 1

fi

done

# Smoke-тесты тарифных политик

echo "Running tariff smoke tests..."

python scripts/smoke_test_tariffs.py --city moscow --tariff standard

python scripts/smoke_test_tariffs.py --city spb --tariff express

# Проверка метрик

echo "Checking metrics..."

curl -s http://monitoring:9090/api/v1/query?query=config_reload_success | jq -e '.data.result[0].value[1] == "1"'

Откат изменений

Процедура аварийного отката:

yaml

# Ручной job для отката конфигураций

rollback-configs:

stage: deploy-production

script:

- |

python scripts/rollback_configs.py \

--environment prod \

--commit $PREVIOUS_COMMIT

when: manual

allow_failure: false

variables:

PREVIOUS_COMMIT: "a1b2c3d4"

Механизм отката:

1. Автоматическое создание тега при каждом успешном деплое.

2. Возможность revert изменений через Git.

3. Последовательный откат сервисов через /actuator/refresh.

4. Проверка корректности отката через smoke-тесты.

Интеграция с мониторингом

yaml

# Конфигурация алертинга для конфигурационных изменений

monitoring:

alerts:

- alert: ConfigRefreshFailed

expr: rate(config_refresh_failure_total[5m]) > 0

labels:

severity: critical

annotations:

description: "Сервис {{ $labels.service }} не смог обновить конфигурацию"

- alert: TariffCalculationErrors

expr: rate(tariff_calculation_errors_total[5m]) > 0.05

labels:

severity: warning

annotations:

description: "Высокий процент ошибок расчета тарифов после обновления конфигурации"

Интеграция с Spring Boot Actuator:

yaml

# В application.yml каждого сервиса

management:

endpoints:

web:

exposure:

include: "health,info,metrics,refresh"

endpoint:

health:

show-details: always

refresh:

enabled: true

Спроектированная система обеспечивает:

• Безопасное развертывание тарифных политик через Spring Cloud Config.

• Поддержку горячего обновления конфигураций через @RefreshScope.

• Интеграцию с существующей микросервисной архитектурой платформы.

• Автоматическую проверку корректности конфигураций.

• Возможность быстрого отката изменений.

• Полное соответствие требованиям программной конфигурируемости бизнес-логики.

Заключение

Разработанная логистическая платформа представляет собой единую, целостную систему, объединяющую все ключевые элементы управления процессом доставки — от оформления заказа до его завершения. Архитектурное разделение на четыре роли (администратор, оператор, курьер и клиент) отражает естественные процессы логистического бизнеса и реализовано через взаимодействие микросервисов, связанных общими API и системой централизованной конфигурации. Каждая роль оперирует в собственной подсистеме, но все они используют единое информационное пространство и согласованный набор сервисов: заказов, маршрутизации, уведомлений и аналитики. Таким образом, все компоненты образуют взаимосвязанную экосистему, в которой изменения бизнес-логики или настроек мгновенно распространяются на все уровни без необходимости модификации кода.

Выбранный подход к программной конфигурируемости обеспечивает высокую гибкость и управляемость платформы. Централизованный config-server позволяет динамически изменять параметры работы сервисов — тарифы, правила маршрутизации, зоны обслуживания, форматы уведомлений — без остановки системы. Это особенно важно для логистической отрасли, где внешние условия (спрос, цены, маршруты) меняются ежедневно. Программная конфигурируемость сокращает время реакции на бизнес-изменения, повышает отказоустойчивость и упрощает масштабирование: новые микросервисы автоматически получают актуальные настройки при запуске.

Вместе с тем, данный подход несёт определённые риски. Основные из них связаны с:

• повышенной сложностью управления зависимостями между микросервисами и конфигурациями;

• возможностью ошибок при централизованном изменении параметров;

• требованиями к надёжности инфраструктуры config-server и системы аутентификации.

Для их снижения предлагается использовать версионирование конфигураций в системе контроля версий (Git), внедрить процедуры автоматического тестирования и отката изменений, а также реализовать репликацию и резервное хранение данных конфигурационного сервера. Кроме того, важна строгая политика доступа: только администраторы должны иметь права на внесение изменений в производственные настройки.

Проведённое исследование показывает, что предложенная микросервисная облачная архитектура с централизованной программной конфигурируемостью является практически применимой для современных логистических и корпоративных систем. Она обеспечивает масштабируемость, модульность, независимое обновление компонентов и простоту интеграции с внешними сервисами (например, платёжными системами и API картографических сервисов). Подобный подход может быть успешно использован в проектах, требующих гибкой настройки бизнес-процессов, высокой доступности и быстрого развертывания в облачной среде.

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