JavaRush /Курси /Модуль 5. Spring /Лекція 164: Основні принципи мікросервісної архітектури (...

Лекція 164: Основні принципи мікросервісної архітектури (SLA, незалежне розгортання)

Модуль 5. Spring
Рівень 11 , Лекція 3
Відкрита

Сьогодні ми зануримося в принципи мікросервісної архітектури, такі як 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, незалежності розгортання і грамотного управління даними, ці самі підходи можуть допомогти й вашому проєкту — будь то стартап чи корпоративний додаток.

Коментарі
ЩОБ ПОДИВИТИСЯ ВСІ КОМЕНТАРІ АБО ЗАЛИШИТИ КОМЕНТАР,
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