三个重构案例：同为"可扩展性差"，却是不同根因

书中给出三个真实的架构重构案例，表面看有些相似，实则根因各不相同，恰好体现了”有的放矢”——必须找准真正的核心问题，而不是笼统地说”系统要重构”。案例一：后台系统M系统重构，解决不合理的耦合——M系统是管理所有游戏相关数据的后台管理系统，问题根因是耦合了P业务独有的数据和所有业务公用的数据（例如数据库某张表一部分字段是公用”游戏数据”、一部分是P业务”独有数据”，改动时代码逻辑复杂、效率很低），导致可扩展性差；重构方案是把游戏数据和业务数据拆开解耦，让两个系统能独立快速发展；重构后M系统和P业务后台系统每月上线版本数是重构前的4倍。案例二：游戏接入S系统重构，解决全局单点的可用性问题——S系统是游戏接入核心系统，一旦故障大量玩家无法登录，其数据库主库是全局单点，一旦主库不可用两个集群的写业务全部不可用，且S系统不具备多中心能力，主机房宕机整个业务就不可用；重构目标是实现双中心，任意一个机房都能提供完整服务，某机房故障时另一机房能全部接管；重构后系统可用性从3个9提升到4个9，重构前最夸张一个月发生4次较大线上故障，重构后即使经历机房交换机宕机、运营商线路故障、机柜断电等问题，对业务也没有大影响。案例三：X系统重构，解决大系统带来的开发效率问题——X系统是创新业务主系统，早期为了快速尝试和快速发展，怎么方便怎么做，很多功能都”塞”进同一个系统，导致后来改不动，做新功能要花大量时间讨论梳理各种业务逻辑；X系统的问题看起来和M系统类似（都是可扩展性不足），但根本原因不一样：M系统是耦合了不同业务的数据，X系统是把业务相关的所有功能都放在同一个系统中，而且所有功能挤在一个系统还会导致一个功能出问题、整站都跟着不可用（比如某个功能拖慢数据库，全站业务都变慢）；重构目标是把各功能拆分到不同子系统中降低单系统复杂度；重构后虽然系统间要通过接口交互、看似增加了接口工作量，但各系统的发展和开发速度比原来快了很多，也不再出现一个子系统有问题、所有业务全跟着遭殃的情况。

结构图：

flowchart TB
  A["三个案例：表面都是'可扩展性差'"]
  A --> M["M系统：业务数据与公用数据耦合<br/>→拆分解耦→上线版本数×4"]
  A --> S["S系统：数据库主库全局单点<br/>→双中心方案→可用性3个9→4个9"]
  A --> X["X系统：所有功能塞进一个系统<br/>→功能拆到不同子系统→开发速度大幅提升"]
  M -.根因不同.-> X