Проектирование архитектуры информационных систем

1.6 Сравнение монолитной и микросервисной архитектуры

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

1.7 Архитектурные образцы

Архитектурный образец, или архитектурный паттерн, представляет собой обобщенное повторно применяемое решение типовой проблемы проектирования. Паттерн не является готовой программой или точной схемой. Он описывает общий принцип организации элементов, условия применения, преимущества, ограничения и последствия. Архитектурные образцы формируются на основе опыта создания множества систем. Они позволяют не разрабатывать каждое решение с нуля, а использовать проверенные подходы. Однако паттерн нельзя применять механически. Необходимо учитывать контекст и требования конкретной системы. Одним из наиболее известных является слоистый архитектурный паттерн. Система разделяется на уровни, каждый из которых выполняет определенную ответственность. Например, выделяются слой представления, слой бизнес-логики, слой доступа к данным и слой хранения данных. Слой представления взаимодействует с пользователем. Слой бизнес-логики реализует правила предметной области. Слой доступа к данным выполняет запросы к хранилищу. Такое разделение упрощает понимание и сопровождение системы. Недостатком слоистой архитектуры может быть прохождение каждого запроса через множество уровней и появление излишних зависимостей. Кроме того, при неправильном проектировании слой бизнес-логики может превратиться в набор процедур, тесно связанных с базой данных. Клиент-серверная архитектура разделяет систему на клиентов, запрашивающих услуги, и серверы, предоставляющие их. Клиент отвечает за взаимодействие с пользователем, сервер — за обработку запросов и управление ресурсами. В двухзвенной архитектуре клиент напрямую взаимодействует с сервером базы данных или серверным приложением. В трехзвенной архитектуре между клиентом и базой данных располагается сервер приложений. Многоуровневая архитектура включает дополнительные уровни и сервисы. Архитектура модель—представление—контроллер, или MVC, разделяет приложение на модель, представление и контроллер. Модель хранит состояние и бизнес-логику, представление отображает данные, контроллер обрабатывает действия пользователя и координирует взаимодействие. MVC особенно распространен в веб-разработке. Например, при открытии страницы товара контроллер принимает запрос, обращается к модели, получает данные и передает их представлению для формирования страницы. Сервисно-ориентированная архитектура, или SOA, организует систему как совокупность сервисов, предоставляющих функции через стандартизированные интерфейсы. Сервисы могут использоваться различными приложениями и бизнес-процессами. SOA часто применяется в крупных организациях для интеграции разнородных систем. Например, сервис проверки клиента может использоваться банковской системой, мобильным приложением и системой кредитования. Микросервисная архитектура имеет общие идеи с SOA, но обычно предполагает более мелкие автономные сервисы, независимое развертывание, децентрализованное управление данными и тесную связь сервисов с отдельными бизнес-возможностями. Событийно-ориентированная архитектура строится вокруг событий. Компонент публикует событие о произошедшем факте, а другие компоненты реагируют на него. Отправитель может не знать, какие получатели обработают событие. Например, событие «Платеж подтвержден» может быть обработано сервисом заказов, системой учета, сервисом уведомлений и аналитической платформой. Событийная архитектура снижает прямую связанность компонентов и хорошо подходит для асинхронных процессов. Однако она усложняет отслеживание последовательности операций, обработку ошибок и обеспечение согласованности данных. Архитектура каналов и фильтров представляет обработку данных как последовательность преобразований. Каждый фильтр выполняет отдельную операцию, а каналы передают данные между фильтрами. Такой паттерн применяется в компиляторах, системах обработки изображений, потоковой аналитике и интеграции данных. Например, поток документов может пройти стадии загрузки, проверки формата, извлечения текста, классификации и сохранения. Архитектура репозитория предполагает наличие центрального хранилища, к которому обращаются различные компоненты. Общая база данных является примером репозитория. Преимуществом является единообразие данных. Недостатком — сильная зависимость компонентов от структуры хранилища. Архитектура брокера используется в распределенных системах для организации взаимодействия между компонентами через посредника. Брокер принимает запросы, определяет получателя и передает сообщения. Примерами являются брокеры сообщений и интеграционные шины. Архитектура микрокернела, или архитектура подключаемых модулей, состоит из минимального ядра и расширений. Ядро реализует базовые функции, а дополнительные возможности подключаются как плагины. Такой подход используется в интегрированных средах разработки, браузерах, системах управления контентом и корпоративных платформах. Гексагональная архитектура, также называемая архитектурой портов и адаптеров, отделяет бизнес-логику от внешних технологий. Центральная часть системы содержит правила предметной области. Взаимодействие с базами данных, пользовательским интерфейсом, внешними сервисами и очередями осуществляется через порты и адаптеры. Благодаря этому бизнес-логика меньше зависит от конкретной базы данных или веб-фреймворка. Например, вместо прямого обращения к определенной СУБД бизнес-компонент использует абстрактный интерфейс хранения, а конкретный адаптер реализует этот интерфейс. Чистая архитектура и луковичная архитектура развивают похожие идеи. Основные правила предметной области размещаются в центре, а технические детали находятся на внешних уровнях. Зависимости направлены внутрь, к более стабильной бизнес-логике. Архитектурные паттерны могут комбинироваться. Например, микросервисная система может использовать событийное взаимодействие, а каждый сервис внутри может быть построен по гексагональной или слоистой архитектуре.

