电商平台
使用场景: 为在线商店设计服务边界的后端工程师
客户端 → 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
过渡期间用事件同步数据
只有在流量迁移完成后才下线单体模块
这样组织的原因: 迁移图应该展示临时的混合状态。团队只画最终架构而忽略过渡路径时，最容易低估迁移风险。
使用技巧
- 明确画出数据归属；共享数据库通常意味着服务并不真正独立。
- 用虚线或不同颜色表示异步事件，避免和请求/响应调用混淆。
- 把网关、队列、缓存、数据库等基础设施和业务服务分组区分。
- 第一张图保持高层抽象；具体工作流再用序列图补充。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=microservices
使用这个微服务架构模板