Лекція 175: Організація мікросервісних проєктів: підходи до розбиття модулів

У цій лекції розберемося з організацією мікросервісних проєктів. Бо знання того, як написати код, — це лише частина роботи. Якщо мікросервіси неправильно організовані, додаток перетвориться на заплутану й некеровану систему — ніби серіал, де сюжетні лінії суперечать одна одній, а персонажі діють нелогічно. Тож давайте поглянемо, як грамотно структурувати проєкти під мікросервісну архітектуру.

Уявіть, що ви будуєте багатоповерховий будинок, де кожну кімнату займає окремий мікросервіс. Все класно, поки ви не вирішите, що кухня має бути на даху, а ванна — у підвалі. Так, ніхто не забороняє так робити, але це явно незручно.

Подібні проблеми бувають і в програмуванні. Якщо ваші мікросервіси погано структуровані:

• Проєкти стають складними для супроводу. Розробники плутаються, який сервіс за що відповідає.
• Деплой перетворюється на кошмар. Будь-які зміни вимагають перекомпіляції великого коду або переналаштування всього застосунку.
• Команди не можуть ефективно працювати. Автономія сервісів губиться, коли один мікросервіс залежить від купи інших.

Отже, хороша архітектура — це не просто красиво, це необхідність.

Принципи декомпозиції мікросервісів

1. Розподіл відповідальностей (Separation of Concerns)

Кожен мікросервіс має відповідати тільки за одну функціональну область. Це ідеологія «роби одне, але роби це добре». Наприклад:

• Сервіс користувачів (User Service) — відповідає за реєстрацію, авторизацію та збереження профілів.
• Сервіс замовлень (Order Service) — керує процесом створення та обробки замовлень.
• Сервіс платежів (Payment Service) — обробляє оплату та керує транзакціями.

Питаєте, як зрозуміти, «де зупинитися»? Тут допоможе підхід «доменного проектування» (Domain-Driven Design, DDD), який підказує, як ідентифікувати великі функціональні області вашого застосунку.

2. Незалежність сервісів

Мікросервіси мають бути максимально незалежними. Це означає:

• Кожен сервіс володіє своїми даними. Ніколи, кажу, НІКОЛИ не підключайтеся до бази даних іншого сервісу напряму.
• Мінімізуйте міжсервісні виклики. Якщо ваш сервіс «залежить» від інших, одна помилка в одному місці може потягнути за собою всю систему.

3. Ізоляція за бізнес-областями

Сервіси потрібно розділяти, виходячи з того, які бізнес-проблеми вони вирішують. Наприклад:

• Якщо ви робите інтернет-магазин, можна виділити сервіси для користувачів, продуктів, замовлень і оплати.
• Якщо ви розробляєте CRM-систему, виділіть сервіси для управління клієнтами, угодами та маркетинговими кампаніями.

Структура мікросервісного проєкту

Тепер розберемося, як структурувати кодову базу. Ось приклад структури:

ecommerce/                                     # Коренева папка проєкту
├── user-service/                              # Мікросервіс користувачів
│   ├── src/                                   # Вихідний код
│   │   ├── main/
│   │   │   ├── java/com/example/user/         # Пакети
│   │   │   │   ├── controller/
│   │   │   │   ├── service/
│   │   │   │   ├── repository/
│   │   │   │   ├── model/
│   │   │   │   └── resources/                  # Конфігураційні файли
│   │   └── test/
│   └── Dockerfile                             # Інструкція для контейнера
├── order-service/                             # Мікросервіс замовлень
│   ├── src/
│   └── Dockerfile
├── payment-service/                           # Мікросервіс для платежів
│   ├── src/
│   └── Dockerfile
└── config/                                    # Централізовані конфігурації
    ├── docker-compose.yml                     # Конфігурація для запуску
    └── eureka-config.yml                      # Конфігурація Service Discovery

Хороша структура пакетів всередині кожного мікросервісу дозволяє легко знаходити код:

• controller/ — тут розміщуються всі контролери (наприклад, REST API).
• service/ — тут знаходиться бізнес-логіка.
• repository/ — доступ до бази даних.
• model/ — опис сутностей, наприклад, User, Order.

Практика: розділяємо додатки на мікросервіси

Припустимо, ми розробляємо інтернет-магазин. У нас є три великі області:

1. Користувачі: реєстрація та авторизація.
2. Продукти: управління каталогом товарів.
3. Замовлення: створення замовлень та керування ними.

Створимо три мікросервіси: UserService, ProductService, OrderService.

1. Спочатку створюємо новий проєкт через Spring Initializr (user-service):
   • Додаємо залежності: Spring Web, Spring Data JPA, Spring Boot DevTools, H2 Database.
2. Структуруємо пакети:

   
   com.example.user
   ├── controller/
   ├── service/
   ├── repository/
   ├── model/
   

3. Створюємо просту сутність:

   
   @Entity
   public class User {
   
       @Id
       @GeneratedValue(strategy = GenerationType.IDENTITY)
       private Long id;
   
       private String name;
       private String email;
   
       // Гетери та сетери
   }
   

4. Додаємо контролер:

   
   @RestController
   @RequestMapping("/users")
   public class UserController {
   
       @GetMapping
       public String getAllUsers() {
           return "Список користувачів!";
       }
   }
   

Створення ProductService і OrderService

Процес аналогічний, але ми використовуємо свої доменні моделі (Product, Order) для кожного сервісу.

Як керувати залежностями між сервісами

Іноді сервіси повинні взаємодіяти один з одним. Наприклад, сервіс замовлень (OrderService) може опитувати сервіс продуктів (ProductService), щоб перевірити доступність товару.

Підходи:

• REST API. Один сервіс робить запит до іншого через HTTP.
• Асинхронний обмін даними. Використовуйте брокери повідомлень, такі як Kafka, якщо хочете розірвати пряму зв'язок між сервісами.

Корисні поради й типові помилки

1. Не намагайтеся зробити ідеальну архітектуру з першого разу. Розбиття системи на мікросервіси може бути ітеративним процесом.
2. Не тримайте занадто багато логіки в одному мікросервісі. Якщо код починає розростатися і ставати складним, це сигнал, що потрібно виділити новий сервіс.
3. Тестуйте мікросервіси окремо. Переконайтеся, що кожен сервіс повністю працює сам по собі.

Ми тільки починаємо розбирати архітектуру мікросервісів. Важливо пам'ятати, що вони — не самоціль, а зручний інструмент, який має допомагати вирішувати бізнес-завдання.