微服务架构图怎么画

微服务架构图怎么画

微服务架构图应按接入、服务、治理、数据分层排布，用实线表示同步调用、虚线表示消息异步，并避免把监控组件画进主链路中央。

微服务架构比单体多了接入层、服务治理、分布式数据等组件，节点数量往往是单体的数倍。一张清楚的微服务架构图能让团队快速看懂「服务怎么调、怎么发现、怎么监控」。本指南梳理分层、组件选型对照与 AI 出图方法。

构图AI 一句话生成手绘风架构图，基于 Excalidraw 可编辑，导出 PNG / SVG / .excalidraw；内置 12 种图类型与约 25 个示例，含微服务、网关、IM 等模板。

何时需要画

• 架构升级：单体拆微服务时，先画图再动手。
• 新人 onboarding：避免「不知道系统里有哪些服务」。
• 故障复盘：定位调用链路上的瓶颈或单点。
• 容量规划：识别关键路径服务，决定扩容优先级。
• 边界争议：画清同步依赖，推动该异步的链路异步化。

核心分层

典型微服务架构分为 4–5 层：

1. 接入层：CDN、负载均衡、API 网关。
2. 服务层：业务服务（用户、订单、商品……）。
3. 治理层：服务注册发现、配置中心、链路追踪、Service Mesh。
4. 数据层：MySQL / PostgreSQL、Redis、ES、消息队列。
5. 运维层：监控、日志、告警、（可选）与 CI/CD 入口衔接。

画图顺序建议自上而下或自左而右固定一种，全团队统一，降低「同一系统多版图」成本。

常见组件

选型列在表格即可，架构图上写你们实际在用的名字，不要同时堆三种注册中心。

画图要点

• 分层画：每层浅色底区分，接入 → 服务 → 数据 → 运维。
• 同步实线、异步虚线：MQ 调用必须虚线。
• 标注协议：HTTP、gRPC、TCP。
• 治理层旁挂：注册发现、监控不要堵在主链路。
• 单向箭头优先：看不清的双向依赖拆成两条并注明方向。
• 控制数量：一页图服务盒子超过约 12 个就要拆分域或画上下文图。

手动画 vs AI 生成

微服务架构图最大痛点是节点太多，手动对齐累人。

画一张电商微服务架构图，手绘风。
分层：
- 接入层：CDN、API 网关（含鉴权、限流）。
- 服务层：用户服务、商品服务、订单服务、支付服务、库存服务、搜索服务。
- 治理层：Nacos（注册发现 + 配置中心）、SkyWalking（追踪）。
- 数据层：MySQL 主从、Redis 集群、ElasticSearch、Kafka。
- 运维层：Prometheus + Grafana、ELK。
关键调用：
- 网关 → 用户服务（鉴权）→ 路由到各业务服务。
- 订单服务通过 gRPC 调库存服务（同步扣减）。
- 订单服务发消息到 Kafka，物流与积分服务消费（异步）。
- 搜索服务订阅商品变更事件更新 ES 索引。

参考 微服务示例 与 IM 架构示例。登录有 1 次免费额度；拆分迭代期 VIP 不限制 AI 画图 便于多版对比。

行业变体

• SaaS 多租户：增加租户隔离（Schema / 行级），详见 SaaS 多租户示例。
• Service Mesh：服务旁挂 Sidecar，南北向仍经网关。
• Serverless：服务换 Function，触发器替代部分网关职责。
• 跨机房：增加同步复制 / 就近接入，标注延迟假设。

生成后建议做「可读性三剪」：剪掉未引用的中间件、剪掉重复的「DB」盒子、剪掉与本次评审无关的服务。导出 PNG 贴 Wiki，SVG 投影，.excalidraw 作为下一迭代底稿。

从单体拆分时怎么画「过渡态」

很多团队需要的不是「理想微服务终态图」，而是当前过渡态：哪些模块仍在单体、哪些已拆出、同步调用是否临时走旧接口。过渡态建议这样画：

• 用虚线框标出「遗留单体」；
• 已拆服务画在服务层正常位置；
• 临时防腐层 / 适配器单独命名，避免被当成长期业务服务；
• 在注释写清预计下线时间或里程碑。

这样新人不会把过渡依赖当成目标架构。AI 生成时也可以在 prompt 里写「订单仍在单体，库存已独立，中间经 AntiCorruption 适配器」，通常比生成完美六边形架构更有用。配合 CI/CD 指南 还能标出「哪些服务独立流水线、哪些仍随单体发布」，让架构图与发布图互相印证。

记住：微服务图的目标是降低沟通成本，不是展示中间件智商税。少画一个没用上的 Mesh，比多画一个「看起来很丰满」的空盒子更专业。

容量与稳定性讨论时，可在关键服务旁标注「有状态 / 无状态」以及是否多活，但请克制：架构图不是容量评估表。需要数字时另附表格，图只负责结构。对事件驱动味道很重的系统，不妨再出一张「仅含 Topic 与消费方」的消息拓扑，避免与同步调用图缠在一起。架构演进记录可以用「日期 + 变更摘要」附在图下方，形成轻量架构决策日志。新服务上线前，强制更新架构图再合并发布文档，能减少「代码已拆、图还是单体」这种常见失真，也让 onboarding 材料始终可信。图中服务名建议与仓库名或注册中心名保持同一套拼写，避免出现「图上叫 order，代码叫 trade-order」。

相关指南

• 前后端分离架构：微服务的前端搭档。
• DevOps CI/CD：微服务的发布链路。
• API 网关示例：接入层的细化。