SOA: что такое сервис-ориентированная архитектура, её плюсы и минусы

Почему SOA до сих пор актуальна

В IT-ландшафте крупной компании легко насчитать десятки систем: учётные, CRM, биллинг, склад, мобильные приложения, аналитика. Если связывать их напрямую, каждая новая система тянет за собой интеграции со всеми существующими. Уже при десяти системах количество возможных связей приближается к полусотне, и любое изменение в одной из них рискует уронить соседние.

Сервис-ориентированная архитектура появилась в начале 2000-х как ответ именно на эту проблему. Вместо клубка прямых связей она предлагает собрать функциональность в сервисы с понятными интерфейсами и общаться через стандартные протоколы.

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

Что такое SOA

Сервис-ориентированная архитектура (Service-Oriented Architecture, SOA) — это подход к проектированию программных систем, при котором приложение собирается из независимых сервисов. В русскоязычных текстах встречается написание «СОА».

Что это значит на практике: каждый сервис реализует отдельную бизнес-функцию, доступен по стандартному протоколу и ничего не знает о внутреннем устройстве соседей. В обиходе подход называют короче — сервисная архитектура; это то же понятие.

Ключевое слово здесь — «владельцы». SOA изначально проектировали для мира, где сервисы принадлежат разным командам, департаментам и даже компаниям. Отсюда упор на контракты, стандартизацию и интеграционный слой, который отличает сервисную архитектуру от простого набора приложений с API.

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

Основные понятия SOA

Прежде чем разбирать принципы работы, нужно договориться о терминах. В сервис-ориентированной архитектуре их шесть.

Сервис — автономный программный компонент, который выполняет конкретную бизнес-функцию: проверяет остаток на счёте, рассчитывает стоимость доставки, отправляет уведомление и т. д. Сервис можно вызвать, не зная, как он устроен внутри.

Интерфейс — точка доступа к сервису. Она скрывает реализацию: потребителю не важно, на каком языке написан сервис и какая база данных за ним стоит.

Контракт — формальное описание интерфейса: какие операции доступны, что сервис принимает на вход, что возвращает и какие гарантии даёт. Для REST API контракт обычно описывают по стандарту OpenAPI, для SOAP-сервисом — в формате WSDL.

Сообщение — единица обмена данными между сервисами. В классической SOA сообщения передавали в XML, сегодня чаще используют JSON или бинарные форматы вроде Protocol Buffers в gRPC.

API (Application Programming Interface) — программный интерфейс, через который сервисы обмениваются запросами. В SOA API сервиса — публичная часть его контракта.

Интеграционный слой — инфраструктура, которая связывает сервисы между собой: маршрутизирует запросы, преобразует форматы, балансирует нагрузку. В классических SOA-системах эту роль играла сервисная шина предприятия (ESB), в современных — API-шлюзы и брокеры сообщений.

Принципы работы сервис-ориентированной архитектуры

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

Слабая связанность — главный из них. Сервисы зависят только от контрактов друг друга, поэтому команду одного сервиса не блокируют релизы другого. С ней связана автономность: сервис сам управляет своей логикой и данными.

Дальше — переиспользуемость: одна и та же проверка платёжных реквизитов работает и в мобильном приложении, и в личном кабинете, и во внутренней CRM.

Наконец, обнаруживаемость: сервисы регистрируются в общем каталоге, где их можно найти вместе с контрактами, а не выяснять устройство системы по переписке.

На практике обмен между сервисами устроен двумя способами.

Синхронный — потребитель отправляет запрос и ждёт ответа. Так работают запросы через REST API или gRPC — например, страница заказа запрашивает у сервиса цен актуальную стоимость. Единой точкой входа для таких вызовов служит API-шлюз. В Yandex Cloud эту роль выполняет Yandex API Gateway: шлюз описывается декларативной спецификацией по стандарту OpenAPI 3.0, умеет проверять авторизацию по JWT, ограничивать частоту запросов и раскатывать «канареечные» релизы API.

Асинхронный — отправитель кладёт сообщение в очередь и продолжает работу, а получатель забирает его, когда готов. Такой сценарий выручает при пиковых нагрузках и долгих операциях: заказ принят мгновенно, а сборка, оплата и уведомления обрабатываются в своём темпе. Для этого используют очереди сообщений, например Yandex Message Queue. Тип очереди выбирают под задачу: стандартные дают максимальную пропускную способность с доставкой «как минимум один раз», а FIFO гарантируют строгий порядок и однократную обработку.

Схема SOA

Типовая схема SOA-системы выглядит как путь запроса через несколько слоёв.

Клиент (браузер, мобильное приложение или внешняя система) обращается к платформе. Балансировщик нагрузки распределяет входящий трафик, API-шлюз проверяет права и направляет запрос нужному сервису.

Дальше сервисы выполняют бизнес-логику: часть операций проходит синхронно, а долгие задачи уходят в очередь сообщений, откуда их разбирают обработчики.

Результаты сохраняются в базах данных и хранилищах. Поверх всей цепочки работает мониторинг: он собирает метрики и логи каждого звена, иначе найти причину сбоя в распределённой системе почти невозможно.

Компоненты SOA-системы

За схемой стоят конкретные компоненты SOA. Исторически центральным была сервисная шина предприятия (Enterprise Service Bus, ESB) — посредник, который маршрутизирует сообщения, преобразует форматы и связывает несовместимые системы. Рядом с шиной работали реестр сервисов — каталог с контрактами и адресами, и оркестратор — механизм, который собирает из отдельных сервисов сквозные бизнес-процессы.