1.7.1 Отличие архитектурного паттерна от шаблона проектирования

Архитектурный паттерн необходимо отличать от шаблона проектирования. Архитектурный паттерн определяет крупномасштабную структуру системы или приложения. Шаблон проектирования решает более локальную задачу организации классов и объектов. Например, MVC является архитектурным паттерном, поскольку определяет структуру приложения. Шаблон «Фабрика» определяет способ создания объектов, а шаблон «Наблюдатель» — способ уведомления зависимых объектов об изменениях. Граница между уровнями может быть условной, однако архитектурные паттерны обычно оказывают влияние на всю систему и связаны с фундаментальными решениями.

1.8 Эталонные модели

Эталонная модель представляет собой абстрактную систему понятий, функций и отношений, описывающую определенную предметную или технологическую область. Она служит основой для понимания, классификации и сравнения систем. Эталонная модель не определяет конкретные программные продукты или технологии. Она описывает, какие сущности и виды взаимодействий существуют в рассматриваемой области. Одним из известных примеров является эталонная модель взаимодействия открытых систем OSI. Она делит сетевое взаимодействие на семь уровней: физический, канальный, сетевой, транспортный, сеансовый, представительный и прикладной. Модель OSI не является готовой сетевой архитектурой конкретной организации. Она предоставляет понятийную структуру, позволяющую понимать функции протоколов и их положение в системе взаимодействия. Другим примером является эталонная модель открытой распределенной обработки RM-ODP. Она предлагает описывать распределенную систему с нескольких точек зрения: организационной, информационной, вычислительной, инженерной и технологической. Организационная точка зрения описывает цели, правила, роли и процессы. Информационная точка зрения рассматривает структуру и смысл информации. Вычислительная точка зрения показывает функциональное разделение на взаимодействующие объекты. Инженерная точка зрения описывает механизмы распределенного взаимодействия. Технологическая точка зрения определяет конкретные технологии реализации. Эталонные модели помогают создать общий язык для участников проекта. Если все стороны используют согласованные понятия, уменьшается вероятность неоднозначного понимания.

1.9 Эталонные архитектуры

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

1.10 Эталонные варианты архитектур

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

1.11 Соотношение паттерна, эталонной модели и эталонной архитектуры

Архитектурный паттерн, эталонная модель и эталонная архитектура различаются по уровню абстракции и назначению. Архитектурный паттерн описывает повторяющийся принцип решения проблемы. Например, слоистая архитектура или событийно-ориентированная архитектура. Эталонная модель описывает основные понятия и отношения в определенной области. Например, OSI или RM-ODP. Эталонная архитектура показывает типовую структуру класса систем. Она может использовать несколько паттернов и опираться на эталонную модель. Эталонный вариант архитектуры представляет конкретизированную конфигурацию, адаптированную к определенному сценарию. Например, модель OSI дает понятия уровней сетевого взаимодействия. Клиент-серверный паттерн задает общий способ взаимодействия. Эталонная архитектура корпоративной сети описывает типовые сегменты, сервисы и средства защиты. Эталонный вариант показывает конкретное размещение серверов, межсетевых экранов и сетевых зон для организации определенного масштаба.

1.12 Архитектурные структуры

