С тех пор как я начал выполнять обязанности системного архитектора, мне чаще приходится рисовать прямоугольники и стрелки, чем писать программный код. С этим можно было бы бороться, например, бессонными ночами участвовать в проектах с открытым исходным кодом, создавать подтверждения осуществимости концепции и демонстрационный код, но и там тоже нужно рисовать прямоугольники, чтобы продемонстрировать архитектуру. Эта статья посвящена визуализации обмена сообщениями в распределенных системах, сервис-ориентированной архитектуре (SOA) и микросервисным приложениям при использовании методологии разработки agile (этот термин потерял свое значение, но более подходящего в данном случае нет).

Что мне нравится в сфере программного обеспечения в последние годы, так это то, что в большинстве организаций, в которых я работал, ценятся принципы бережливой и гибкой методологии разработки ПО. Все стремятся создавать готовое программное обеспечение (а не документацию), быстро выдавать результат (а не заниматься долгим планированием), исключить потери и реагировать на изменения. Для реализации этих принципов используются такие методы управления, как Scrum, «канбан» и технические методы, позаимствованные из методологии экстремального программирования (например, модульное тестирование и парное программирование), а также методы CI/CD и DevOps. В общем, я решил собрать в одном месте схемы и инструменты проектирования, которые я использую в своей повседневной работе с распределенными системами.

Проблемы модели представлений «4+1» и «смерть от UML»

Каждый проект сопровождается на старте большими амбициями, но каждый раз не хватает времени на то, чтобы все довести до совершенства, и в итоге приходится выдавать что-то, что более-менее работает. И это хорошо — таким образом окружающий мир помогает нам избегать украшательства и соблюдать такие принципы, как YAGNI и KISS. В результате мы выполняем необходимый минимум и адаптируемся к изменениям.

Большинство схем, которые я встречал, были основаны на модели представлений «4+1» Филиппа Крачтена, которая имеет представление разработки, процесса, а также логическое и физическое представление.


Модель представлений «4+1». Изображение взято из книги Практическое руководство по архитектуре предприятия (A Practical Guide to Enterprise Architecture), авторы: Джеймс МакГаверн, Скотт В. Амблер, Майкл Е. Стивенс, Джеймс Линн, Викас Шаран, Элияс К. Джо, 2003 год.

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

Применимость диаграмм

Как правило, эти представления описываются с помощью унифицированного языка моделирования (unified modeling language, UML), и для каждого представления требуется создавать одну или несколько UML-диаграмм. Если мне нужно создать 15 типов UML-диаграмм, чтобы описать и доступно объяснить архитектуру системы, то это противоречит предназначению UML.


Death by UML (Смерть от UML). Фрагменты диаграммы Пауло Мерсона из Википедии.

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

Еще один недостаток существующих UML-диаграмм заключается в том, что они описывают в первую очередь объектно-ориентированные архитектуры, а не архитектуры на основе каналов и фильтров. В приложениях для обмена сообщениями главную роль играет не структура, а методы взаимодействия между элементами, маршрутизация и потоки данных. Диаграммы классов объектов, компонентов, пакетов и др. — это далеко не эффективная форма описания процессов обработки на основе каналов и фильтров. Диаграммы поведения UML (например, диаграммы активности и последовательности) более содержательны, но также не позволяют легко описывать основные концепции интеграционных приложений, такие как фильтрация и маршрутизация с учетом содержимого.

Применимость представлений

Представления, отражающие различные аспекты системы, — отличная форма описания ее концепции, однако существующие представления модели «4+1» не соответствуют практике разработки и развертывания современного программного обеспечения. Идея направленного потока — когда сначала создается логическое представление, затем вытекающие из него представления разработки и процессов, а в конце и соответствующее физическое представление не всегда согласуется с действительностью. Жизненный цикл разработки систем отличается от традиционной (водопадной) последовательности сбора требований, проектирования, реализации и сопровождения.


Жизненный цикл разработки программного обеспечения. Фрагмент рисунка Web Serv.

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

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

Средства визуализации интеграционных приложений

