服务拆分、分布式与控制平面

Category

server / services 子树总览。覆盖：拆分方法论（01）、服务角色（02）、控制平面（03）、发现路由协作（04）、一致性恢复重连（05）。

Definition

很多团队第一次认真面对分布式，不是因为想“架构升级”，而是因为旧系统已经撑不住现实压力了。房间服和活动服的负载曲线完全不同，跨服玩法开始上线，热点场景需要迁移，节点故障不能再靠人工救火，玩家断线重连也不能继续靠碰运气。

这时真正的问题不是“要不要微服务”，而是下面这些更具体的工程问题：

• 哪些状态必须放在一起维护，哪些状态可以拆开治理
• 哪些节点应该独立扩缩容，哪些故障必须被局部隔离
• 玩家、队伍、房间、场景在跨节点迁移时由谁调度
• 路由、发现、切流、摘流、维护态这些能力由谁统一管理
• 一条跨服务链路失败后，系统怎样恢复到可解释状态

如果这些问题没有先回答清楚，所谓“服务拆分”往往只是把单体里的复杂度改名成了网络复杂度、链路复杂度和恢复复杂度。

这一章不是按中间件名词展开，而是按系统进入分布式之后最先暴露的几类问题展开：边界如何画，角色如何分，控制平面为什么会从附属能力变成主系统，路由和发现为什么会成为核心基础设施，以及一致性、重连和恢复为什么必须从一开始就被正式设计。

Related

关系链：拆分四问（01）→ 角色（02）→ 控制平面（03）→ 路由（04）→ 一致性与恢复（05）。上游：runtime 子树（故障隔离面）；下游：glossary/07（控制平面词条）、database 树（事务一致性）、树根 server 总览。

Reference

节点清单见下节。

本章文章

• 服务拆分方法论：先判断项目为什么会被迫拆分，再看边界究竟该围绕状态、故障域还是扩缩容需求来画。
• 核心服务角色：梳理网关、账号、匹配、房间、场景、活动、排行、支付和治理层这些常见角色分别该管什么、不该管什么。
• 协调层、跨服与控制平面：解释为什么系统一旦进入多区服、多玩法和动态调度阶段，就必须把“谁来指挥节点和迁移”单独做成正式能力。
• 服务发现、路由与协作：讨论请求如何找到正确目标、绑定关系如何维护，以及服务之间怎样协作才不会把路由逻辑散落一地。
• 一致性、恢复与重连：把跨服务失败、幂等、补偿、会话恢复和玩家重连放进同一套恢复语义里看待。