Архитектурная структура представляет собой способ организации архитектурных элементов и отношений между ними. Одна система может иметь множество структур, поскольку различные задачи требуют рассмотрения разных элементов и связей. Например, с точки зрения программного кода система состоит из модулей и зависимостей между ними. С точки зрения выполнения она состоит из процессов, потоков и каналов связи. С точки зрения развертывания она состоит из программных компонентов и вычислительных узлов. Каждая из этих структур отражает реальную сторону архитектуры. Обычно архитектурные структуры объединяются в несколько крупных групп: модульные структуры, структуры компонентов и соединителей и структуры распределения. Модульные структуры описывают организацию программного кода и единиц разработки. Элементами являются модули, пакеты, библиотеки, классы и подсистемы. Отношения показывают зависимости, использование, наследование и включение. Одной из модульных структур является структура декомпозиции. Она показывает, как система разделена на подсистемы и модули. Например, система может быть разделена на управление пользователями, каталог, заказы, платежи и отчеты. Другой модульной структурой является структура использования. Она показывает, какой модуль использует функции другого модуля. Такая структура помогает контролировать зависимости и предотвращать циклические связи. Структура слоев показывает распределение модулей по уровням абстракции. Верхние слои используют нижние, но нижние не должны зависеть от верхних. Структуры компонентов и соединителей описывают систему во время выполнения. Элементами являются процессы, сервисы, компоненты, базы данных, очереди и другие исполняемые единицы. Соединители представляют вызовы, сообщения, события, потоки данных и протоколы. Например, структура выполнения интернет-магазина может включать веб-клиент, API-шлюз, сервис заказов, платежный сервис, брокер сообщений и базу данных. Такая структура позволяет анализировать производительность, параллелизм, надежность и сетевое взаимодействие. Структуры распределения, или структуры размещения, показывают, как программные элементы связаны с окружением. К ним относится структура развертывания, которая отображает размещение компонентов на серверах, виртуальных машинах, контейнерах и сетевых узлах. Структура назначения работ показывает распределение модулей между командами разработки. Структура размещения файлов показывает организацию исходного кода и артефактов. Например, сервис заказов может быть развернут в трех контейнерах на двух вычислительных узлах, а база данных — на отдельном кластере. Такая информация относится к структуре развертывания. Архитектурные структуры помогают отвечать на разные вопросы. Структура модулей показывает, какие части кода придется изменить. Структура выполнения показывает, как пройдет запрос пользователя. Структура развертывания показывает, какие серверы будут задействованы и что произойдет при их отказе.

1.12.1 Архитектурные представления

Архитектурное представление является описанием системы с определенной позиции и для определенных заинтересованных сторон. Оно включает архитектурные элементы, отношения между ними и пояснения. Необходимо различать структуру, представление и точку зрения. Структура существует как организация элементов системы. Представление является ее документированным изображением или описанием. Точка зрения задает правила построения такого представления: какие элементы включать, какие обозначения использовать и какие вопросы решать. Например, структура развертывания существует в системе как реальное размещение программных компонентов. Диаграмма развертывания является архитектурным представлением. Набор правил создания диаграмм развертывания является архитектурной точкой зрения. Разные заинтересованные стороны нуждаются в разных представлениях. Руководителю не требуется детальная схема классов. Ему важны крупные подсистемы, риски и затраты. Разработчику необходимы модули, интерфейсы и зависимости. Администратору требуется схема серверов, сетей и развертывания. Специалисту по безопасности важны границы доверия, потоки конфиденциальных данных и механизмы контроля доступа. Попытка создать одну универсальную диаграмму для всех участников приводит к перегруженному и малополезному документу. Поэтому архитектура описывается набором взаимосвязанных представлений. Одной из известных моделей является модель представлений «4+1». Она включает логическое представление, представление процессов, представление разработки, физическое представление и сценарии. Логическое представление описывает основные функциональные элементы и объекты предметной области. Оно показывает, каким образом система реализует требуемую функциональность. Представление процессов описывает выполняющиеся процессы, потоки, параллелизм, взаимодействие и синхронизацию. Оно важно для анализа производительности и надежности. Представление разработки показывает организацию программного кода, модулей, библиотек и пакетов. Оно ориентировано на разработчиков. Физическое представление описывает развертывание программных элементов на технической инфраструктуре. Оно важно для системных инженеров и администраторов. Сценарии, обозначаемые как «+1», демонстрируют, как элементы различных представлений взаимодействуют при выполнении конкретных пользовательских задач. Например, сценарий оформления заказа связывает пользовательский интерфейс, сервисы, процессы, данные и инфраструктуру. В современной практике также широко используется модель C4. Она предлагает четыре уровня: контекст системы, контейнеры, компоненты и код. Диаграмма контекста показывает систему, пользователей и внешние системы. Диаграмма контейнеров показывает крупные исполняемые приложения и хранилища данных. Диаграмма компонентов раскрывает внутреннее устройство контейнера. Диаграмма кода описывает классы и другие элементы реализации. Модель C4 позволяет постепенно увеличивать детализацию, не перегружая представления.

1.12.2 Требования к архитектурным представлениям

