Представляем новую сквозную архитектурную диаграмму: Критический путь

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

Около года назад я написал статью о 5 типах архитектурных диаграмм, в которой описал многие из диаграмм, которые мы используем сегодня. В нем рассказывается о том, как и почему следует создавать такие диаграммы, как диаграммы потоков, сервисов, персон, инфраструктуры и разработчиков.

Они в значительной степени соответствуют модели c4 для диаграмм архитектуры программного обеспечения. Есть нюансные различия, и обе они помогают по-разному донести важную информацию о вашем приложении.

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

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

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

Мне нужна была диаграмма критического пути.

Обзор

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

Пример диаграммы критического пути

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

Аудитория

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

Соображения

На диаграмме критического пути не обязательно указывать все детали для каждого API. Вы должны обобщить и сгруппировать похожие конечные точки вместе. Если у вас есть набор конечных точек, которые технически следуют одному и тому же потоку (например, API Gateway to Lambda to DynamoDB to DynamoDB streams), вы можете включить эту схему один раз.

Потоки данных

Говоря о потоках данных, я имею в виду путь, который проходит бизнес-процесс через вашу систему. Если мы возьмем пример из Gopher Holes Unlimited, мы увидим, что происходит, когда в систему добавляется новый суслик.

Поток данных для добавления нового суслика

Компоненты

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

В нашем примере инициатор потока данных начинается с взаимодействия пользовательского интерфейса Add New Gopher. Для этого бизнес-процесса взаимодействие представляет собой мастер пользовательского интерфейса, который проводит пользователя через добавление всех необходимых элементов данных для суслика. Когда мы прослеживаем стрелки, мы начинаем со звезды.

Поток использует механизм поиска для поиска существующих сусликов. Эта конечная точка поиска использует AppSync для поиска сусликов из DynamoDB, вспомогательной функции Lambda и путем вызова API в Национальном реестре грызунов.

После отправки данных они проходят через основной поток ввода данных, который идет через API Gateway к DynamoDB к потокам DynamoDB к пошаговым функциям (эта схема описана в этом посте).

После завершения темы SNS публикуют сообщение, которое подхватывается Zapier для передачи данных сторонним приложениям Varmint Hunters Collective и Small Animal Preservation Society. Он также публикует данные в Национальный реестр грызунов, который получает данные через ALB поверх парка EC2 с автоматическим масштабированием.

Как только данные попадают к интеграторам через SNS, наш поток данных готов. Проследив стрелки, мы видим, что четыре системы обновляются при добавлении нового суслика. Похоже, это важный поток данных!

Этот бизнес-процесс — прекрасный пример того, почему диаграмма критического пути важна. Она позволяет увидеть самые важные потоки данных. Или самые хрупкие. Или самые загруженные. Построение диаграммы критического пути покажет вам каждую службу, через которую проходят данные, что облегчит изоляцию проблемных областей до того, как они станут проблемой.

Сделайте ее интерактивной

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

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

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

Я рисую все свои диаграммы в бесплатном приложении под названием diagrams.net (ранее draw.io). При построении диаграмм критического пути я помещаю каждый поток данных в отдельный слой. Затем я добавляю в ключ кнопки, переключающие видимость слоя, что позволяет легко показывать/скрывать целые потоки.

Ключ диаграммы критического пути

Эти кнопки находятся в ключе, поэтому они собраны в одном месте. Потребители диаграммы могут нажать кнопку, чтобы скрыть все линии потока данных, или нажать ее снова, чтобы вернуть обратно. Diagrams.net предлагает полное пошаговое руководство о том, как создавать слои и делать кнопки, которые их показывают и скрывают.

Чтобы посмотреть интерактивную версию диаграммы критического пути Gopher Holes Unlimited, нажмите здесь.

Случаи использования

Существует несколько вариантов использования диаграммы критического пути.

  • Системная диаграмма — Перечисляет все приложения, участвующие в вашей экосистеме, и то, как они связаны между собой.
  • Планирование на случай катастрофы — Определяет потенциальные узкие места и области с большим радиусом поражения в случае катастрофы.
  • Architecture Diagram Lite — Показывает типы архитектур в игре. Gopher Holes Unlimited — это бессерверное приложение, National Rodent Registry — контейнерное приложение с автоматическим масштабированием ec2 и т.д..

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

Вы не сможете собрать головоломку без всех частей.

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

Вам нужен последний уровень детализации. Вам нужны нюансы более подробных диаграмм, чтобы показать зависимости или специфику взаимосвязей. Диаграмма инфраструктуры обеспечивает детализацию, если она вам нужна, когда вы прорабатываете сценарии катастроф. В модели C4 это уровень 4 (Код).

Заключительные мысли

Диаграмма критического пути — это отличный инструмент, который нужно держать в своем заднем кармане. Это «агрегированная» диаграмма, то есть она объединяет важные фрагменты нескольких других типов диаграмм в одну.

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

Эта диаграмма не заменит другие в вашем инструментарии, но ее следует использовать в качестве дополнения и отправной точки при построении системных диаграмм.

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

Попробуйте, дайте мне знать, что вы думаете, и поделитесь тем, что вы построили!

Счастливого кодинга!

Оцените статью
Procodings.ru
Добавить комментарий