Сервисная архитектура: сводка по SOA и микросервисам

Сводка

SOA подходит, когда в приоритете интеграция большого корпоративного ландшафта и централизованный контроль.
Микросервисы подходят, когда в приоритете скорость изменений продукта, автономия команд и независимые релизы.
Ключевое отличие не в “модности”, а в операционной модели: governance, ownership данных, деплой и наблюдаемость.
Для большинства команд сначала важнее навести порядок в доменной модели и CI/CD, чем дробить монолит.
Гибридный сценарий практичен: SOA на уровне межсистемных интеграций, микросервисы внутри продуктового контура.

Зачем эта страница

Для сервисных продуктов выбор архитектуры напрямую влияет на скорость поставки, стоимость изменений и риски эксплуатации. Эта страница даёт практичный способ выбрать между SOA и микросервисами без догм.

Кратко: в чем разница

Критерий	SOA	Микросервисы
Основная цель	Интеграция корпоративных систем и reuse сервисов	Быстрые независимые релизы внутри продукта
Размер сервиса	Крупнее, вокруг бизнес-возможностей	Меньше, вокруг ограниченного контекста
Коммуникация	Часто через централизованную шину (ESB)	Чаще REST/gRPC + события через брокер
Governance	Централизованный	Децентрализованный по командам
Данные	Нередко общие модели/ресурсы	Каждый сервис владеет своими данными

Когда выбирать SOA

Нужно связать много разнородных enterprise-систем (ERP, CRM, биллинг, legacy).
Важнее единые корпоративные регламенты и централизованный контроль, чем скорость локальных релизов.
Команда уже инвестировала в ESB, каталог сервисов и платформенный governance.

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

Продукт развивается быстро, релизы идут часто и по независимым потокам.
Есть зрелый DevOps: CI/CD, observability, контрактное тестирование, алертинг.
Нужна автономия команд и независимое масштабирование отдельных доменных зон.

Где чаще ошибаются

Называют систему микросервисной, но держат общую БД и общий релизный цикл.
Уходят в микросервисы без platform-инженерии, получая рост операционной сложности.
Строят избыточный ESB-слой для продукта, где достаточно API Gateway + event-driven интеграций.

Минимальный архитектурный baseline

Для SOA

Формальные сервисные контракты и версионирование.
Каталог сервисов и единые правила интеграции.
Централизованная политика безопасности и аудита.

Для микросервисов

Четкие bounded contexts и отдельная ответственность за данные.
Наблюдаемость по умолчанию: логи, метрики, трассировка.
Автоматизированные релизы и rollback-стратегия на уровне каждого сервиса.

Пример контракта между сервисами (PHP/Laravel)

<?php

namespace App\Http\Controllers;

use Illuminate\Http\JsonResponse;
use Illuminate\Http\Request;

final class BillingWebhookController
{
    // Контракт фиксирует обязательные поля события между сервисами.
    public function __invoke(Request $request): JsonResponse
    {
        $payload = $request->validate([
            'event_id' => ['required', 'string'],
            'event_type' => ['required', 'in:invoice.paid,invoice.failed'],
            'occurred_at' => ['required', 'date'],
            'customer_id' => ['required', 'string'],
            'invoice_id' => ['required', 'string'],
        ]);

        // Здесь можно вызвать application-service и записать event в inbox/outbox.
        return response()->json(['accepted' => true, 'event_id' => $payload['event_id']]);
    }
}

Этот пример полезен и для SOA, и для микросервисов: контракт валидируется на входе, а не «по договоренности в чате».

Пример события для асинхронной интеграции (JavaScript)

const invoicePaidEvent = {
  eventId: "evt_2026_07_25_001",
  eventType: "invoice.paid",
  occurredAt: new Date().toISOString(),
  customerId: "cust_42",
  invoiceId: "inv_1001",
  amount: { value: 14900, currency: "RUB" },
};

// Публикация в брокер (Kafka/RabbitMQ/NATS) делается в инфраструктурном адаптере.
publish("billing.events", invoicePaidEvent);

Практическая эвристика выбора

Если ключевая задача - enterprise-интеграция большого ландшафта систем, стартуйте с SOA.
Если ключевая задача - скорость вывода продуктовых изменений и автономия команд, берите микросервисы.
Гибрид возможен: SOA на уровне корпоративных интеграций и микросервисы внутри продуктового контура.