微服务架构图解——许多小服务组成一个系统 · 思维导图
微服务架构图解——许多小服务组成一个系统. 可编辑的思维导图，以彩色分支、子主题和曲线连接呈现想法。 曲线表示联系；只有方向重要时才使用箭头。
微服务是一种架构风格：应用由许多小而独立部署的服务构成，每个服务拥有自己的数据，彼此通过 API 网关和消息通信来协调，而不是靠共享状态。
微服务架构图解——许多小服务组成一个系统 · 思维导图
The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
如何阅读这张思维导图
- 从中心主题开始，沿着彩色分支探索相关想法。
- 曲线表示联系；只有方向重要时才使用箭头。
Clients & gateway
这一分支汇集 “Web and mobile clients”, “The gateway is the single entry point: it routes each request to the right service, handles authentication and often aggregates responses from several services.”.
Independent services
这一分支汇集 “Orders service”, “Payments service”, “Teams deploy and scale services independently”, “Users service”.
Messaging
这一分支汇集 “Services communicate by publishing events rather than calling each other directly — so one service's change or outage never blocks another.”.
Owned data
这一分支汇集 “The defining rule of microservices: no shared schema. Each service's data is private to it, which is what allows teams to deploy independently.”.
Observability
这一分支汇集 “Metrics, logs and traces feed one view”.
跨分支联系
每个服务都可以独立部署——架构里其他一切的存在，都是为了保护这条性质。
服务之间通过消息总线通信，并各自拥有自己的数据库；共享状态是反模式。
API 网关是这套系统唯一的前门；客户端从不直接和服务对话。
独立必须用可观测性来换——许多服务只有在一个视图覆盖全部时才管得住。
微服务编排的正是 Docker 打包出来的容器——这两张图解是连着的。
Key relationships and takeaways
- 每个服务都可以独立部署——架构里其他一切的存在，都是为了保护这条性质。
- 服务之间通过消息总线通信，并各自拥有自己的数据库；共享状态是反模式。
- API 网关是这套系统唯一的前门；客户端从不直接和服务对话。
- 独立必须用可观测性来换——许多服务只有在一个视图覆盖全部时才管得住。
- 微服务编排的正是 Docker 打包出来的容器——这两张图解是连着的。
When to use this visual
- 在团队采用微服务之前，讲清楚微服务为什么存在、真正的取舍又是什么。
- 为新人上手记录现有系统的服务边界、消息主题与数据归属。
- 排查反模式：一个共享数据库，或者一个服务直接调用另一个服务，都是边界泄漏。
运作方式
调整中心主题
根据项目或课程修改中心主题的名称。
扩展分支
编辑想法并添加示例或注释。
连接相关想法
绘制跨分支连接；只有方向重要时才使用箭头。
常见问题
什么是微服务架构？
它是一种架构风格：应用由许多小服务构成，每个服务负责一项业务能力，独立部署并拥有自己的数据。服务之间通过网络通信——通常是 HTTP 加一条消息总线——而不是共享内存或数据库。好处是可以独立部署、团队自治；代价是网络复杂度，以及对可观测性的需求。
为什么每个微服务都要拥有自己的数据库？
因为共享数据正是那种会破坏独立部署的耦合。如果两个服务读写同一张表，它们就无法在不互相协调的情况下修改表结构、扩缩容或部署。拥有自己的数据存储，才让一个服务能按自己的节奏演进和扩展——这正是图中“每个服务拥有自己的数据库”这一条带所强制的规则。
API 网关在微服务里扮演什么角色？
网关是整套系统的唯一入口。它把请求路由到正确的服务，处理身份认证、限流这类横切关注点，还能把多个服务的响应聚合成一个。客户端只和网关对话，从不直接找单个服务，这样网关背后的服务拓扑就可以自由变化。
什么时候不该用微服务？
当系统很小，或者团队很小的时候。微服务是用架构复杂度——网络故障、分布式事务、可观测性——去换独立部署能力，而这笔交换只有在团队大到独立部署成为约束瓶颈时才划算。很多团队的问题，一个模块划分良好的单体应用就能解决，那正是单体架构那张图解讲的内容。
在 QueryChart 中编辑此思维导图
在可编辑画布中打开思维导图。移动想法、添加分支并绘制连接。