Що таке мікросервіси, навіщо їх використовують?

Повне пояснення

Що це і навіщо

• Мікросервісна архітектура розділяє великий застосунок на дрібні, самодостатні сервіси.
• Кожен сервіс виконує конкретну бізнес‑логіку і спілкується через чітко визначені API (REST, gRPC).
• Переваги: незалежне розгортання, масштабування за потребою, швидка інтеграція нових технологій.

Ключові принципи

• Bounded Context – кожен сервіс має власну доменну модель.
• Loose Coupling – мінімальна залежність між сервісами, зазвичай через HTTP/JSON або повідомлення.
• Single Responsibility – один сервіс відповідає за одну функціональність.

Як це працює

1. Клієнт надсилає запит до API Gateway.
2. Gateway маршрутизує запит до відповідного мікросервісу.
3. Сервіс обробляє логіку, взаємодіє з власною БД і повертає результат.
4. Для асинхронних процесів часто використовується брокер повідомлень (RabbitMQ, Kafka).

Практика і реалізація

• Node.js/Express або NestJS для створення мікросервісу.
• Docker + docker‑compose для локального розгортання.
• CI/CD (GitHub Actions, GitLab CI) для автоматичного деплою в Kubernetes.

Тестування

• Unit‑тести з Jest/ Vitest.
• Integration‑тести, що спілкуються через реальний HTTP сервер (supertest).
• End‑to‑end тестування з Playwright, що перевіряє взаємодію між сервісами.

Безпека

• Аутентифікація через OAuth2 / JWT.
• Rate limiting, CORS, input validation.

Масштабування

• Автоматичне масштабування в Kubernetes (Horizontal Pod Autoscaler).
• Кешування через Redis або CDN.

Проблеми та edge‑cases

• Складність моніторингу: потрібен централізований лог (ELK, Loki).
• Схема даних: розподілена транзакція → eventual consistency.
• Затримки мережі: використання circuit breaker (Hystrix, Resilience4j).

Часті помилки

1. Надмірна кількість мікросервісів → складність управління.
2. Відсутність централізованої конфігурації → дублювання налаштувань.
3. Неправильне використання shared database → порушення принципу single responsibility.
4. Недостатня документація API → труднощі інтеграції.
5. Відсутність тестів для межових сценаріїв → непередбачувані помилки.
6. Перевантаження мережі через синхронні виклики → використання async patterns.
7. Неправильна обробка помилок → падіння всього сервісу.
8. Відсутність логування → складно відстежувати проблеми в продакшн‑середовищі.