Любая схема микросервисной архитектуры начинается чистой, а заканчивается клубком. Это почти закон. Вы рисуете сервисы, рисуете вызовы между ними, и уже к двадцати блокам получается нечитаемая сетка пересекающихся стрелок, которая не говорит ничего, кроме "всё сложно". Проблема не в архитектуре. Проблема в том, что диаграмма пытается показать все связи сразу, хотя читателю нужна форма: границы и то, как сервисы общаются.
Выход в том, чтобы перестать рисовать "каждый сервис вызывает каждый" и вместо этого осознанно нарисовать две вещи: границы, которые группируют сервисы, и стиль взаимодействия на каждом ребре. Сделайте это, и даже большая система останется читаемой.
Группируйте по границам сервисов, а не по сетке
Самое большое улучшение, которое можно сделать, это перестать раскладывать сервисы аккуратной сеткой и начать группировать их по границе, к которой они относятся. В терминах предметной области это ваши ограниченные контексты (bounded contexts); в терминах команд это обычно то, кто чем владеет. Заказы, Платежи, Идентификация, Каталог. Нарисуйте их как подписанные области и поместите сервисы внутрь. Внезапно у диаграммы появляется структура, и читатель может ориентироваться по областям, а не просматривать сорок одинаковых блоков.
Показывайте взаимодействие микросервисов на каждом ребре
Не все стрелки равны, и притворство, что они одинаковы, как раз и делает схемы микросервисов обманчивыми. Синхронный запрос (один сервис вызывает другой и ждёт) ведёт себя при сбоях и по задержкам совсем иначе, чем асинхронное событие (один сервис публикует, остальные реагируют когда угодно). Рисуйте их по-разному: сплошные линии для синхронных вызовов, пунктир для событий через шину или очередь. Теперь диаграмма рассказывает операционную историю. Видно, где медленный сервис вызовет каскад (сплошные цепочки) и где система развязана (пунктирные переходы).
Два вида стрелок, нарисованных по-разному, превращают клубок в карту того, где сбой распространяется, а где останавливается.
Хотя бы раз нарисуйте владение данными
Правило, которое делает микросервисы микросервисами: каждый сервис владеет своими данными. Диаграмма, на которой все сервисы делят одну базу данных, изображает распределённый монолит, хочет команда того или нет. Стоит иметь одно представление, где каждый сервис стоит рядом со своим хранилищем, потому что в тот момент, когда два сервиса указывают на одну базу, вы нашли связанность, которая потом будет болеть. Это не нужно на каждой диаграмме, но где-то это должно быть.
Добавьте общие для всех элементы
Несколько компонентов находятся вне границ и касаются всего: API-шлюз, стоящий перед всей системой, шина событий или брокер сообщений, переносящий асинхронный трафик, и, если он у вас есть, service mesh, отвечающий за взаимодействие между сервисами. Дайте им собственное место по краям диаграммы, чтобы они читались как общая инфраструктура, а не как ещё один сервис в блоке.
Не поддавайтесь желанию нарисовать всё
Неудачная схема микросервисов пытается быть полной. Полезная намеренно частична. Выберите вопрос, на который отвечает диаграмма (как проходит запрос, где асинхронные границы, какие сервисы какими данными владеют), и рисуйте только то, что на него работает. Полное, но нечитаемое никому не помогает; сфокусированное и ясное и есть вся суть.
Поддерживайте её живой
Микросервисные системы меняются быстрее почти всего, что вы стали бы рисовать: новые сервисы, новые события, удалённые зависимости. Версия, нарисованная вручную, устаревает ещё до конца спринта. Выводите скелет из источника (спецификации, манифесты сервисов или граф вызовов), перегенерируйте по мере развития и сохраняйте группировку по границам и стили рёбер как человеческий слой поверх. Тогда диаграмма успевает за системой, весь смысл которой в том, что её части меняются независимо.
Группируйте по границам, оформляйте рёбра по тому, как общаются сервисы, хотя бы раз покажите владение данными и генерируйте основу, чтобы она оставалась актуальной. Вот схема микросервисов, которая проясняет, а не пугает.