Сервис-ориентированная архитектура (SOA) и микросервисная архитектура – два популярных подхода к разработке программного обеспечения. Хотя оба разделяют приложение на отдельные сервисы, между ними существуют фундаментальные различия, определяющие их применимость в различных ситуациях.
Сервис-ориентированная архитектура (SOA)
В основе SOA лежат повторное использование сервисов и корпоративная шина (ESB). Система разбивается на сервисы, используемые повторно в разных частях приложения. Взаимодействие и маршрутизация осуществляются через ESB.
Типичная SOA-архитектура включает:
- Шина (ESB): Посредник при взаимодействии, управляет передачей сообщений и координацией вызовов.
- Инфраструктурные сервисы: Группа часто используемых сервисов (аутентификация, авторизация, отправка SMS и т.д.).
- Прикладные сервисы: Ограничены определенным контекстом, но могут быть встроены в более высокоуровневые сервисы.
- Сервисы предприятия: Реализуют крупные части бизнес-процессов компании, потребляя более низкоуровневые сервисы. Они являются бэкендом, предоставляющим API для сайтов и мобильных приложений.
Проектирование в стиле SOA характеризуется многослойностью, что приводит к сложной распределённой архитектуре, напоминающей монолитную систему, но с значительно большей сложностью. Любой запрос проходит через множество систем.
Микросервисная архитектура
В отличие от SOA, микросервисная архитектура избегает повторного использования, предпочитая независимость сервисов. Система разбивается на сервисы с ограниченным контекстом, отражающим конкретные бизнес-области.
Ключевые особенности микросервисной архитектуры:
- Каждый сервис обладает всеми необходимыми для функционирования компонентами (включая собственную базу данных).
- Каждый сервис – независимый процесс.
- Сервисы физически разделены и самодостаточны (архитектура без разделения ресурсов).
- Взаимодействие между сервисами осуществляется обменом данными через брокер сообщений, без сложной логики (фактически – просто проксирование API).
Микросервисная архитектура характеризуется небольшим количеством слоёв, но большим количеством сервисов и команд, которые ими владеют. Основная сложность – правильное определение ограниченного контекста и разделение сервисов между командами.
Сравнение SOA и микросервисной архитектуры
| Характеристика | SOA | Микросервисная архитектура |
|---|---|---|
| Внесение изменений | Сложно, требует согласований между командами. | Просто, осуществляется командой, владеющей сервисом. |
| Повторное использование | Стремится к повторному использованию, но часто приводит к сложностям. | Предпочтительно дублирование. |
| Команды и поддержка | Команды разделены, сложная координация. | Команды кросс-функциональны, владеют процессом от начала до конца. |
| Взаимодействие | Через корпоративную шину (ESB), может стать узким местом. | Обмен данными через брокер сообщений. |
| Автоматизация и развертывание | Сложно. | Просто, каждый сервис развертывается независимо. |
| Тестирование | Затруднено из-за множества взаимосвязей. | Просто, каждый сервис тестируется изолированно. |
| Масштабируемость | Менее масштабируема | Высоко масштабируема |
Выбор между SOA и микросервисной архитектурой зависит от контекста проекта. SOA была оптимальным решением 10 лет назад, в эпоху дорогих серверов и коммерческих лицензий, где повторное использование ресурсов было критично. Сейчас, с открытым исходным кодом, DevOps и системами непрерывной интеграции и доставки, микросервисная архитектура часто предпочтительнее благодаря своей гибкости и масштабируемости. Различие между подходами – скорее концептуальное, чем техническое. Стремление к повторному использованию и множеству зависимостей между сервисами, даже при отсутствии ESB, указывает на архитектуру, отличную от микросервисной. Микросервисы ориентированы на выполнение одной бизнес-задачи, а SOA – на выполнение множества задач, что сказывается на хранении данных (независимое хранилище в микросервисах против совместного в SOA).