《架构即未来》

总体观点

核心观点

1. 1. AKF扩展立方体：扩展只有三个方向

   “系统怎么扩展”抽象成一个立方体：X轴水平克隆，Y轴按功能拆分，Z轴按数据拆分。任何扩展手段都能归到这三个轴上，讨论扩展有了共同语言。

   用户量涨10倍系统变慢：短期X轴加机器顶住（最快），中期Y轴拆“图片处理”成独立服务（治本）。长期Z轴按用户ID分库（根治）。三个方向清清楚楚，不再碰运气。

2. 2. X轴：水平克隆——加机器，最简单的扩展

   最简单粗暴的扩展：应用原样复制多份，前面用负载均衡分发流量。不改代码，见效最快。但有天花板：有状态的部分（数据库、文件存储）克隆不了，所以X轴通常是第一步，不是终点。

   流量翻倍，最快就是再买几台服务器装同样的程序，前面加负载均衡分流。代码一行不改，半小时搞定。但数据库还是那一个，加再多机器，瓶颈迟早卡在没法克隆的地方。

3. 3. Y轴：按功能拆分——微服务思想的老祖宗

   按功能、业务把系统拆开：不同功能拆成不同服务，各自独立扩展、独立部署。好处是资源利用率高，哪里压力大加哪里；代价是系统变复杂，服务之间要通信、要治理。

   电商网站拆成“商品浏览”“下单支付”“图片处理”三个服务：图片处理吃CPU就多配机器，商品浏览压力大就加缓存。各服务独立扩展，钱花在刀刃上——这就是“微服务”思想的老祖宗。

4. 4. Z轴：按数据拆分——分库分表的理论源头

   把数据切成互不重叠的片，分散到不同机器：按客户、按地域、按哈希切。好处是扩展性最强（理论上无限加机器）；代价是跨片查询变复杂、事务难做。数据库扩展的终极手段：分库分表。

   用户表1亿行越查越慢：按用户ID哈希分到10个库，1号库只存ID尾号1的用户。查询先算“这个用户在哪”，再去对应库查——每个库1000万行，速度回来了。

5. 5. 扩展不只是技术的事：人、流程、技术三驾马车

   见过太多“技术没问题但扩不上去”的案例，结论：扩展性是人、流程、技术三者的乘积。组织不合理（200人的大团队）、流程有瓶颈（发布层层审批），技术再好也白搭。三者一起设计。

   团队天天加班，发布还是慢：不是技术不行，是流程卡住了——每次发布五个领导审批，等两周。“流程”这条腿瘸了。技术、流程、组织三条腿，瘸一条都跑不快。

6. 6. 架构原则：为扩展而设计，而不是事后补救

   与其事后救火，不如事前设计。架构原则：无状态设计、异步解耦、缓存优先、水平扩展友好——让系统“天生就好扩展”。扩展性不是运维阶段才考虑，是画第一张架构图时就要想好的。

   设计之初就规定：应用服务器不存本地状态（登录态放Redis）。X轴加机器才无压力；耗时操作全走异步队列，Y轴拆分才顺滑。

7. 7. 先找到瓶颈再动手：度量先行，加错机器等于白花钱

   扩展第一步永远是度量：先找到瓶颈，再选对应的轴。一慢就加机器，结果瓶颈在数据库，加100台应用服务器也没用。AKF立方体的价值就是一张“排查地图”，顺着三个轴一个个排除。

   系统变慢别急着加机器。CPU满了，走X轴加机器；服务太重，走Y轴拆分；单表太大，走Z轴分片。量体裁衣、对症下药，加错方向的机器都是白花钱。

全书结构

1. 第一部分 可扩展性组织的人员配置

   可扩展性首先是人的问题；组织架构与团队自主性决定系统上限，用 RASCI 矩阵明确权责分工，打破 IT 与业务的对立思维。

   运用 RASCI 矩阵清晰界定架构师（负责人 R）、业务主管（审批人 A）与开发（支持人 S）的分工，彻底根除跨部门推诿扯皮。

2. 第二部分 构建可扩展的过程

   规范的流程是规模化扩张的倍增器：推行故障根因复盘、设立变更控制委员会（CAB）与架构审查委员会（ARB），科学规划容量预留空间。

   每周召开变更审查会议评估高风险生产变更，每次重大故障必须产出带有时间线的无指责复盘报告，沉淀防止同类故障再次发生的防御机制。

3. 第三部分 可扩展的架构方案

   核心理论“AKF 扩展立方体”：X轴水平克隆加机器、Y轴按业务功能拆服务、Z轴按客户与数据分片，构建故障隔离池与多级缓存异步架构。

   系统性能告急时，短期先用 X 轴加机器顶住，中期按 Y 轴把订单和用户拆为独立服务，长期按 Z 轴按用户 ID 哈希将数据库拆分到多个物理集群。

4. 第四部分 其他的问题和挑战

   科学权衡海量数据成本收益比，审慎评估云计算与自建数据中心时机，构建全方位立体化立体化监控大盘与多活数据中心灾备方案。

   对海量历史日志数据推行分级冷热存储策略，热数据放 SSD 高速检索，冷数据自动沉降到低成本云对象存储，大幅压降服务器运营成本。