Зачем нужна сервис-ориентированная архитектура

Зачем нужна сервис-ориентированная архитектура

Как разбить приложение на модули.

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

Cервис-ориентированная архитектура (SOA, service-oriented architecture) помогает достичь баланса между стоимостью и скоростью. SOA базируется на разделении приложения на слабо связанные компоненты (сервисы).

Объясняем, как разбиение логики на модули упрощает разработку.

Сервисы как отдельные части

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

  • авторизации пользователей;
  • логирования;
  • оповещений.

Крупные задачи разделяются между модулями. Для описания содержимого и функций сервиса нет строгих правил. Команда сама определяет, что нужно сервису. При этом сами сервисы следуют контрактам (четким правилам):

  • что именно может подключиться к сервису;
  • по какому протоколу и через какой интерфейс идет передача данных;
  • с какими данными работает сервис;
  • за какие функции он отвечает;
  • что сервис возвращает в ответ на обращения.

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

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

Компоненты взаимодействуют между собой по протоколам с помощью очереди событий. Она поставляется через Enterprise Service Bus (ESB) — ПО, которое управляет передачей сообщений между компонентами системы.

курс по теме: PHP-разработчик с нуля до PRO
Вячеслав Епанча Senior PHP Developer в Laba
 

Слоеная архитектура

Приложение, следующее SOA, условно разделяется на слои, каждый из которых отвечает за определенную работу:

  • Business Process Layer — слой для объединения сервисов и решения задач приложения;
  • Service — слой с сервисами;
  • Components — слой с компонентами, которые обеспечивают работу отдельных сервисов. Например, у компонента нет своей собственной базы данных — он обращается к БД, которой пользуются сразу несколько сервисов;
  • Integration Layer — слой, связывающий между собой компоненты отдельного модуля.

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

Плюсы SOA:

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

Минусы SOA:

  • Связанные модули зависят друг от друга;
  • Чем больше связей между сервисами, тем больше изменений нужно отслеживать;
  • Когда над разными сервисами работает много команд, им сложно кооперироваться для поддержки продукта и внесения изменений, которые касаются нескольких сервисов. В таком случае поддерживать высокую скорость гибкой разработки невозможно;
  • Высокая стоимость продукта с увеличением количества сервисов;

Переход к микросервисной архитектуре (следующая итерация развития SOA) решает эти недостатки. Компоненты становятся меньше, имеют свои собственные ресурсы и хранилища данных, а для коммуникации используют только HTTP.

 

Ещё статьи
Платформи для волонтерів, пошук житла, корисні карти та ігри.