На уровне архитектуры опишите, как вы спроектируете микросервисную систему для онлайн-магазина: какие границы сервисов, способы коммуникации, схемы масштабирования и мониторинга вы предложите

10 Дек в 08:21
5 +1
0
Ответы
1
Границы сервисов (высокоуровнево)
- API Gateway — маршрутизация, аутентификация, rate‑limit, агрегация ответов.
- Auth / Identity — регистрация, вход, JWT/OAuth2, управление ролями.
- Catalog — описание товаров, категории, медиа (статичное хранение в CDN).
- Inventory — текущее количество, блокировки резерва при оформлении.
- Pricing — цены, акции, промокоды (может быть отдельный сервис с кешем).
- Cart — временные корзины, сохраняемые/анонимные; синхронизация с Inventory/Pricing.
- Orders — создание заказа, статус, взаимодействие с Payment и Shipping.
- Payment — интеграции платёжных провайдеров, обработка вебхуков, idempotency.
- Shipping / Fulfillment — расчёт доставки, трекинг, взаимодействие с внешними логистами.
- Notifications — email/SMS/push (асинхронно по событиям).
- Search / Recommendations — полнотекстовый поиск (Elasticsearch), модель рекомендаций.
- Analytics / Reporting — события бизнес‑аналитики, ETL в хранилище.
- Admin / Backoffice — управление товарами, возвратами, поддержка.
Способы коммуникации
- Внешний интерфейс: REST/JSON или gRPC через API Gateway для frontend/mobile.
- Синхронные вызовы между сервисами при необходимости реального результата (gRPC/HTTP+timeouts).
- Асинхронная коммуникация через event bus / message broker (Kafka / RabbitMQ) для согласованности, интеграций и аудита: события типа OrderCreated, InventoryReserved, PaymentSucceeded.
- Для сложных распределённых транзакций — saga (choreography или orchestration) + компенсирующие действия.
- Idempotency: каждый критический запрос снабжать idempotency key.
- Контракты: OpenAPI / protobuf + CI‑тесты контрактной совместимости.
Консистентность и модели данных
- CQRS: чтение из денормализованных read models (Elastic/Redis), запись в authoritative write models (RDBMS/NoSQL).
- Event sourcing — опционально для Orders/Inventory, если нужна полная история изменений.
- Для Inventory: optimistic or pessimistic reserving в зависимости от бизнес‑требований; использовать компенсирующие события.
Схемы масштабирования
- Статeless сервисы горизонтально масштабируются: контейнеры / k8s + HPA по CPU/latency/custom metrics.
- Stateful компоненты:
- БД заказов (RDBMS): master‑write, read replicas; при большой нагрузке — шардирование по tenant/order_id.
- NoSQL для каталога: разграничение по каталожным категориям, репликация.
- Kafka: partitioning для параллелизма; количество партиций ∝ консьюмеров.
- Кеширование: CDN для статики; Redis/Memcached для сессий, кэша цен/каталога.
- Балансировка нагрузки: L4/L7 (Ingress, ALB), sticky sessions не рекомендуется (использовать токены).
- Пример простого расчёта количества инстансов:
- количество инстансов = ⌈RPSпиковыйRPSна_инстанс⌉\left\lceil\frac{\text{RPS}_\text{пиковый}}{\text{RPS}_\text{на\_инстанс}}\right\rceilRPSна_инстанс RPSпиковый .
Например, если RPSпиковый=5000\text{RPS}_\text{пиковый}=5000RPSпиковый =5000 и RPSна_инстанс=200\text{RPS}_\text{на\_инстанс}=200RPSна_инстанс =200, то инстансов ⌈5000200⌉=25\left\lceil\frac{5000}{200}\right\rceil=252005000 =25.
- Репликация и устойчивость: хранение минимум replicas=3\text{replicas}=3replicas=3 для критичных данных, регулярные бэкапы и point‑in‑time recovery.
Надёжность и устойчивость
- Circuit breaker, bulkhead, retry с backoff, timeouts.
- Rate limiting на уровне API Gateway: per‑user и per‑IP.
- Canary / blue‑green deployments для безопасного релиза.
- Chaos testing для проверки отказоустойчивости.
Мониторинг, логирование, трассировка
- Метрики: Prometheus + Alertmanager. Основные SLI/SLO: latency (p95/p99), error rate, throughput, availability.
- Пример пороговой проверки: error_rate>0.05\text{error\_rate} > 0.05error_rate>0.05 → alert.
- Централизованные логи: EFK/ELK (Elasticsearch + Fluentd/Logstash + Kibana).
- Distributed tracing: OpenTelemetry / Jaeger для трассировки межсервисных запросов.
- Health checks: liveness/readiness probes в k8s; endpoint /health.
- Dashboards: Grafana — latency, QPS, backlog очередей, consumer lag (Kafka).
- Alerts: на нарушение SLO, рост consumer_lag, уменьшение свободного места диска, падение реплик БД.
Операционные практики
- Теги и метрики per‑service, per‑team; runbooks для типичных инцидентов.
- CI/CD: автоматические тесты контрактов, миграций DB, blue/green deploys.
- Безопасность: секреты в vault, TLS mTLS между сервисами, WAF на Gateway.
Короткий список приоритетов при проектировании
1. Разделять по бизнес‑функциям (bounded contexts).
2. Асинхронная коммуникация для слабой связности и устойчивости.
3. Горизонтальное масштабирование stateless‑сервисов + шардирование/репликация stateful.
4. Полноценный мониторинг и tracing с SLO/alerting.
5. Тщательная обработка ошибок, idempotency и saga для консистентности.
Если нужно — могу дать диаграмму взаимодействий, пример схемы шардирования или конкретные выборы технологий под нагрузку/бюджет.
10 Дек в 08:28
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Прямой эфир