Самая полезная, с моей точки зрения, модель описана Саймоном Брауном и носит название модель C4 (я советую скачать бесплатную копию отличной книги Саймона «Искусство визуализации архитектуры программного обеспечения» (The Art of Visualising Software Architecture)). Описывая свою модель, Саймон отмечает важность наличия единого набора абстракций, а не общей нотации (например, UML), и использования небольшого набора диаграмм для создания абстракций различного уровня: контекста системы, контейнеров, компонентов и классов. Этот подход нравится мне тем, что предполагает движение от общего к частному, начиная с самого общего представления с его последующей детализацией на каждом новом уровне.

Модель C4 не всегда идеально подходит для создания связующего программного обеспечения и интеграции приложений, однако более эффективна, чем предыдущие. Если бы мы воспользовались ей, то диаграмма контекста системы представляла бы собой один прямоугольник с надписью «сервисная шина предприятия», «связующее ПО», «коммуникационное связующее ПО» или «микрослужбы» с десятками стрелок, расходящихся во все стороны. Не слишком полезно, не правда ли? Контейнерная диаграмма более удобна, но термин «контейнер» настолько перегружен различными смыслами («контейнер виртуальной машины», «контейнер приложения», «контейнер докера»), что ценность его использования в коммуникативных целях невелика. Диаграммы компонентов и классов также не являются хорошим выбором, поскольку каналы и фильтры основаны на шаблонах интеграции предприятия, а не на классах и пакетах.

Возникает вопрос: какие же диаграммы использовать? Я использую три типа диаграмм, которые обозначаются аббревиатурой SSD (хотя она звучит не так здорово, как C4): контекста системы (system context), структуры службы (service design) и развертывания (deployment).

Диаграмма контекста системы

На этой модели отображаются все службы (как SOA, так и микрослужбы) со входами и выходами. Как правило, внешние системы располагаются в верхней части модели, службы — в середине, а внутренние службы — в нижней части. Иногда внутренние и внешние службы располагаются частично над промежуточным уровнем, а частично и под ним, как показано на рисунке ниже. Рядом со стрелками также полезно (хотя и необязательно) указывать протоколы (например, HTTP, JMS, файловый) и форматы данных (XML, JSON, CSV). Если количество служб велико, то протоколы и форматы данных можно указывать на диаграммах уровня служб. С помощью стрелок я показываю службы, инициирующие запросы, а не направления потоков данных.


Диаграмма контекста системы

Эта диаграмма дает хорошее общее представление о структуре распределенной системы: ее службах, внутренних и внешних связях, типах взаимодействий (с протоколами и форматами данных) и их инициаторах.

Диаграмма структуры службы

Эта диаграмма показывает, что происходит в каждом из прямоугольников, соответствующих связующим службам на диаграмме контекста системы. Для создания этой диаграммы рекомендуется использовать EIP-значки и соединять их между собой потоками сообщений. Служба может иметь множество потоков данных, поддерживать различные протоколы, а также реализовывать механизмы реального времени и пакетной обработки.


Диаграмма структуры службы

Диаграмма развертывания

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



Диаграмма развертывания

Диаграмма развертывания показывает, как отдельные службы и система в целом относятся к узлам (физическим и виртуальным).

Советы по выбору инструментов

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

• Mac OS: OmniGraffle со значками graffletopia. С помощью этого инструмента я создал все диаграммы для книги Шаблоны проектирования Camel (Camel Design Patterns);
• Windows: Enterprise Architect компании Sparx Systems с EIP-значками Харальда Вестфала. Кроме того, здесь находятся шаблоны MS Visio;
• • Интернет: LucidCharts, в состав которого по умолчанию включены EIP-значки. Этот инструмент наиболее прост в использовании и доступен в любом месте.

Кроме того, имеется ряд других средств разработки, с помощью которых можно создавать EIP-диаграммы:

• Red Hat JBoss Developer Studio;
• EIP Designer компании Sirius;
• Talend Open Studio для ESB;
• Hawtio, подключаемый модуль для Camel, который может отображать выполняемые маршруты Camel в виде EIP-диаграмм.

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

ИТ-специалисты умеют находить себе задачи, занимающие все их рабочее время. Я уверен, что если бы у нас было больше времени, то мы бы придумали еще десяток полезных представлений, однако без этих трех мы не смогли бы описать приложение для интеграции. Как когда-то сказал Антуан де Сент-Экзюпери: «Совершенство достигается не тогда, когда нечего добавить, а тогда, когда нечего убрать».