架构设计思想：AKF 拆分原则

AKF 拆分原则
业界对于可扩展的系统架构设计有一个朴素的理念,就是：
通过加机器(水平扩展)就可以解决容量和可用性问题 。( 如果一台不行那就两台) 。
我是个段子：（ 世界上没有什么事是一顿烧烤不能解决的。如果有，那就两顿 。）

这一理念在“云计算”概念疯狂流行的今天，得到了广泛的认可！对于一个规模
迅速增长的系统而言，容量和性能问题当然是首当其冲的。但是随着时间的向前，
系统规模的增长，除了面对性能与容量的问题外，还需要面对功能与模块数量上
的增长带来的系统复杂性问题以及业务的变化带来的提供差异化服务问题。而许
多系统，在架构设计时并未充分考虑到这些问题，导致系统的重构成为常态，从
而影响业务交付能力，还浪费人力财力！对此，《可扩展的艺术》一书提出了一
个更加系统的可扩展模型—— AKF 可扩展立方（Scalability Cube）。这个立方
体中沿着三个坐标轴设置分别为：X、Y、Z。

Y 轴(功能) —— 关注应用中功能划分，基于不同的业务拆分
X 轴(水平扩展) —— 关注水平扩展，也就是”加机器解决问题”，集群
Z 轴(数据分区) —— 关注服务和数据的优先级划分，如按地域划分

1.1 Y 轴( 功能)
Y 轴扩展会将庞大的整体应用拆分为多个服务。每个服务实现一组相关的功
能，如订单管理、客户管理等。在工程上常见的方案是 服务化架构(SOA) 。比
如对于一个电子商务平台，我们可以拆分成不同的服务，组成下面这样的架构：

但通过观察上图容易发现，当服务数量增多时，服务调用关系变得复杂。其实就是个RPC架构，为
系统添加一个新功能，要调用的服务数也变得不可控，由此引发了服务管理上的
混乱。所以，一般情况下，需要采用服务注册的机制形成服务网关来进行服务治
理。系统的架构将变成下图所示：

1.2 X 轴( 水平扩展)
X 轴扩展与我们前面朴素理念是一致的，通过绝对平等地复制服务与数据，
以解决容量和可用性的问题。其实就是将微服务运行多个实例，做集群加负载均
衡的模式。
为了提升单个服务的可用性和容量， 对每一个服务进行 X

1.3 Z 轴( 数据分区)
Z 轴扩展通常是指基于请求者或用户独特的需求，进行系统划分，并使得划
分出来的子系统是相互隔离但又是完整的。以生产汽车的工厂来举例：福特公司
为了发展在中国的业务，或者利用中国的廉价劳动力，在中国建立一个完整的子
工厂，与美国工厂一样，负责完整的汽车生产。这就是一种 Z 轴扩展。

1.3.1 工程领域常见的 Z 轴扩展有以下两种方案：
1.3.1.1 单元化架构
在分布式服务设计领域，一个单元（Cell）就是满足某个分区所有业务操作
的自包含闭环。如上面我们说到的 Y 轴扩展的 SOA 架构，客户端对服务端节点
的选择一般是随机的，但是，如果在此加上 Z 轴扩展，那服务节点的选择将不再
是随机的了，而是每个单元自成一体。如下图：

1.3.1.2 数据分区
为了性能数据安全上的考虑，我们将一个完整的数据集按一定的维度划分出
不同的子集。 一个分区（Shard），就是是整体数据集的一个子集（最终子集还要合成一个整体）。比如用尾
号来划分用户，那同样尾号的那部分用户就可以认为是一个分区。数据分区为一
般包括以下几种数据划分的方式：
数据类型（如：业务类型）
数据范围（如：时间段，用户 ID）
数据热度（如：用户活跃度，商品热度）
按读写分（如：商品描述，商品库存）

举例：比如滴滴打车，你在哪个城市打车，就给你展示哪个城市的司机数据分区