微服务架构图解——许多小服务组成一个系统

微服务架构图解——许多小服务组成一个系统

The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

How to read this visual

• 先自上而下读左边这一列：客户端到网关，再到服务——这就是请求路径。
• 再顺着每个服务发出的箭头看：通向消息总线，通向它自己的数据库，通向可观测性。
• 右侧几条带是这套系统的共享基础设施——消息通信、数据与可观测性——所以每个服务都指向它们。

请求路径

“Web 与移动客户端”开启整个流程，“API 网关负责路由与聚合”是唯一入口——它把每个请求路由到正确的服务，处理身份认证，并常常把多个服务的响应组装成一个。网关是每个客户端唯一看得见的组件，所以它位于客户端层与服务之间。

服务本身

“订单服务”、“用户服务”与“支付服务”是独立部署的单元。每一个都由自己的团队负责，按自己的节奏发布。图上把每个服务连到消息总线——服务之间靠事件而不是直接调用来通信——也连到它自己的数据库，因为拥有自己的数据正是一个服务能够独立部署的原因。

共享基础设施

“消息总线让服务解耦”让一个服务可以发布事件，而不必知道谁在消费。“每个服务拥有自己的数据库”是那条防止共享状态耦合的规则。“指标、日志与链路追踪汇入同一个视图”则是让一套多服务系统在运维上说得通的可观测性——没有它，跨越边界的故障根本看不见。这三条带既是这套架构的代价，也是它的回报。

Key relationships and takeaways

• 每个服务都可以独立部署——架构里其他一切的存在，都是为了保护这条性质。
• 服务之间通过消息总线通信，并各自拥有自己的数据库；共享状态是反模式。
• API 网关是这套系统唯一的前门；客户端从不直接和服务对话。
• 独立必须用可观测性来换——许多服务只有在一个视图覆盖全部时才管得住。
• 微服务编排的正是 Docker 打包出来的容器——这两张图解是连着的。

When to use this visual

• 在团队采用微服务之前，讲清楚微服务为什么存在、真正的取舍又是什么。
• 为新人上手记录现有系统的服务边界、消息主题与数据归属。
• 排查反模式：一个共享数据库，或者一个服务直接调用另一个服务，都是边界泄漏。

运作方式

1. 把服务改成你自己的系统

   把订单、用户和支付换成你实际的服务，再补上这三个通用服务没覆盖到的，每一个都作为“服务”条带里的一个方框。

2. 写出你的消息主题

   在消息总线上标注你的服务实际发布和订阅的事件，让解耦成为具体的东西，而不只是一句断言。

3. 画出数据归属

   在每个服务通往数据库的连线上，注明真实的存储（PostgreSQL、一个缓存、一个搜索索引）以及它归谁所有，用来检查一个服务一个数据库这条规则是否成立。

4. 补上故障与扩缩容分支

   插入真实的路径——某个服务在总线上的重试与熔断、某个热点服务扩出的副本——每一条都以一个明确的状态收尾。

常见问题

什么是微服务架构？

它是一种架构风格：应用由许多小服务构成，每个服务负责一项业务能力，独立部署并拥有自己的数据。服务之间通过网络通信——通常是 HTTP 加一条消息总线——而不是共享内存或数据库。好处是可以独立部署、团队自治；代价是网络复杂度，以及对可观测性的需求。

为什么每个微服务都要拥有自己的数据库？

因为共享数据正是那种会破坏独立部署的耦合。如果两个服务读写同一张表，它们就无法在不互相协调的情况下修改表结构、扩缩容或部署。拥有自己的数据存储，才让一个服务能按自己的节奏演进和扩展——这正是图中“每个服务拥有自己的数据库”这一条带所强制的规则。

API 网关在微服务里扮演什么角色？

网关是整套系统的唯一入口。它把请求路由到正确的服务，处理身份认证、限流这类横切关注点，还能把多个服务的响应聚合成一个。客户端只和网关对话，从不直接找单个服务，这样网关背后的服务拓扑就可以自由变化。

什么时候不该用微服务？

当系统很小，或者团队很小的时候。微服务是用架构复杂度——网络故障、分布式事务、可观测性——去换独立部署能力，而这笔交换只有在团队大到独立部署成为约束瓶颈时才划算。很多团队的问题，一个模块划分良好的单体应用就能解决，那正是单体架构那张图解讲的内容。

在 QueryChart（FlowJam）中编辑这张图解

把上面这张微服务画布原样打开成你自己的图表，把服务改成你系统里的名字，画出你真实的边界。

在 QueryChart（FlowJam）中编辑这张图解