Распределённые стили: SOA
В прошлом уроке вы познакомились с одним из самых распространённых типов монолитных стилей — многослойной архитектурой. В этом уроке вы узнаете об архитектуре на основе сервиса и познакомитесь с сервис-ориентированной архитектурой, которая относится к распределённому стилю, с её отличительными чертами, узнаете, чем она принципиально отличается от многослойной архитектуры и когда её стоит использовать.
Подходы к разделению архитектуры ПО
Существует два подхода к разделению архитектуры ПО на части:
- Техническое разделение (Technical partitioning) — это группирование функций приложения по слоям.
- Разделение по предметной области (Domain partitioning) — это группирование функций приложения по предметной области.
Рассмотрим на примере приложения интернет-магазина. В предметной области любого интернет-магазина есть такие понятия, как заказ, доставка, оплата, клиенты и программа лояльности.
В случае технического разделения относящиеся к доставке функции будут распределены по разным слоям:
- Слой представления будет отображать экран для ввода адреса доставки.
- Бизнес-слой будет рассчитывать стоимость доставки.
- Сервисный слой будет обрабатывать ошибку неправильно введённого адреса.
- Слой доступа к данным будет извлекать из хранилища справочники городов, улиц и домов.
- Слой хранилища сохранит адрес доставки после оформления заказа.
В случае разделения по предметной области все относящиеся к доставке функции будут сгруппированы в соответствующем элементе ПО.
Если команде разработки потребуется внести изменения в приложение, например предоставить клиентам магазина возможность добавления товаров в избранное, то в случае технического разделения им потребуется доработать все слои:
- В слое представления добавить элементы интерфейса для добавления в избранное и экран просмотра избранных товаров.
- В бизнес-слое добавить проверку возможности добавления товара в избранное, например, если товар раскупили.
- В сервисном слое добавить обработку ошибки в случае повторного добавления товара в избранное.
- В слое доступа к данным добавить SQL-запросы на извлечение избранных товаров, запись в таблицу с избранными товарами и удаление записи.
- В слое хранилища добавить таблицу с избранными товарами по клиентам.
В случае разделения по предметной области команде потребуется:
- Добавить таблицу с избранными товарами по клиентам.
- Сгруппировать все перечисленные выше изменения в отдельный элемент ПО «Избранное».
Подход к разделению архитектуры ПО определяет организацию программного кода приложения:
- В случае технического разделения разработчику фронтенда нужно будет сначала найти часть программного кода, реализующую логику представления, а затем добавить в неё экран просмотра избранных товаров.
- В случае разделения по предметной области разработчику фронтенда нужно будет сначала найти часть кода, реализующую связанные с избранными товарами функции, а затем добавить в неё экран просмотра избранных товаров.
Чтобы клиенты интернет-магазина могли добавлять товары в избранное, команде разработки потребуется:
- В случае технического разделения развернуть все слои приложения единовременно.
- В случае разделения по предметной области развернуть только «Избранное» и хранилище данных.
Если примером технического разделения является многослойная архитектура, то примером разделения по предметной области является архитектура на основе сервиса, которая относится к распределённым стилям.
Распределённые стили
Распределённые стили подразумевают развёртывание частей программного кода ПО в разное время, а значит, в распределённой архитектуре части ПО вводятся в эксплуатацию по отдельности. В этом ключевое отличие распределённого стиля от многослойного стиля.
К распределённым архитектурным стилям относятся:
- архитектура на основе сервиса (Service-based architecture),
- событийно-ориентированная архитектура (Event-driven architecture),
- архитектура на основе пространства (Space-based architecture).
Архитектура на основе сервиса используется чаще всех перечисленных распределённых стилей.
Архитектура на основе сервиса
Основным элементом архитектуры на основе сервиса является сервис (Service). Сервис также называют услугой или службой.
Сервис — это независимо развёртываемый элемент ПО, который реализует некоторую функцию. Одни сервисы реализуют значимые для пользователей функции, а другие — незначимые.
Незначимой для пользователей функцией является, например, сбор данных об отдельных действиях пользователей, исключениях и событиях, связанных с информационной безопасностью, — ведение журналов аудита. Ведение журналов аудита называют также журналированием или логированием (Logging).
К архитектуре на основе сервиса относятся:
- сервис-ориентированная архитектура (Service-oriented architecture — SOA),
- микросервисная архитектура (Microservices architecture).
Оба этих стиля также состоят из сервисов, при этом характеристики этих сервисов различаются.
Типы сервисов SOA
Как и другие стили архитектуры на основе сервиса, SOA определяет возможные типы сервисов исходя из выполняемых ими ролей в архитектуре ПО.
В SOA выделяют следующие типы сервисов:
- Бизнес-сервис (Business service).
- Сервис предприятия (Enterprise service).
- Сервис приложения (Application service).
- Инфраструктурный сервис (Infrastructure service).
Рассмотрим типы сервисов на примере приложения для доставки цветов. С его помощью пользователи могут заказать доставку букета. С ростом бизнеса добавились ещё функции написания поздравительной открытки и доставка небольших подарков, исполнение поздравительной песни и прочее.
Это значит, что вместо автоматизации одного бизнес-процесса (доставка цветов) приложение должно автоматизировать несколько.
Бизнес-сервис
Бизнес-сервис — это абстрактный, высокоуровневый, крупный сервис, который соответствует одному из основных бизнес-процессов предприятия.
Поскольку это абстрактный сервис, он не реализует функции, а только принимает и отправляет сообщения. Обычно бизнес-сервис включает только название, ожидаемые входные и выходные сообщения.
Бизнес-сервисы нужны для взаимодействия приложения, использующего SOA, с клиентами — веб-браузерами, настольными приложениями и другими программами.
Например, бизнес-сервисы могут соответствовать бизнес-процессам доставок цветов и шаров. Когда пользователь приложения для доставки цветов заказывает шарики, веб-браузер на его устройстве отправляет сообщение бизнес-сервису «Доставка шаров» и ожидает от него ответного сообщения.
Бизнес-сервисы в SOA могут быть реализованы с использованием технологии веб-сервисов (Web services). К этим технологиям относятся SOAP, WSDL, XML и другие. С ними вы познакомитесь в следующем спринте.
Сервис предприятия
Сервис предприятия — это более конкретный и менее крупный сервис (по сравнению с бизнес-сервисами), который реализует функции, необходимые для выполнения бизнес-процессов предприятия. То есть сервисы предприятия реализуют функции, предусмотренные бизнес-сервисами. Например, сервисы предприятия могут реализовывать функции, необходимые для оплаты заказов.
Важной особенностью сервисов предприятия, которая определяет их название, является то, что они, как правило, используются повторно любыми другими приложениями предприятия. Это значит, что один сервис предприятия может реализовывать функции, необходимые нескольким бизнес-сервисам.
Например, при появлении отдельного приложения для заказа мероприятий (детских праздников, юбилеев, корпоративов) сервис предприятия «Оплата заказа» может быть повторно использован им.
При этом к сервисам предприятия по-прежнему могут обращаться только бизнес-сервисы. Таким образом, должен быть разработан бизнес-сервис «Организация мероприятий», который будет отправлять запросы к сервису предприятия «Оплата заказа».
Сервисы предприятия отражают ключевую концепцию SOA — делиться как можно большим (Share-as-much-as-possible). Это значит, что командам разработки предприятия следует постоянно делиться с архитектором ПО планами по разработке новых функций, чтобы он мог определить потребности в повторно используемых функциях. Повторно используемые функции он передаст в разработку какой-то одной команде, избавив остальные от этой работы.
Сервис приложения
Сервис приложения — это узкоспециализированный сервис, реализующий уникальную для предприятия функцию. Один сервис приложения реализует функции, необходимые одному сервису предприятия.
Таким образом, они не предполагают повторного использования. Если архитектор ПО обнаруживает, что такая потребность появилась, он может трансформировать сервис приложения в сервис предприятия.
Например, сервис приложения может реализовывать функцию выбора пользователем наполнения шара — воздухом или гелием. Таким образом, бизнес-сервис «Доставка шаров» будет обращаться к сервису предприятия «Формирование заказа», а тот, в свою очередь, к сервису приложения «Выбор наполнения шара».
Инфраструктурный сервис
Инфраструктура (Infrastructure) в контексте IT-индустрии — это аппаратная и программная среда, которая необходима для проектирования, реализации и работы ПО. Так же как городская инфраструктура (магазины, аптеки, дороги и транспорт) необходима людям для жизни и работы, IT-инфраструктура необходима для работы ПО.
Инфраструктурные сервисы решают проблемы, связанные с эксплуатацией сервисов других типов. Например, они реализуют функции мониторинга, логирования, аутентификации и авторизации.
Инфраструктурные сервисы реализуют функции, необходимые сервисам предприятия или сервисам приложения.
За эти сервисы отвечает, как правило, отдельная команда обслуживания инфраструктуры.
Например, инфраструктурные сервисы «Логирование» и «Мониторинг» не влияют на выполнение бизнес-процесса доставки цветов, но позволяют командам разработки отслеживать работу приложения.
Компания — провайдер цифровых услуг предоставляет людям возможность подключить интернет и цифровое телевидение, установить камеры видеонаблюдения в подъезде и квартире и множество других услуг. Клиенты могут заказать эти услуги в мобильном приложении. Приложение разработано в сервис-ориентированном архитектурном стиле.
Определите, какой сервис отвечает за выполнение разных функций в этом приложении.
Оформление заявки на вызов специалиста
Бизнес-сервис
Пользователь пришёл в приложение из-за этой функции ПО. Эта функция выполняет бизнес-задачу.
Расчёт стоимости услуг
Сервис предприятия
Эта функция нужна для выполнения более крупной бизнес-задачи. Потенциально сервис может быть переиспользован для заказа любых услуг в приложении другими командами разработки.
Расчёт параметров для облачных видеонаблюдений
Сервис приложений
Эта функция специфична и указывает на одну конкретную услугу, которая оказывает компания — установка видеонаблюдения. Переиспользование этого сервиса другими командами затруднительно.
Выдача ролей пользователю
Инфраструктурный сервис
Эта функция не относится напрямую к выполнению бизнес-задач, но при этом нужна всем командам разработки приложения.
Промежуточное ПО для обмена сообщениями
Неотъемлемым элементом SOA является промежуточное ПО для обмена сообщениями (Messaging middleware). Это ПО работает как почта: получает запрос от любого сервиса и перенаправляет его другому сервису.
В SOA всё взаимодействие между сервисами, необходимое для выполнения запроса клиента, осуществляется через промежуточное ПО для обмена сообщениями. Таким образом, поток сообщений между элементами SOA выглядит так:
Промежуточное ПО для обмена сообщениями — это отдельная часть программного кода, которая также может быть развёрнута отдельно от сервисов. На диаграмме выше промежуточное ПО изображено три раза для удобства её восприятия.
Архитектурное представление SOA
Рассмотрим архитектуру приложения, использующего SOA. Архитектурные представления SOA и других стилей, относящихся к архитектурам на основе сервиса, описывают структуру сервисов ПО.
Так как клиенты (веб-браузеры, настольные приложения и другие программы) взаимодействуют с бизнес-сервисами, то в архитектурном представлении бизнес-сервисы располагаются в верхней части.
Промежуточное ПО для обмена сообщениями изображают однократно — под бизнес-сервисами. Под ним расположены сервисы предприятия, затем сервисы приложений и инфраструктурные сервисы.
Такая последовательность отражает основной поток сообщений в SOA.
Хранилище данных, как правило, не рассматривают в архитектурном представлении SOA. Это происходит потому, что этот стиль не предъявляет никаких требований к хранилищам данных, их формату и взаимодействию сервисов с ними.
Например, у каждого сервиса может быть своя собственная база данных, или он может делить её с другими сервисами.
Рейтинг архитектурных характеристик
Рассмотрим рейтинг архитектурных характеристик SOA.
Производительность (низкий)
По сравнению с монолитными стилями, распределённые помогают достичь неплохих показателей производительности приложения. Это происходит за счёт того, что запросы проходят не через один закрытый бизнес-слой, как в многослойной архитектуре, а через несколько сервисов.
При этом из-за того, что все запросы проходят через промежуточное ПО для обмена сообщениями (сервисную шину предприятия), оно может стать «узким горлышком», ведь с ростом количества запросов время выполнения бизнес-процессов будет увеличиваться.
Также недоступность сервисной шины предприятия может привести к недоступности всех сервисов предприятия.
Возможность модификации (низкий)
Хотя в этом стиле архитектуры есть возможность развёртывать каждый сервис независимо, изменения в одном сервисе предприятия требуют согласования со всеми командами разработки, которые его используют.
Также с ростом количества сервисов модификация сервисной шины предприятия будет требовать бо́льших ресурсов команды разработки.
Масштабируемость (высокий)
SOA не накладывает ограничений на количество сервисов, которые можно использовать. Поэтому показатель масштабируемости может быть достаточно высоким.
Однако добавление каждого нового сервиса увеличивает нагрузку на сервисную шину, а также увеличивает сложность разработки, развёртывания и тестирования.
Простота разработки (низкий)
Сложность разработки в этом архитектурном стиле проявляется в двух ситуациях:
- Разработка сервисов, которые могут быть повторно использованы. Архитектор ПО, системный аналитик и разработчик должны проделать большую работу, чтобы учесть интересы всех бизнес-сервисов и создать такой сервис предприятия, который сможет выполнить их задачи.
- Изменение сервисов предприятия. Если нужно изменить один из сервисов предприятия, команда разработки должна точно определить, как эти изменения отразятся на других сервисах. Чем больше бизнес-сервисов использует сервис предприятия, тем выше цена ошибки при разработке.
Простота развёртывания (низкий)
В SOA в эксплуатацию вводится каждый сервис по отдельности.
Так как бизнес-сервис может использовать несколько сервисов предприятия, то при обновлении одного из них все связанные бизнес-сервисы будут недоступны. В итоге это создаёт неудобства для пользователей. Например, они могут посмотреть список товаров, но не могут их заказать. Поэтому при развёртывании каждого сервиса необходимо отслеживать, какие бизнес-сервисы будут недоступны. И согласовывать время развёртывания со всеми пользователями сервиса предприятия.
Чем больше сервисов предприятия, тем сложнее становится процедура развёртывания.
Простота тестирования (низкий)
Тестирование приложения в SOA будет непростым. Причина та же, что и при развёртывании приложения: каждый сервис предприятия может участвовать в работе нескольких бизнес-сервисов. А значит, изменения в этом сервисе предприятия могут повлиять на работу бизнес-сервисов.
Когда использовать SOA
Сервис-ориентированная архитектура отлично подходит для:
- Крупных предприятий Когда в организации работает множество взаимодействующих систем, использование сервисной шины предприятия позволяет этим системам развиваться независимо друг от друга. Такие системы могут быть реализованы с использованием разных технологий, но благодаря промежуточному ПО для обмена сообщениями эти различия не будут влиять на их взаимодействие. Этот стиль архитектуры можно встретить в ПО, используемом в финансовой и нефтегазовой отраслях, а также в металлургии.
- Нескольких команд разработки При наличии в организации нескольких команд разработки поддерживать многослойный тип архитектуры достаточно сложно, так как небольшие изменения будут приводить к длительной процедуре согласований со всеми командами. В сервис-ориентированной архитектуре у команды есть персональные сервисы приложений, которые можно менять независимо от других команд. Изменения в сервисах предприятия, которые не влияют на другие сервисы и промежуточное ПО, также не требуют согласований со всеми командами. Однако, если в работе организации много бюрократических процессов, процесс согласования крупных изменений в сервисах или промежуточном ПО может существенно замедлить развитие ПО.
Подведём итоги
Основным элементом архитектуры на основе сервиса является сервис — это независимо развёртываемый элемент ПО, который реализует некоторую функцию.
В сервис-ориентированной архитектуре (SOA) выделяют следующие типы сервисов:
- Бизнес-сервис Абстрактный, высокоуровневый, крупный сервис, который соответствует одному из основных бизнес-процессов предприятия. Бизнес-сервисы в SOA могут быть реализованы с использованием технологии веб-сервисов.
- Сервис предприятия Более конкретный и менее крупный сервис (по сравнению с бизнес-сервисами), который реализует функции, необходимые для выполнения бизнес-процессов предприятия.
- Сервис приложения Узкоспециализированный сервис, реализующий уникальную для предприятия функцию.
- Инфраструктурный сервис Аппаратная и программная среды, которые необходимы для проектирования, реализации и работы ПО.
Неотъемлемым элементом SOA является промежуточное ПО для обмена сообщениями. Всё взаимодействие между сервисами, необходимое для выполнения запроса клиента, осуществляется через него.
Главное преимущество SOA — это масштабируемость, так как она не накладывает ограничений на количество сервисов, которые можно использовать.