Зачем нужна сервис-ориентированная архитектура
Как разбить приложение на модули.
Стоимость разработки зависит от количества нового функционала. Чем больше фич будет реализовано в приложении, тем больше времени уйдет на их внедрение. На стоимость разработки влияют и технологический стек продукта, и архитектурные подходы, которым следует команда.
Cервис-ориентированная архитектура (SOA, service-oriented architecture) помогает достичь баланса между стоимостью и скоростью. SOA базируется на разделении приложения на слабо связанные компоненты (сервисы).
Объясняем, как разбиение логики на модули упрощает разработку.
Сервисы как отдельные части
Основная единица SOA — сервис, отвечающий за конкретный бизнес-процесс. Например, в приложении могут быть отдельные сервисы для:
- авторизации пользователей;
- логирования;
- оповещений.
Крупные задачи разделяются между модулями. Для описания содержимого и функций сервиса нет строгих правил. Команда сама определяет, что нужно сервису. При этом сами сервисы следуют контрактам (четким правилам):
- что именно может подключиться к сервису;
- по какому протоколу и через какой интерфейс идет передача данных;
- с какими данными работает сервис;
- за какие функции он отвечает;
- что сервис возвращает в ответ на обращения.
Модули нижнего уровня ничего не знают о реализации верхних, кроме протокола, по которому они работают с ресурсами. Сервисы только передают и принимают данные, не имея доступа к методам друг друга. Кроме того, все события обрабатываются асинхронно. Не должно быть ситуаций, когда сервисы не работают из-за того, что ожидают ответа от других систем.
Так как сервисы представляют отдельные функции, их можно переиспользовать в разных приложениях. Объединение сервисов в более крупные сущности называется оркестровкой. Разработчик получает конструктор, из которого может собирать приложения.
Компоненты взаимодействуют между собой по протоколам с помощью очереди событий. Она поставляется через Enterprise Service Bus (ESB) — ПО, которое управляет передачей сообщений между компонентами системы.
Слоеная архитектура
Приложение, следующее SOA, условно разделяется на слои, каждый из которых отвечает за определенную работу:
- Business Process Layer — слой для объединения сервисов и решения задач приложения;
- Service — слой с сервисами;
- Components — слой с компонентами, которые обеспечивают работу отдельных сервисов. Например, у компонента нет своей собственной базы данных — он обращается к БД, которой пользуются сразу несколько сервисов;
- Integration Layer — слой, связывающий между собой компоненты отдельного модуля.
Преимущества и недостатки SOA
Плюсы SOA:
- Гибкость — модули запускаются отдельно. В результате архитектура получается распределенной и не зависит от платформы. Разные компоненты можно писать на разных языках программирования и фреймворках, а затем размещать на отдельных серверах;
- Легко интегрировать новые фичи — достаточно написать новый сервис и определить, по каким протоколам он будет взаимодействовать с остальными;
- SOA обеспечивает инкапсуляцию — бизнес-функции изолируются друг от друга, что повышает отказоустойчивость. Если изменяется один из сервисов, нужно перезапустить только те части, которые с ним взаимодействуют. Приложение может работать, пусть и с ограниченным функционалом. Когда падает сервис, отвечающий за рассылку писем, сервис для авторизации пользователей продолжает работу;
- Сервис не привязан к одному приложению и может использоваться в другом. Разработчик может написать две реализации одного и того же сервиса: один из них обеспечивает основную бизнес-логику, а второй используется для тестирования новых фич;
Минусы SOA:
- Связанные модули зависят друг от друга;
- Чем больше связей между сервисами, тем больше изменений нужно отслеживать;
- Когда над разными сервисами работает много команд, им сложно кооперироваться для поддержки продукта и внесения изменений, которые касаются нескольких сервисов. В таком случае поддерживать высокую скорость гибкой разработки невозможно;
- Высокая стоимость продукта с увеличением количества сервисов;
Переход к микросервисной архитектуре (следующая итерация развития SOA) решает эти недостатки. Компоненты становятся меньше, имеют свои собственные ресурсы и хранилища данных, а для коммуникации используют только HTTP.
