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

Поэтому каждый понимает под SOA что-то свое, а мы попробуем объяснить, что такое сервис-ориентированная архитектура в нашем понимании: SOA — это подход к разработке ПО, основанный на архитектурных принципах, с применением стандартизированных интерфейсов.

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

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

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

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

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

Поговорим о преимуществах SOA:

• Автономность. Сервисы, разработанные на основе SOA, не зависят друг от друга, поэтому могут использоваться несколькими приложениями одновременно.

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

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

• Одинаковая структура каталогов. SOA поддерживает применение «шаблонов», которые помогают выстраивать каталоги под единому принципу.

• Переиспользование сервисов. SOA дает возможность повторно применить сервис существующей системы для новых проектов.

 Но у SOA есть и недостатки:

• Сложное управление. Каждый сервис SOA должен без задержек доставлять сообщения, но их количество может быть больше нескольких миллионов, а это затрудняет управление всеми службами.

• Большая нагрузка. В SOA служба проверяет сообщение на соответствие заявленному заранее контракту. В случае, если применяется несколько сервисов, это может привести к увеличению время отклика и снижению общей производительности.

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

• Высокие инвестиционные затраты. Использование SOA требует большого количества инвестиций: организационных, экономических, технических и психологических.

Отличия SOA от MSA (микросервисной архитектуры)

Отличия заключаются в технических особенностях и реализации этих подходов. Так, например, использование сервис-ориентированной архитектуры невозможно без ESB, централизации и наличия крупных сервисов. Система, спроектированная с помощью SOA, многослойна и по принципу работы напоминает монолитную архитектуру. Но сервис-ориентированная архитектура намного сложнее монолитной за счет глубоких связей и относительной децентрализованности.

В свою очередь, MSA — это подход, при котором система разрабатывается на основе небольших самостоятельных серверов. В отличие от SOA, микросервисы избегают повторное использование и предпочитают дублирование. Повторное использование серверов предполагает связанность между ними, а микросервисная архитектура — это максимальная децентрализованность и возможность распределить нагрузку между компонентами. Другими словами, микросервисная архитектура помогает разбить сервисы по бизнес-отраслям. Каждый сервис имеет все необходимые для самостоятельного функционирования элементы и существует как независимый процесс. Использовать MSA лучше в проектах с большим коллективом разработчиков, объемной и сложной архитектурой, продуктами, с резко меняющимся трафиком, приложениями, которые требуют частых обновлений. Хотите узнать больше о “плюсах” и “минусах” MSA? Читайте статью “Зачем бизнесу нужны микросервисы” в нашем блоге.

Вывод

За последние 10 лет SOA эволюционировала и стала заменой устаревшим решениям. Особой популярностью сервис-ориентированная архитектура пользуется у владельцев больших и сложных корпоративных систем, в частности банков. Благодаря SOA разработчикам больше не нужно создавать новую интеграцию под каждый проект. Теперь решения создаются на основе «шаблонов», которые позволяют тратить меньше времени и других ресурсов. Вместе с SOA компания может быстрее реагировать на потребности бизнеса и быть на шаг впереди конкурентов.

Помните, что сервис-ориентированная архитектура — это не «панацея», а обобщение практик  по разработке ПО. Поэтому, ориентируйтесь на свои задачи и потребности, используйте SOA только тогда, когда это необходимо.

Если вы хотите глубже изучить микро-сервисную архитектуру, присоединяйтесь к нашим курсам!