Диаграмма архитектуры предоставляет структурированный чертеж, используемый системными архитекторами и командами DevOps для визуализации конфигураций инфраструктуры, облачных микросервисов и структурных макетов. Построена на основе архитектура-бетадвигателя, этот текстовый инструмент заменяет ручные инструменты перетаскивания, автоматически размещая группу структурных сервисов, кластеры баз данных, шлюзы и краевые пути в чистые, предсказуемые макеты системы.
Базовая структура синтаксиса
Каждая диаграмма начинается с архитектура-бетазаголовка объявления. Вы заполняете холст, определяя отдельные элементы узлов с помощью ключевого слова serviceключевого слова, и отображаете треки соединений, указывая точные направляющие координатные порты (Tверх, Bниз, Lлев, Rправ) разделенные двоеточиями и двойными тире.
архитектура-бета
service шлюз(internet)[Метка шлюза]
service сервер(server)[Сервер приложения]
шлюз:B -- T:сервер
Справочник по синтаксису
В таблице ниже приведено разбиение основных компонентов данных, ключевых слов форматирования и атрибутов соединителей, используемых для создания карты рабочей области архитектуры в Mermaid.js.
| Компонент синтаксиса | Требование типа | Описание и правила использования |
|---|---|---|
| Объявление | Идентификатор ключевого слова | Инициализирует холст рабочей области карты инфраструктуры. Должно использоваться точное архитектура-бета блок. |
| Узел сервиса | Ключевое слово + Блок идентификации | Объявляет архитектурный элемент. Использует синтаксис: service id(иконка)[Метка отображения]. |
| Оболочка группы | Ключевое слово контейнера | Группирует связанные сервисы внутри визуального контейнера. Использует синтаксис: group id(иконка)[Метка группы]. |
| Ключевое слово «в» | Модификатор присвоения | Явно назначает узел сервиса находиться внутри определённой объявленной оболочки группы: service id(иконка)[Метка] в groupId. |
| Узел соединения | Идентификатор ключевого слова | Создаёт точку структурной выравнивания, используемую для аккуратного маршрутизирования сложных мульти-направленных путей соединений: junction id. |
| Края соединения | Операторы направления портов | Настраивает направление трекинговых путей, прикрепляя соединение к конкретным сторонам узла (В, Н, Л, П): source:side -- side:target. Поддерживает направляющие стрелки (-->). |
Расширенная группировка и маршрутизация краёв портов
Чтобы точно контролировать, как связи перемещаются между элементами, не создавая хаоса, архитектурный движок требует явного привязывания портов. Связанные узлы можно организовать внутри структурных групп, чтобы уточнить границы системы.
1. Правила точного привязывания портов
Вы определяете, где линия соединения покидает и входит в компонент, добавляя двоеточие и флаг направления края (“T, B, L, R) к соответствующим идентификаторам узлов:
db:R -- L:server: Линия покидает **Правую** сторону базы данных и входит в **Левую** сторону сервера в виде прямой горизонтальной линии.db:T -- L:server: Линия покидает **Верхнюю** сторону базы данных и входит в **Левую** сторону сервера, автоматически изгибаясь под чистым углом 90°.src:B --> T:proc: Линия покидает **Нижнюю** сторону исходного узла и направляется вниз к **Верхней** стороне процессора с направляющим концом стрелки.
2. Структурирование систем с помощью групп
Чтобы объявить визуальную группу (например, виртуальную частную сеть или кластер баз данных), используйте ключевое слово group и присвойте узлы ей с помощью модификатора in модификатора:
architecture-beta
group cloudNetwork(cloud)[Частная облачная сеть]
service auth(server)[Узел аутентификации] в cloudNetwork
service api(server)[Точки доступа API] в cloudNetwork
Выравнивание элементов-сестер (v11.16.0+)
Когда несколько различных служб используют идентичные маршруты обхода краев (например, три независимых источника данных, передающих данные в один обработчик сообщений), алгоритм компоновки иногда объединяет их вместе. Ключевое слово align row и выравнивание по столбцу директивы заставляют движок равномерно распределять эти элементы-потомки по конкретной осевой линии.
архитектура-бета
служба src1(server)[Источник 1]
служба src2(server)[Источник 2]
служба proc(server)[Центр обработки]
src1:B --> T:proc
src2:B --> T:proc
выравнивание по строке src1 src2
Реальный чертеж: чертеж кластера микросервисов
Этот чертеж демонстрирует высоконадежную архитектуру облачных решений для корпоративного уровня. Центрируя основной движок API и ветвя аутентификацию и асинхронные задачи горизонтально по обе стороны, компоновка использует принципы симметричного дизайна для предотвращения пересечения линий. Весь поток данных предсказуемо движется вниз от публичного шлюза в чётко выровненный слой хранения данных, используя двойной выравнивание по строке директивы для фиксации компонентов в чётких, предсказуемых горизонтальных дорожках.
архитектура-бета
заголовок "Архитектура микросервисов с высокой доступностью"
%% Уровень внешнего входа
служба cloudflare(internet)[WAF Cloudflare]
служба alb(server)[Балансировщик нагрузки AWS Application]
%% Кластер основного приложения
группа appCluster(cloud)[Управляемые микросервисы EKS]
служба authService(server)[Сервис аутентификации] в appCluster
служба apiService(server)[Основной движок API] в appCluster
служба workerNode(server)[Рабочий узел асинхронных задач] в appCluster
%% Уровень защищенного хранения данных
группа dataCluster(database)[Защищенный слой данных]
служба redis(disk)[Кластер кэша Redis] в dataCluster
служба postgres(database)[Основной PostgreSQL] в dataCluster
%% 1. Вертикальный поток: вход трафика с публичного уровня в вычислительный центр
cloudflare:B --> T:alb
alb:B --> T:apiService
%% 2. Горизонтальный поток: основной API ветвится симметрично влево и вправо
apiService:L --> R:authService
apiService:R --> L:workerNode
%% 3. Базовый поток: рабочие приложений опускаются прямо в соответствующие слоты данных
authService:B --> T:redis
workerNode:B --> T:postgres
%% Выравнивание осей компоновки для идеальной сетки
выравнивание по строке authService apiService workerNode
выравнивание по строке redis postgres
Распространённые ошибки синтаксиса и системные ограничения
При написании кода инфраструктуры имейте в виду эти конкретные правила проверки конфигурации, чтобы избежать ошибок парсинга:
- Последовательность скобок метки:Строки отображаемого текста должны использовать квадратные скобки
[Текст метки]и следуют непосредственно за скобками иконки без пробелов:служба id(server)[Текст]является правильным. Использование кавычек внутри скобок нарушит работу парсера. - Регистр символов порта: Якоря портов соединительных линий должны быть написаны заглавными буквами (
T,B,L,R). Нижний регистр букв (t,b,l,r) не распознаются и приведут к сбоям при генерации макета. - Правило предварительного объявления: Каждый идентификатор узла или соединения, используемый внутри оператора пути ребра, должен быть явно объявлен на отдельной строке выше его. Подключение к неявному имени узла не будет выполнено.
- Ограничения членов выравнивания: При использовании
align rowилиalign columnдирективы позиционирования, вы должны указать как минимум два или более действительных ранее объявленных идентификатора службы или соединения в командной строке.