3.4. Пример микросервисной архитектуры

Представим интернет-магазин:

• API Gateway — единая точка входа для клиентов. Маршрутизирует запросы к нужным сервисам, может заниматься аутентификацией, балансировкой.

• User Service — управляет пользователями (регистрация, профили).

• Order Service — управляет заказами.

• Payment Service — обрабатывает платежи.

• Email Service — отправляет уведомления (подписывается на события из Kafka).

3.5. Преимущества микросервисов

• Масштабируемость — можно масштабировать только нужные сервисы (например, Order Service под высокой нагрузкой Чёрной пятницы, а User Service — нет).

• Гибкость технологий — разные сервисы могут использовать разные языки и БД.

• Устойчивость к ошибкам — сбой в одном сервисе не ломает всё приложение.

• Лёгкость развёртывания — можно обновлять сервисы независимо.

• Упрощение разработки — маленькие команды могут работать над отдельными сервисами параллельно.

3.6. Недостатки и сложности микросервисов

• Сложность распределённых систем — нужно решать проблемы сетевых задержек, частичных сбоев, согласованности данных.

• Трудности с транзакциями — ACID-транзакции между сервисами невозможны, нужны компенсирующие транзакции (Saga).

• Сложность отладки и мониторинга — запрос может проходить через много сервисов, трудно отследить путь.

• Управление конфигурациями — нужно синхронизировать конфиги многих сервисов.

• Нагрузка на сеть — больше взаимодействий между сервисами.

3.7. Когда выбирать микросервисы?

Микросервисы подходят, если:

• Приложение большое и сложное, над ним работают несколько команд.

• Требуется высокая масштабируемость и отказоустойчивость.

• Разные части приложения имеют разные требования к технологиям.

• Частота изменений в разных частях приложения разная.

Микросервисы НЕ нужны, если:

• Приложение маленькое или среднее.

• У вас небольшая команда (до 10 человек).

• Требования к масштабированию невысоки.

• Проект находится на ранней стадии (MVP). Лучше начать с монолита и декомпозировать его позже.

Часть 4. Связь между концепциями

Эти три концепции не исключают, а дополняют друг друга:

• Клиент-сервер — фундамент, на котором всё строится.

• REST — популярный способ организации взаимодействия между клиентом и сервером (или между микросервисами).

• Микросервисы — способ организации серверной части, где каждый микросервис сам является сервером для других сервисов и клиентов (через API Gateway), и они часто общаются по REST.

Таким образом, RESTful API — это "клей", соединяющий микросервисы и клиентов в клиент-серверной архитектуре.

5. Заключение

Ключевые выводы:

1. Клиент-серверная архитектура разделяет систему на поставщиков услуг (серверы) и их потребителей (клиенты). Это основа сетевого взаимодействия.

2. REST — архитектурный стиль для построения API, использующий принципы: отсутствие состояния, единообразие интерфейса, кэширование, слои. Основан на ресурсах и методах HTTP.

3. Микросервисы — подход к разработке, при котором приложение состоит из множества небольших независимых сервисов. Даёт гибкость, масштабируемость, но добавляет сложность.

4. Эти концепции часто используются вместе: микросервисы общаются через REST API, а клиенты обращаются к ним через API Gateway (клиент-сервер).