- •Проект «Логистическая платформа»
- •Архитектура системы управления доставкой на основе
- •Декомпозиция системы на микросервисы
- •Управление поведением системы без переписывания
- •Сценарий: Создание и выполнение заказа
- •Выводы и достигнутые результаты
- •Инфраструктурные компоненты логистической платформы
- •Инструменты Infrastructure as Code
- •Пример IaC: Terraform — сети и регионы
- •Примеры IaC: Ansible и Pulumi
- •Гео-распределённая инфраструктура и базы данных
- •Как параметры влияют на развёртывание
- •К главному классу приложения добавляем аннотацию @EnableConfigServer:
- •Репозиторий с конфигурациями приложений
- •Исходя из этого, структура нашего репозитория с конфигурациями будет выглядеть так:
- •Пример файла order-service-dev.yml
- •Пример файла order-service-dev.yml
- •Процесс загрузки конфигураций
- •Процесс загрузки конфигураций
- •Этапы развертывания пайплайна
- •Механизм деплоя и обновления
- •Проверка и откат изменений
- •Региональные тарифные политики
- •СПАСИБО ЗА ВНИМА
Процесс загрузки конфигураций
При запуске исполняемого 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.
Архитектура CI\CD для
Безопасное развертывание тарифных политик в разные регионы Цель пайплайна конфигураций
●Автоматическое обновление конфигураций без перезапуска сервисов
●Поддержка разных тарифных политик для Москвы и Санкт-Петербурга
●Гарантия корректности изменений через автоматические проверки
Ключевые компоненты
●Git-репозиторий конфигураций (config- repo)
●Spring Cloud Config Server
●Микросервисы с @RefreshScope
●Механизм автоматического обновления
через /actuator/refresh
config-repo/
├── order-service/
│ ├── order-service-dev.yml │ ├── order-service-stage.yml │ └── order-service-prod.yml └── courier-service/
├── courier-service-dev.yml └── courier-service-prod.yml
Система построена на принципах GitOps, где все изменения конфигураций проходят через version-controlled репозиторий. Это обеспечивает полную трассируемость изменений и возможность быстрого отката.
Этапы развертывания пайплайна
Многостадийная проверка и деплой
1. Валидация
●Проверка синтаксиса YAML-файлов
●Валидация по JSON-схеме
●Проверка обязательных полей тарифов
2.Тестирование
●Unit-тесты расчета стоимости доставки
●Проверка бизнес-логики для разных городов
●Тестирование граничных значений
3.Деплой в Staging
●Пуш изменений в Git-репозиторий
●Автоматическое обновление Config Server
●Вызов /actuator/refresh для сервисов
4.Интеграционное тестирование
●Сквозные тесты создания заказа
●Проверка расчета маршрутов
●Тестирование уведомлений
5.Деплой в Production
●Ручное подтверждение изменений
●Последовательное обновление сервисов
●Мониторинг применения конфигураций
Каждый этап служит защитным барьером, предотвращая попадание некорректных конфигураций в production. Ручное подтверждение на последнем этапе дает бизнесу контроль над критическими изменениями.
Механизм деплоя и обновления
Hot-reload конфигураций через Spring cloud config
@Service
@RefreshScope
public class OrderService { @Value("${delivery.tariffs.standard.price}") private String deliveryPrice;
// Конфигурация обновляется без перезапуска
}
Процесс обновления
deploy-production: stage: deploy-production script:
- python scripts/deploy_configs.py --environment prod when: manual
only: changes:
- "**/*-prod.yml"
Автоматизация в GitLab CI
# order-service-prod.yml delivery:
zones: moscow:
available_tariffs: ["standard", "express", "free"] peak_hours_surcharge: 1.3
spb:
available_tariffs: ["standard", "express"] bridge_surcharge: 1.2
Деплой в разные регионы
Механизм @RefreshScope позволяет обновлять конфигурации без перезапуска сервисов, что критически важно для высоконагруженной логистической платформы. Разные города имеют уникальные параметры тарификации
Проверка и откат изменений
Гарантия надежности развертывания
Проверки после деплоя
●Health checks через Spring Boot Actuator - мониторинг состояния сервисов
●Smoke-тесты тарифных политик - проверка расчета стоимости в реальных сценариях
●Мониторинг метрик в реальном времени - отслеживание ключевых показателей
●Проверка отсутствия регрессий - контроль качества после изменений
Процедура отката
●Автоматическое создание Git-тега при успешном деплое
●Возможность revert через Git до предыдущей стабильной версии
●Последовательный откат сервисов через механизм refresh
●Подтверждение успешности отката через smoke-тесты
Мониторинг и алертинг
●Алерт при неудачном обновлении конфигурации - мгновенное оповещение
●Мониторинг ошибок расчета тарифов - контроль бизнес-логики
●Отслеживание успешности применения конфигов - метрики развертывания
Система отката обеспечивает быстрое восстановление работоспособности платформы в случае проблем с новыми конфигурациями, минимизируя impact на бизнес-процессы.
rollback-configs:
stage: deploy-production script:
- python scripts/rollback_configs.py --commit $PREVIOUS_COMMIT
when: manual # Ручной запуск при необходимости
Механизм отката
Региональные тарифные политики
Поддержка Москвы и Санкт-Петербурга
Преимущества подхода
●Гибкость - изменения тарифов без перезапуска сервисов
●Локализация - разные политики для разных городов в одном пайплайне
●Надежность - автоматическая проверка корректности конфигураций
●Безопасность - быстрый откат при необходимости
●Прозрачность - полная версионность и трассируемость изменений
Бизнес-ценность
●Сокращение времени внедрения новых тарифных политик с дней до минут
●Возможность A/B тестирования тарифов в разных регионах
●Снижение операционных рисков за счет автоматизированных проверок
●Улучшение времени реакции на рыночные изменения
Описание: Региональный подход позволяет учитывать уникальные особенности каждого города (пробки в Москве, мосты в Петербурге), обеспечивая оптимальную тарифную политику и повышая удовлетворенность клиентов.
delivery: tariffs: standard:
price: 300 # Базовая стоимость express:
price: 1500 # Премиальная доставка
zones: |
|
moscow: |
|
# Московские специфичные настройки |
|
peak_hours_surcharge: 1.3 |
# Надбавка в часы пик |
center_zone_multiplier: 1.5 |
# Умножитель для |
центра |
|
available_tariffs: ["standard", "express", "free"] |
|
spb: |
|
# Питерские специфичные настройки |
|
bridge_surcharge: 1.2 |
# Надбавка за мосты |
historical_center_multiplier: 1.4 # Умножитель для исторического центра
available_tariffs: ["standard", "express"]
Структура региональных настроек