Архитектурные представления должны быть понятными, непротиворечивыми, актуальными и соответствовать целям аудитории. Каждая диаграмма должна отвечать на конкретный вопрос. Например, схема контекста должна показывать границы системы и внешние взаимодействия. Она не должна содержать сотни внутренних классов. Диаграмма развертывания должна показывать узлы и размещение компонентов, а не подробно описывать бизнес-процессы. Необходимо использовать согласованные обозначения. Если один и тот же компонент на разных диаграммах называется по-разному, возникает неоднозначность. Представления должны быть связаны между собой. Компонент, указанный на логической схеме, должен иметь соответствующее место в структуре реализации и развертывания. Важна актуальность документации. Архитектурная схема, не соответствующая реальной системе, может быть опаснее отсутствия схемы, поскольку вводит участников в заблуждение. При этом документация не должна становиться самоцелью. Необходимо создавать те представления, которые действительно помогают принимать решения, разрабатывать, тестировать и эксплуатировать систему.

1.13 Проектирование архитектуры «сверху вниз»

В исходной формулировке темы дважды указано проектирование «снизу вверх». В теории архитектуры обычно рассматриваются два взаимодополняющих подхода: проектирование «сверху вниз» и проектирование «снизу вверх». Для полного понимания проектирования архитектуры необходимо раскрыть оба подхода. Проектирование сверху вниз начинается с целей, требований и общего представления системы. Сначала система рассматривается как единое целое, затем последовательно разделяется на подсистемы, компоненты и более мелкие элементы. На первом этапе определяются цели организации и границы системы. Затем выявляются основные функции, информационные потоки и внешние взаимодействия. После этого функции распределяются между подсистемами, а подсистемы разбиваются на компоненты. Например, при проектировании системы университета сначала определяется общая цель — автоматизация образовательной деятельности. Затем выделяются крупные области: управление контингентом, учебные планы, расписание, успеваемость, электронное обучение и отчетность. Далее каждая область разделяется на более конкретные функции и модули. Подход сверху вниз обеспечивает соответствие архитектуры целям и требованиям. Он помогает избежать ситуации, когда система представляет собой случайный набор технологий и компонентов. Функциональная декомпозиция является характерным инструментом проектирования сверху вниз. Общая функция разделяется на подфункции до тех пор, пока элементы не станут достаточно конкретными для реализации. Преимуществом подхода является целостность. Архитектура формируется на основе общей картины, а локальные решения подчиняются системным целям. Однако чистое проектирование сверху вниз имеет ограничения. Архитектор может создать логически стройную модель, которая не учитывает реальные технологии, существующие системы, ограничения инфраструктуры и доступные компоненты. Например, архитектура может предполагать использование полностью независимых сервисов, но существующая база данных и организационная структура не позволяют разделить данные и ответственность. Поэтому проектирование сверху вниз должно сопровождаться анализом практических ограничений снизу.

1.14 Проектирование архитектуры «снизу вверх»

Проектирование снизу вверх начинается с анализа существующих компонентов, технологий, данных, систем, библиотек, оборудования и технических возможностей. Из отдельных элементов формируются более крупные подсистемы, а затем общая архитектура. Такой подход особенно характерен для проектов модернизации, интеграции и развития наследуемых систем. В организации уже могут существовать базы данных, приложения, серверы, интерфейсы и процессы. Архитектор не может игнорировать их и проектировать полностью новую систему без учета реального состояния. Например, предприятие планирует создать единую систему аналитики. Уже существуют бухгалтерская система, система управления складом, CRM, производственная система и множество файловых отчетов. Проектирование снизу вверх начинается с изучения источников данных, форматов, интерфейсов и качества информации. Затем создается интеграционная архитектура и аналитическое хранилище. Подход снизу вверх может использоваться и при создании новой системы, если применяются готовые платформы, библиотеки и облачные сервисы. Архитектор анализирует возможности доступных компонентов и на их основе формирует решение. Например, если облачная платформа предоставляет готовые сервисы аутентификации, хранения файлов, очередей сообщений и мониторинга, архитектура может быть построена с учетом этих сервисов. Преимуществом проектирования снизу вверх является реалистичность. Решение учитывает существующие ограничения и доступные ресурсы. Можно повторно использовать проверенные компоненты, сократить сроки и снизить затраты. Однако у подхода имеются риски. Если архитектура формируется только из существующих компонентов, она может не соответствовать целям бизнеса. Система превращается в набор технических решений без единой концепции. Например, организация может использовать определенную базу данных только потому, что она уже установлена, хотя новая система требует другого типа хранения. Или архитектура может строиться вокруг старого приложения, которое давно ограничивает развитие. Проектирование снизу вверх может приводить к локальной оптимизации. Каждый компонент хорошо решает свою задачу, но система в целом оказывается сложной, несогласованной и дорогой в сопровождении. Поэтому необходимо оценивать не только возможность повторного использования компонента, но и его влияние на долгосрочную архитектуру.