Микросервисы

Вообще говоря, существует два варианта построения диаграмм микросервисов при использовании модели C4, хотя это зависит от того, что вы подразумеваете под “микросервисом”. Имея это в виду, давайте начнем с самого начала.

Этап 1 - монолитный архитектурный стиль

Представьте, что мы работаем в небольшой начинающей компании, испытывающей нехватку средств, и наша задача - создать программную систему (названую “X”), которая предоставляет нашим клиентам бизнес-возможности A, B и C. Контекстная диаграмма нашей системы может выглядеть следующим образом:

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

Этап 2 - архитектурный стиль микросервисов

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

Чтобы ответить на этот вопрос, мы обратимся к Микросервисам, написанным Джеймсом Льюисом и Мартином Фаулером:

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

Чтобы привести это в соответствие с моделью C4, давайте заменим “приложение” на “программную систему”:

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

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

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

Поскольку мы по-прежнему являемся единой командой инженеров, переход на архитектуру микросервисов - это деталь реализации, которая очевидна только внутри команды. Вот почему все семь контейнеров показаны внутри границы программной системы, причем каждый “микросервис” представляет собой комбинацию контейнера API (шестиугольника) и контейнера схемы базы данных (цилиндра). В результате вы заметите, что на этой диаграмме контейнеров микросервисы не отображаются в виде явных полей. Вместо этого в этой версии диаграммы используется цветовое кодирование, чтобы показать взаимосвязь между парами API и базы данных контейнеры схемы. Если вы хотите более подробно описать это сопряжение, вы можете обвести каждую пару рамкой, чтобы показать, что они сгруппированы вместе.

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

И если бы эта новая бизнес-возможность была реализована с помощью нового микросервиса, который представляет собой всего лишь один AWS lambda без сохранения состояния, пересмотренная схема контейнера выглядела бы следующим образом:

Этап 3 - Закон Конвея

По мере того как наша компания растет и переходит от стартапа к масштабированию, мы начинаем искать способы оптимизации доставки и решаем обратиться к [закону Конвея] (https://en.wikipedia.org/wiki/Conway%27s_law) как к способу достижения этой цели. Таким образом, мы решили разделить нашу единую инженерную команду на несколько команд, в результате чего каждый микросервис будет принадлежать отдельной команде:

Команда X: владеет программной системой X, предоставляющей пользовательский интерфейс, связанный с бизнес-возможностями A, B, C и D.
Команда А: владеет службой А.
Команда B: владеет службой B.
Команда C: владеет службой C.
Команда D: владеет службой D.

Теперь мы можем использовать модель C4, чтобы взглянуть на каждую программную систему с точки зрения команды, которой она принадлежит, при этом каждая услуга “продвигается” из пары контейнеров в программную систему. Схема системного контекста для Команды X теперь выглядит следующим образом:

Команда X сохранила только монолитный пользовательский интерфейс, поэтому пересмотренная схема контейнера для программной системы X выглядит следующим образом:

И с точки зрения команды А, схема системного контекста для службы А выглядит следующим образом:

А схема контейнера для сервиса A выглядит следующим образом:

Резюме

Подход к построению диаграммы архитектурного стиля микросервисов зависит от того, кому принадлежат отдельные сервисы, и от того, рассматриваете ли вы их как детали реализации в рамках единой программной системы или как отдельные программные системы, которые принадлежат (или могли бы принадлежать) отдельным командам.