电商平台
使用场景: 为在线商店设计服务边界的后端工程师
客户端 → API 网关
网关路由到用户、商品、购物车、订单、支付服务
订单服务向 Kafka 发送 OrderCreated 事件
库存服务异步锁定库存
通知服务在订单确认后发送邮件/短信
每个核心服务拥有自己的数据库
这样组织的原因: 图中最重要的边界是：订单、支付和库存不应该共享同一个数据库。服务自治依赖数据归属，而不只是代码仓库拆开。
真实案例
SaaS 协作产品
使用场景: 正在从单体拆分领域服务的工程团队
Workspace Service 拥有团队、成员和权限
Document Service 拥有文档和版本历史
Comment Service 处理线程评论
Realtime Gateway 管理 WebSocket 连接
事件总线分发文档更新和通知
这样组织的原因: 协作产品通常同时有同步请求和实时事件。把两条路径都画出来，能帮助评审者判断哪些更新需要强一致，哪些可以最终一致。
通知平台
使用场景: 构建通用通知基础设施的平台团队
生产者服务 → Notification API
Notification API 校验模板和用户偏好
Kafka Topic 分发到邮件、短信、推送 Worker
送达回执写入 Delivery Store
管理后台读取送达状态和失败原因
这样组织的原因: 通知平台是很典型的微服务例子，因为生产者服务不应该知道每个送达渠道如何实现。架构图能清晰展示这种解耦。
单体到微服务迁移
使用场景: 规划渐进式架构迁移的技术负责人
单体仍然位于 API Gateway 后方
先抽取 Auth Service，明确 token 边界
再抽取读多写少的 Catalog Service
过渡期间用事件同步数据
只有在流量迁移完成后才下线单体模块
这样组织的原因: 迁移图应该展示临时的混合状态。团队只画最终架构而忽略过渡路径时，最容易低估迁移风险。
画好微服务架构图的技巧
- 明确画出数据归属；共享数据库通常意味着服务并不真正独立。
- 用虚线或不同颜色表示异步事件，避免和请求/响应调用混淆。
- 把网关、队列、缓存、数据库等基础设施和业务服务分组区分。
- 第一张图保持高层抽象；具体工作流再用序列图补充。
相关资源
和相似工具的对比
微服务架构图 vs 单体架构图
单体架构图画的是一个部署单元内部的分层（控制器、服务、仓储）。微服务架构图画的是可独立部署的单元以及它们之间的网络。最关键的区别是：微服务图上每一条线都是一个潜在故障点，所以延迟和重试策略属于图上应该表达的信息。
服务图 vs 部署图
服务图回答「有哪些逻辑边界、谁负责什么」；部署图回答「实际跑在哪——哪个集群、哪个地域、几个实例」。很多团队试图把两者合并，结果得到一张过于拥挤、两个用途都没服务好的图。建议分开画。
同步调用 vs 事件流
把 REST 调用和异步事件画成同一种线，是微服务图里最常见的混淆来源。同步调用意味着调用方会阻塞、并承担被调方的故障；事件意味着发出即不管、最终一致。必须用明显不同的线型区分，否则这张图会主动向读者传递错误的耦合信息。
自由画的微服务图 vs C4 模型
C4 规定了四个固定的缩放层级（上下文、容器、组件、代码），在多团队之间统一表达时很好用。而针对某个具体讨论临时画的图更快、更贴题。如果你这周只想说清一个问题，没必要为此引入一整套框架。
常见误区
多个服务共用一个数据库
如果两个服务读写同一批表，它们就不是可独立部署的——你得到的是一个分布式单体。把这件事诚实地画出来是有价值的：耦合可见了，团队才能决定是接受还是改造。用两个恰好指向同一实例的数据库图标把它藏起来，问题就会一直存在。
只画正常路径，不画故障和重试
只有happy path 箭头的图，暗示「所有服务都活着时系统就能工作」——而这从来不是需要讨论的情况。请在确实有超时、重试、熔断、降级的调用上标注出来，并且把**缺失**这些保护的调用也标出来，后者往往才是评审重点。
服务拆得过细
画三十个方框、每个只连一条箭头，看起来拆分得很彻底，但没有向读者传递任何关于边界的信息。先按业务能力分组；如果一组服务总是一起部署、一起挂，就把它们画成一个方框加注释，因为在运维意义上它们本来就是一个东西。
漏掉 API 网关和认证边界
认证在哪一层发生，决定了整个安全模型。如果图上看不出某个服务是公网可达、还是只能通过网关访问，安全评审就没法用这张图——而安全评审恰恰是这类图的主要读者之一。
常见问题
画图之前怎么确定服务边界？+
按数据归属划边界，而不是按代码写起来方便划。每个服务应当拥有自己的数据，并且只通过 API 对外暴露。画图时有个很实用的检验方法：如果一个服务无法在不同时部署另一个服务的情况下上线，那这个边界就划错了，图上应该把它们合并画成一个。
图上要画出每个服务的数据库吗？+
要。数据归属是微服务的定义性特征，藏起来等于删掉了最重要的信息。给每个服务画自己的存储图标；如果确实有几个服务共用一个，就把这个共享依赖显式画出来，而不是悄悄复制一个相同的图标了事。
异步消息和事件总线怎么画？+
把消息中间件（Kafka、RabbitMQ、SQS）画成一个独立元素，而不是画成一条线，然后生产者连进去、消费者连出来。这很重要，因为中间件的作用正是解耦两端：生产者并不知道自己的消费者是谁。直接从生产者连到消费者的箭头，会暗示一种实际不存在的耦合。
给新人 onboarding 用的图应该画多细？+
对新人来说，保留服务、各自的存储、网关，以及两三条最重要的调用链就够了——最好顺着一个真实用户请求把链路标出来。完整清单式的图会让新人无从下手；而顺着一个请求走一遍，能让他更快建立架构的整体认知。
这张图应该多久更新一次？+
把更新绑定到服务边界变化，而不是代码变化。加一个接口不影响这张图；拆分服务、引入消息中间件、改变某个存储的归属，才需要更新。图上标一个「最后确认日期」，读者就知道该给它多少信任度。
在线开始编辑
回到模板页，替换成你自己的内容，就可以继续使用这套结构。
使用这个模板： /editor/new?template=microservices
使用这个微服务架构模板