Продолжая недавний разговор про основы архитектуры информационных систем для начинающих системных и бизнес-аналитиков сегодня разберем, чем монолит отличается от микросервисной модели, каковы преимущества модульной организации ИС и какой ценой они достигаются.
Что такое микросервисная архитектура ИС
Если рассматривать информационную систему как хранилище данных и набор интерфейсов для работы с ней, которые позволяют решать специализированные бизнес-задачи, удовлетворяя потребности пользователя, то возникает вопрос, как это реализовать. Хотя задачи реализации не относятся к области ответственности аналитика, аналитику невозможно корректно и полностью разработать требования к ИС, не представляя базовых принципов организации взаимодействия ее компонентов.
Напомню, если все компоненты трехслойной архитектуры информационной системы распределены по нескольким устройствам, она называется распределенной. Подробнее об этом читайте здесь. Однако, простое вынесение каждого слоя на отдельный аппаратный или программный узел не является оптимальным решением для многофункциональных ИС, которые включают целый набор возможностей. Например, интернет-банк, маркетплейс, CRM или СЭД. Модель данных такой ИС затрагивает несколько доменов, каждый из которых имеет множество специфических сущностей: каталоги товаров, платежи, доставка и т.д. Проектирование и разработка такой сложной системы занимают много времени и сил. А рефакторинг для исправления ошибок или внесения изменений из-за внутренних или внешних событий превращается в целый трудоемкий проект.
Основы архитектуры и интеграции информационных систем
Код курса
OAIS
Ближайшая дата курса
20 мая, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
Поэтому в середине 2010-х годов, наряду с ростом интереса к Agile-практикам, активное распространение получил подход проектирования и реализации ИС в виде набора слабосвязанных и взаимодействующих между собой модулей – микросервисов. Приставка «микро» здесь относится не к размеру кодовой базы, а подчеркивает модульный характер программных компонентов одной системы. Сервисы разделяют по принципу единой ответственности: каждый из них реализует лишь ограниченный набор функций, сгруппированных по контексту. Например, в интернет-банке за работу с картами отвечает один сервис, за вклады – другой, а за кредиты – третий.
У каждого сервиса своя модель данных, и чаще всего, отдельная БД и СУБД, заточенная под его назначение. Например, для сервиса, который отвечает за проведение платежей, т.е. финансовые транзакции, нужна реляционная OLTP-СУБД, отвечающая всем ACID-требованиям. Что это такое и почему это особенно важно в распределенных системах, рассмотрим в следующий раз. А сервису аналитики событий пользовательского поведения нужна совершенно другая структура организации данных: здесь не столько важны ACID-транзакции, сколько возможность построения сложных аналитических запросов по огромным таблицам с разными типами данных в их полях. Аналогичная модульность с ограничением ответственности соблюдается и в другом backend-компоненте – серверном приложении, которое отвечает за бизнес-логику, т.е. обработку данных и команд, поступивших от клиента. Сервис включает только те функции, которые нужны для рассматриваемого домена, например, доставка товаров интернет-магазина. Такое разделение не заметно на уровне пользователя, поскольку в GUI-интерфейсе его клиентского приложения, которое выполняет роль терминала для отображения данных и ввода команд, присутствуют возможности обращения к нескольким сервисам ИС.
Кроме упрощения процессов проектирования и разработки сложных ИС, микросервисная архитектура также выгодна с практической точки зрения: обычно за один сервис отвечает отдельная команда ИТ-специалистов. Разделив большой объем на несколько независимых модулей, можно распараллелить эти работы и сократить общее время создания продукта (TTM, Time To Market). Обратной стороной этих достоинств является целый набор сложностей проектирования и реализации микросервисного взаимодействия, что мы рассмотрим далее.
Монолит vs микросервисы: что не так с модной Agile-архитектурой
Несмотря на упрощение процессов реализации и поддержки системы с микросервисной архитектурой, проектирование такой ИС как набора сервисов является непростой задачей даже для опытного ИТ-архитектора. Хотя для этого существует целый набор архитектурных паттернов – шаблонов, которые воплощают лучшие практики организации взаимодействия микросервисов как друг с другом, так и с клиентскими приложениями, а также базами данных. Тем не менее, для любых микросервисных систем характерны такие недостатки, как задержки из-за передачи данных по сети между разными модулями и необходимость согласования форматов обмена данными для их интеграции.
Поэтому монолитные ИС до сих пор живут и имеют право на существование, будучи намного предпочтительнее в некоторых ситуациях по сравнению с микросервисами. В монолитной архитектуре после этапа разработки требований можно сразу приступить к реализации бизнес-логики, не тратя время на тщательное продумывание межпроцессного взаимодействия атомарных модулей. Монолит легче тестировать и развертывать. Кроме того, управлять одной командой разработчиков проще, чем дирижировать целым оркестром отдельных групп.
Наконец, сам процесс разделения единой системы на несколько сервисов не всегда прост и прозрачен. Не существует универсального рецепта декомпозиции ИС на независимые, но взаимодействующие друг с другом модули. Например, можно выделять микросервисы по бизнес-возможностям ИС, по доменам или сценариям использования. Другим вопросом является гранулярность микросервисной системы: насколько большим может быть каждый сервис и насколько сильно они могут быть связаны между собой. Впрочем, это относится к области ответственности архитектора ПО, а не аналитика.
Но, чтобы архитектор мог оптимально выполнить свои задачи по проектированию решения, включая выделение микросервисов и организацию их взаимодействия, аналитик должен корректно определить ключевые функциональные и нефункциональные требования к ИС. А в случае взаимодействия с внешними системами здесь же решаются задачи разработки требований к интеграции, о чем я расскажу в следующих статьях.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
3 июня, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
Как это сделать все это наиболее эффективным образом, вы узнаете на моих курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
- Основы архитектуры и интеграции информационных систем
- Разработка ТЗ на информационную систему по ГОСТ и SRS
