Гео-распределённая инфраструктура и базы данных
Глобальный балансировщик |
Микросервисы |
Москва Санкт Петербу (основной) рг (резерв)
Kubernetes кластер |
PostgreSQL реплики |
• Основной и резервный регионы: Москва является основным регионом, а Санкт-Петербург — резервным, обеспечивая высокий уровень отказоустойчивости и непрерывности работы.
•Распределенные компоненты: Stateful-компоненты, такие как PostgreSQL и Redis, спроектированы для эффективной работы в двух регионах, гарантируя сохранность данных.
•Global Load Balancer: Stateless-микросервисы могут быть автоматически перераспределены через Global Load Balancer в случае сбоя основного региона, минимизируя время простоя.
Как параметры влияют на развёртывание
Каждый параметр в конфигурации инфраструктуры оказывает существенное влияние на производительность, отказоустойчивость, стоимость и гибкость системы.
Список регионов (Terraform: variable |
Добавление нового региона в переменную |
Автоматическое создание сетей и подсетей, возможность деплоя |
"regions") |
|
ближе к пользователям, рост отказоустойчивости, но и увеличение |
|
|
затрат. |
Количество узлов Kubernetes |
Увеличение node_count с 3 до 5 |
Выше производительность и отказоустойчивость кластера, но |
(node_count) |
|
прямо пропорциональный рост стоимости облачных ресурсов. |
Ресурсы БД (CPU/RAM, размер диска) |
Увеличение RAM у PostgreSQL с 4 до 8 ГБ |
Вертикальное масштабирование, снижение латентности запросов |
|
|
и рост пропускной способности, но значительное увеличение |
|
|
стоимости. |
Количество реплик БД (число host {}) |
Добавление ещё одной read-реплики PostgreSQL |
Выше отказоустойчивость и возможность разгрузки мастер-узла |
|
|
за счёт распределения чтений, но дополнительная нагрузка на сеть |
|
|
и расходы на ресурсы. |
Размер Redis / кэша (Terraform/Pulumi |
Увеличение diskSize Redis с 4 до 16 ГБ |
Больше кэша приводит к меньшему количеству обращений к |
параметры) |
|
основной БД, снижению латентности, но увеличивает стоимость |
|
|
хранения и вычислительных ресурсов. |
Параметры Ansible (группы хостов, |
Добавление нового хоста в группу 'rabbitmq_nodes' |
Масштабирование сервисов происходит автоматически без |
переменные) |
|
необходимости изменения самих плейбуков, что обеспечивает |
|
|
гибкость и простоту управления. |
Оптимизация этих параметров критически важна для баланса между производительностью, надёжностью и стоимостью эксплуатации логистической платформы.
К главному классу приложения добавляем аннотацию @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
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
Пример файла order-service-dev.yml
# Зоны доставки 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"
Процесс загрузки конфигураций
Рассмотрим процесс загрузки конфигураций на примере микросервиса order-service.
Для начала в order-service необходимо подключить зависимость spring-cloud-starter-config.
<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