Un diagramme d’architecture fournit un plan structuré utilisé par les architectes système et les équipes DevOps pour visualiser les configurations d’infrastructure, les microservices cloud et les configurations de disposition structurelle. Conçu sur le moteur architecture-beta moteur, cet outil basé sur le texte remplace les outils de glissement manuel en disposant automatiquement les groupes de services structurels, les clusters de bases de données, les passerelles et les chemins aux bords dans des dispositions système propres et prévisibles.
Structure de syntaxe de base
Chaque diagramme commence par la déclaration architecture-beta d’en-tête. Vous remplissez la toile en définissant des éléments de nœud individuels à l’aide du mot-clé service mot-clé, et établissez les trajets de connexion en précisant les ports de coordonnées directionnelles exactes (Top, Bottom, Left, Right) séparés par des deux-points et des traits doubles.
architecture-beta
service gateway(internet)[Étiquette passerelle]
service server(server)[Serveur d'application]
gateway:B -- T:server
Référence de syntaxe
Le tableau ci-dessous détaille les composants principaux de données, les mots-clés de formatage et les attributs de connecteur utilisés pour construire une carte d’espace de travail d’architecture dans Mermaid.js.
| Composant de syntaxe | Exigence de type | Description et règles d’utilisation |
|---|---|---|
| Déclaration | Identificateur de mot-clé | Initialise le canevas de l’espace de travail de cartographie de l’infrastructure. Doit utiliser exactement architecture-beta bloc. |
| Nœud de service | Mot-clé + Bloc d’identité | Déclare une entité architecturale. Utilise la syntaxe : service id(icône)[Libellé affiché]. |
| Enveloppe de groupe | Mot-clé conteneur | Regroupe des services liés à l’intérieur d’un conteneur visuel. Utilise la syntaxe : groupe id(icône)[Libellé du groupe]. |
| Mot-clé dans | Modificateur d’affectation | Affecte explicitement un nœud de service pour qu’il réside à l’intérieur d’une enveloppe de groupe déclarée spécifique : service id(icône)[Libellé] dans groupId. |
| Nœud de jonction | Identificateur de mot-clé | Établit un point central d’alignement structurel utilisé pour acheminer proprement des chemins de lien complexes et multidirectionnels : junction id. |
| Arêtes de connexion | Opérateurs de direction de port | Configure des chemins de suivi directionnels en fixant le lien à des côtés spécifiques du nœud (H, B, G, D) : source:côté -- côté:cible. Prend en charge les pointes de flèche directionnelles (-->). |
Regroupement avancé et routage des arêtes de port
Pour contrôler exactement la manière dont les liens se déplacent entre les éléments sans que cela ait l’air désordonné, le moteur d’architecture nécessite des liaisons de ports explicites. Les nœuds associés peuvent être organisés à l’intérieur de groupes structurels afin de clarifier les limites du système.
1. Règles exactes de liaison de ports
Vous définissez où une ligne de connexion sort et entre dans un composant en ajoutant deux points et un indicateur de direction d’arête (“H, B, G, D) aux identifiants respectifs des nœuds :
db:D -- G:serveur: La ligne sort par le **côté droit** de la base de données et entre par le **côté gauche** du serveur sous forme de ligne horizontale droite.db:H -- G:serveur: La ligne sort par le **haut** de la base de données et entre par le **côté gauche** du serveur, se courbant automatiquement à un angle droit net de 90°.src:B --> H:proc: La ligne sort par le **bas** du nœud source et descend vers le **haut** du processeur avec une pointe de flèche directionnelle.
2. Structurer les systèmes avec des groupes
Pour déclarer un groupe visuel (comme un cloud privé virtuel ou un cluster de base de données), utilisez le mot-clé groupe mot-clé, et attribuez des nœuds à celui-ci via le modificateur dans modificateur :
architecture-betarn groupe cloudNetwork(cloud)[Cloud privé]r
service auth(server)[Nœud d'authentification] dans cloudNetworkr
service api(server)[Points d'entrée API] dans cloudNetwork
Aligner les éléments frères (v11.16.0+)
Lorsque plusieurs services distincts partagent des itinéraires d’arêtes identiques (par exemple, trois sources de données déconnectées qui transmettent vers un seul worker de messages), l’algorithme de disposition peut parfois les regrouper. Le aligner ligne et aligner colonneles directives obligent le moteur à répartir ces éléments frères de manière égale le long d’une ligne d’axe spécifique.
architecture-beta
service src1(server)[Source 1]
service src2(server)[Source 2]
service proc(server)[Hub de traitement]
src1:B --> T:proc
src2:B --> T:proc
aligner ligne src1 src2
Schéma du monde réel : Schéma du cluster de microservices
Ce schéma illustre une architecture cloud hautement résiliente et de niveau entreprise. En centrant le moteur principal de l’API et en faisant partir horizontalement l’authentification et les tâches asynchrones de chaque côté, la disposition utilise des principes de conception symétrique pour éviter les chevauchements de lignes. Le flux complet des données se déplace de manière prévisible depuis la passerelle publique vers une couche de stockage de données proprement alignée, en utilisant un double aligner ligne directives pour verrouiller les composants sur des pistes horizontales nettes et prévisibles.
architecture-beta
title "Architecture de microservices à haute disponibilité"
%% Niveau d'entrée externe
service cloudflare(internet)[Cloudflare WAF]
service alb(server)[Équilibreur de charge d'application AWS]
%% Cluster central d'application
groupe appCluster(cloud)[Microservices gérés EKS]
service authService(server)[Service d'authentification] dans appCluster
service apiService(server)[Moteur principal de l'API] dans appCluster
service workerNode(server)[Travailleur de tâches asynchrones] dans appCluster
%% Niveau de stockage sécurisé
groupe dataCluster(database)[Couche de données protégée]
service redis(disk)[Cluster de cache Redis] dans dataCluster
service postgres(database)[PostgreSQL principal] dans dataCluster
%% 1. Flux vertical : entrée du trafic depuis le public vers le cœur de calcul
cloudflare:B --> T:alb
alb:B --> T:apiService
%% 2. Flux horizontal : l'API principale se ramifie symétriquement à gauche et à droite
apiService:L --> R:authService
apiService:R --> L:workerNode
%% 3. Flux de base : les travailleurs d'application descendent directement vers leurs emplacements respectifs de données
authService:B --> T:redis
workerNode:B --> T:postgres
%% Alignements d'axes de disposition pour une grille parfaite
aligner ligne authService apiService workerNode
aligner ligne redis postgres
Péchés courants de syntaxe et contraintes du système
Lorsque vous écrivez du code d’infrastructure, gardez à l’esprit ces règles spécifiques de validation de configuration afin d’éviter les erreurs de parsing :
- Séquence des crochets de libellé :Les chaînes de texte affichées doivent utiliser des crochets carrés
[Texte du libellé]et doivent suivre directement les parenthèses de l’icône sans espaces :service id(server)[Texte]est correct. Utiliser des guillemets à l’intérieur des parenthèses rompra le parseur. - Sensibilité à la casse des ports :Les ancres de port des arêtes de connexion doivent être écrites en majuscules (
T,B,L,R). Lettres minuscules (t,b,l,r) ne sont pas reconnues et provoqueront des plantages lors de la génération de la mise en page. - Règle de déclaration préalable : Chaque identificateur de nœud ou de jonction utilisé dans une déclaration de chemin d’arête doit être déclaré explicitement sur une ligne séparée au-dessus de celle-ci. Se connecter à un nom de nœud implicite entraînera un échec de la construction.
- Limites des membres d’alignement : Lors de l’utilisation de
align rowoualign columnles directives de positionnement, vous devez fournir au moins deux identificateurs de service ou de jonction valides et précédemment déclarés sur la ligne de commande.