Лекція 161: Що таке мікросервісна архітектура і навіщо вона потрібна

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

Так само й з мікросервісами. Замість одного великого додатка (моноліту), ми розбиваємо його на багато невеликих сервісів, кожен з яких виконує одну конкретну задачу.

В основі цього підходу лежать два головні принципи:

1. Розподіл обов'язків: кожен сервіс, як окрема компанія, відповідає тільки за свою частину роботи.
2. Повна автономність: будь-який сервіс можна оновити або змінити, не заважаючи роботі інших — як ремонт в одному офісі не впливає на роботу сусідів.

Еволюція: від моноліту до мікросервісів

Колись усі любили моноліти. Це був золотий стандарт для корпоративних додатків. Один великий проєкт, одна кодова база і одне розгортання. Але, як і будь-який інший тренд, моноліти не позбавлені недоліків:

• Складність масштабування: система вимагає масштабування всього додатка навіть при навантаженні на одну його частину.
• Ризик відмов: баг або збій в одному компоненті може вивести з ладу всю систему.
• Повільні оновлення: будь-яка зміна вимагає перескладання всього додатка.

Мікросервіси стали логічною відповіддю на ці проблеми. Вони дозволили розробникам не лише масштабувати критично важливі компоненти, а й скоротити час розгортання змін.

Навіщо потрібні мікросервіси?

1. Швидкість і гнучкість розробки. З мікросервісами команди можуть працювати паралельно над різними компонентами. Наприклад, команда A розробляє мікросервіс для обробки платежів, а команда B — для управління користувачами. Вони незалежні одна від одної, що скорочує час розробки.
2. Масштабованість. Якщо конкретний сервіс (наприклад, обробка замовлень) стикається з великою навантаженням, ми можемо масштабувати тільки його, залишивши інші частини системи неушкодженими. Це економить ресурси.
3. Стійкість до збоїв. Коли один сервіс виходить з ладу, решта продовжує працювати. Наприклад, якщо сервіс рекомендацій недоступний, сайт може продовжити приймати замовлення.
4. Технологічна незалежність. Кожен мікросервіс може бути написаний на своїй мові програмування і використовувати свій стек технологій. Наприклад, REST API можна писати на Spring Boot, а обробку великих даних — на Python.

Як працюють мікросервіси?

Основні елементи мікросервісної архітектури:

Приклади з реального світу

1. Netflix — яскравий приклад використання мікросервісів. Кожна частина системи, від рекомендацій до обробки потоків відео, побудована як окремий сервіс. Це дозволяє масштабувати саме ті частини, які активно використовуються користувачами.
2. Uber — керує мільйонами запитів на поїздки і доставку їжі. Їхня архітектура дотримується принципів мікросервісів, розділяючи такі функції, як обробка водіїв, маршрутів і платежів, на незалежні компоненти.

Міфи, пов'язані з мікросервісами

• "Мікросервіси — це завжди краще". Насправді вони підходять не для всіх проєктів. Якщо ваша система досить мала, мікросервіси можуть ускладнити її розробку.
• "Можна просто взяти і перейти на мікросервіси". Це не так. Перехід вимагає ретельного планування і зміни архітектури системи.

Реалізація мікросервісів у Spring Boot

Напевно ви задаєтесь питанням: "Як же зв'язати Spring Boot і мікросервіси?" Spring Boot — ідеальний інструмент для створення мікросервісів. Його можливості включають:

• Інтеграцію зі Spring Cloud для таких задач, як конфігурації, Service Discovery і API Gateway.
• Підтримку Kafka та інших систем повідомлень для асинхронної взаємодії.
• Просте управління конфігурацією через application.yml.

Давайте наведемо приклад і почнемо кодити. Уявімо, що в нас є мінімалістична мікросервісна система: UserService і OrderService. Ми будемо використовувати Spring Boot для їх реалізації.

UserService

@RestController
@RequestMapping("/users")
public class UserController {

    @GetMapping("/{id}")
    public String getUser(@PathVariable Long id) {
        // Повертаємо інформацію про користувача
        return "Користувач з ID: " + id;
    }
}

OrderService

@RestController
@RequestMapping("/orders")
public class OrderController {

    @GetMapping("/{id}")
    public String getOrder(@PathVariable Long id) {
        // Повертаємо інформацію про замовлення
        return "Замовлення з ID: " + id;
    }
}

API Gateway (Spring Cloud Gateway — базова налаштування)

spring:
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: http://localhost:8081
          predicates:
            - Path=/users/**
        - id: order-service
          uri: http://localhost:8082
          predicates:
            - Path=/orders/**

Тепер у нас є базова структура: UserService, OrderService і API Gateway, який маршрутизує запити. Наприклад:

• Запит http://localhost:8080/users/1 надійде в UserService.
• Запит http://localhost:8080/orders/1 надійде в OrderService.

Як масштабувати мікросервіси?

Припустимо, OrderService відчуває велике навантаження. Ми можемо просто запустити ще кілька його екземплярів. Інструменти на кшталт Kubernetes допоможуть розподілити навантаження між ними.

Висновок

Мікросервіси — це потужний інструмент для сучасних додатків, але вони не є панацеєю. Вони додають гнучкість, масштабованість і відмовостійкість, але також збільшують складність системи. На наступних лекціях ви дізнаєтесь більше про патерни, такі як Service Discovery і API Gateway, які допоможуть вам проектувати мікросервісні системи на практиці.