Лекция 164: Основные принципы микросервисной архитектуры (SLA, независимое развертывание)

Сегодня мы углубимся в принципы микросервисной архитектуры, такие как Service Level Agreement (SLA) и независимое развертывание, а также затронем децентрализованное управление данными.

Service Level Agreement (SLA): обещание вашему миру

SLA можно представить как договор между микросервисом и его потребителями (другими сервисами, клиентами, или компанией в целом). В этом договоре прописаны чёткие гарантии: как быстро сервис должен отвечать, с какой доступностью он работает и какие показатели надежности он должен соблюдать. SLA — это ваш личный KPI для микросервиса.

Для примера: если вы разрабатываете сервис обработки платежей, SLA может включать такие требования:

• 99.9% времени доступности (время простоя не более 43 минут в месяц).
• Время ответа API менее 200 миллисекунд.
• Обработка не менее 1000 запросов в секунду при пике нагрузки.

Как установить SLA?

1. Понимание бизнес-ценности: выясните, насколько критична работа каждого микросервиса для компании. Например, система авторизации критична, а сервис рекомендаций может иногда "прихрамывать".
2. Измеримые показатели: установите чёткие метрики: время ответа, доступность, пропускная способность.
3. Мониторинг: система мониторинга должна фиксировать выполнение SLA.

пример SLA

⚙️ Платёжный сервис (Payment Service):
- Доступность: 99.95%
- Время ответа: меньше 250 мс для 95% транзакций
- Максимальное время восстановления после сбоя: 5 минут

Важно помнить: если один из микросервисов нарушает SLA, это может отразиться на всей экосистеме приложения!

Независимое развертывание: микросервисы на своих двоих

Когда вы разрабатываете монолитное приложение, любое изменение требует пересборки всего проекта, прохождения всех тестов и деплоя на сервер. Если ваш проект весит пару гигабайтов и состоит из 200 разработчиков с параллельно работающими командами — готовьтесь к адовым ночам релизов.

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

Как организовать независимое развертывание

1. Делите на функциональные блоки. Каждый микросервис должен представлять законченный функционал, например:

• Сервис авторизации
• Сервис обработки платежей
• Сервис доставки уведомлений

2. Минимизируйте связи между сервисами. Используйте REST или асинхронные очереди, такие как Kafka. Если сервисы слишком тесно связаны, вы принесёте монолитные проблемы в мир микросервисов.

Пример асинхронного взаимодействия:

@Service
public class PaymentProducer {

    private final KafkaTemplate<String, String> kafkaTemplate;

    public PaymentProducer(KafkaTemplate<String, String> kafkaTemplate) {
        this.kafkaTemplate = kafkaTemplate;
    }

    public void notifyPaymentProcessed(String paymentId) {
        kafkaTemplate.send("payment-topic", paymentId);
    }
}

Сервис оплаты отправляет сообщение в Kafka, не заботясь о том, кто и когда его получит.

3. Используйте CI/CD. Новая версия микросервиса деплоится автоматически после тестов. Пример настроек CI/CD пайплайна для микросервиса:

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script: mvn clean package
  artifacts:
    paths:
      - target/*.jar

test:
  stage: test
  script: mvn test

deploy:
  stage: deploy
  script: |
    scp target/*.jar user@server:/apps/microservice
    ssh user@server "sudo systemctl restart microservice"

Децентрализованное управление данными: никаких "богатых" баз данных

Модульность данных — это краеугольный камень микросервисов. В идеале, каждый микросервис должен владеть собственной базой данных, чтобы исключить конкуренцию за ресурсы и риски одновременного изменения одной таблицы разными сервисами.

Подходы к управлению данными:

1. Разделение данных по микросервисам Каждый сервис контролирует свою базу данных. Например:
   • Сервис заказов управляет таблицами orders и order_items.
   • Сервис пользователей управляет таблицами users и profiles.
2. CQRS и Event Sourcing Используйте подход CQRS (Command Query Responsibility Segregation), чтобы разделить чтение и запись данных. Например, команда изменения статуса заказа отправляет событие, которое затем обрабатывает другой сервис.

Пример CQRS с использованием событий:

// Отправка события
public void updateOrderStatus(Order order) {
    order.setStatus(OrderStatus.PROCESSING);
    orderRepository.save(order);
    eventPublisher.publish(new OrderUpdatedEvent(order.getId(), order.getStatus()));
}

Практическое применение

Вы только что узнали, как SLA, независимое развертывание и децентрализация данных делают микросервисы мощным инструментом разработки. Эти принципы обеспечивают гибкость, масштабируемость и надёжность, которые так важны для современных приложений.

Но стоит понимать: каждая из этих концепций требует внедрения серьёзных инструментов. Например, для реализации SLA и децентрализованного управления данными понадобятся системы мониторинга, такие как Prometheus, для отслеживания метрик производительности, а также архитектурные решения вроде Kafka или RabbitMQ для асинхронной коммуникации.

Микросервисы помогли Netflix и Uber достичь масштабов мирового уровня. Учитывая, что их успех зиждется на принципах SLA, независимости деплоя и грамотного управления данными, эти же подходы могут помочь и вашему проекту — будь это стартап или корпоративное приложение.