Сегодня тяжёлую ESB всё чаще заменяет связка более простых инструментов: API-шлюз берёт на себя маршрутизацию и безопасность синхронных вызовов, брокер сообщений — асинхронный обмен, а описания API в едином репозитории играют роль реестра. Логика при этом смещается из шины в сами сервисы: интеграционный слой остаётся тонким и предсказуемым.

Преимущества и недостатки SOA-архитектуры

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

Хорошая новость в том, что большую часть недостатков SOA сегодня исправляют готовыми инструментами. Управление API и защиту точек входа централизует API-шлюз, за метрики и алерты распределённой системы отвечает система наблюдаемости — например, Yandex Monium, а доступ к облачным ресурсам разграничивает Yandex Identity and Access Management. Сложность не исчезает, но перестаёт быть ручной работой.

Чем SOA отличается от микросервисной архитектуры

Микросервисная архитектура (MSA) выросла из SOA: архитектура микросервисов доводит её принципы до предела, поэтому сервисы становятся меньше, автономнее и избавляются от общей шины. Мартин Фаулер, один из авторов канонического описания микросервисов, прямо называет их вариантом сервис-ориентированного подхода. Поэтому корректнее говорить не о SOA против микросервисов, а о двух поколениях одной идеи.

Основные отличия SOA от MSA удобно свести в таблицу:

Разница видна и в инфраструктуре. Микросервисы почти всегда живут в контейнерах под управлением оркестратора. Разворачивать и сопровождать такой кластер удобнее в управляемом сервисе — например, Yandex Managed Service for Kubernetes^® берёт на себя работу мастера и следит за состоянием групп узлов, оставляя команде только сами приложения. Подробно о том, кому подходит микросервисный подход, мы рассказывали в статье микросервисной архитектуре.

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

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

Микросервисная архитектура уместнее для нового продукта, который строится с нуля и должен быстро развиваться силами независимых команд. В англоязычных материалах эту дилемму называют «SOA vs microservices», но на практике подходы сочетают: корпоративный интеграционный контур живёт по правилам SOA, а внутри отдельных продуктов работают микросервисы.

SOA для бизнеса

Для бизнеса сервис-ориентированная архитектура — способ сократить стоимость изменений. Когда функциональность оформлена в сервисы, новый канал продаж или партнёрская интеграция собираются из готовых блоков, а не пишутся заново. Отдельный плюс — прозрачность: у каждого сервиса есть владелец, контракт и метрики, поэтому проще считать стоимость и планировать развитие.

Референсная SOA-система на Yandex Cloud выглядит так. Внешний трафик принимает Yandex Application Load Balancer, запросы к API проходят через API-шлюз с проверкой прав, сервисы работают в кластере Kubernetes, асинхронные задачи идут через очередь сообщений, данные лежат в управляемых базах, а метрики и логи всех компонентов собирает единая система наблюдаемости. Каждый элемент этой цепочки — управляемый сервис: инфраструктурную рутину забирает платформа, команда занимается бизнес-логикой.

Внедрение сервис-ориентированной архитектуры в корпоративную среду

Проектирование SOA начинается не с бизнес-процессов. Типовой путь внедрения выглядит так.

1. Аудит ландшафта. Составьте карту систем, их связей и дублирующейся функциональности: дубли — первые кандидаты на выделение в общие сервисы.
2. Выделение сервисов и контрактов. Разбейте процессы на бизнес-функции и опишите для каждой контракт: операции, форматы данных, требования к доступности.
3. Выбор интеграционного слоя. Решите, что будет связывать сервисы: API-шлюз, брокер сообщений, шина или их комбинация. Здесь же определите стандарты: протоколы, форматы, правила версионирования.
4. Пилотный проект. Начните с одного процесса со зримым эффектом, например с единого сервиса клиентских данных. Пилот проверит и технологии, и готовность команд.
5. Управление SOA. Заведите реестр сервисов, назначьте владельцев, договоритесь о жизненном цикле версий и контроле качества API. Без этого слоя управления система быстро вернётся к хаосу интеграций.

Главные ошибки внедрения тоже известны. Слишком крупные сервисы возвращают монолит под новым названием, слишком мелкие — топят команду в накладных расходах. Вторая по частоте проблема — сервисы без владельцев: контракт, за который никто не отвечает, устаревает за квартал.

SOA в примерах

Разобраться, что такое SОА на практике, проще всего на примерах отраслей.

Классический пример SOA-системы — банк. Автоматизированная банковская система, процессинг карт, кредитный конвейер и мобильное приложение работают как отдельные сервисы. Особенности SOA здесь видны сразу: когда банк запускает новый продукт, скажем, вклад с онлайн-открытием, он переиспользует готовые сервисы проверки клиента и проведения платежей, а не дублирует их.

В ритейле сервисный подход связывает интернет-магазин, кассы, склад и программу лояльности. Остаток товара считается в одном сервисе, и все каналы продаж видят одну и ту же цифру. Заказы при пиковых распродажах уходят в очередь и обрабатываются по мере готовности склада: сайт при этом отвечает быстро.

Похожим образом SOA работает в телекоме и на производстве: биллинг, CRM и техподдержка обмениваются событиями через интеграционный слой, а новые партнёрские сервисы подключаются через публичные API, не требуя доработки ядра.

Частые вопросы про SOA

Что в итоге

Сервис-ориентированная архитектура остаётся рабочим инструментом для компаний со сложным IT-ландшафтом: она превращает клубок интеграций в управляемый набор сервисов с контрактами и владельцами. Платить за это приходится дисциплиной — управлением API, версионированием и мониторингом, но именно эти задачи сегодня закрывают управляемые облачные сервисы. А спор «SOA или микросервисы» на практике решается союзом: принципы у подходов общие, и зрелые команды используют оба — каждый там, где он уместен.