天下武功，唯”拆“不破之架构篇二 | 技术人应知的创新思维模型 (9)

随着业务的发展、用户量、业务量发生 10 倍速变化，对于企业而言意味着破局点已经到来，对于系统架构师而言往往意味着架构需要正确拆解、快速扩展；前文我们谈了谈架构拆解的时机、架构拆解的角度与尺度；本文我们将继续谈谈架构拆解(拆分)的方法论; 关于架构拆解的方法论，不得不提及广为人知的《The Art of Scalability》即《可扩展艺术》这本书，在这本书中，作者给出了一个系统性的拆解模型：AKF 扩展立方体模型。

下面我们来简单聊聊 AKF 扩展立方体模型，如图所示 AKF 模型包括 X、Y、Z 轴三个拆解方向，对应下列三种常见架构拆解、扩展策略:

1. 服务的水平复制 X 轴

这里的服务是一个广义服务概念，通常它即可能是一个独立的单体应用、也有可能是一个独立的“微服务”；这里我们统称为”服务“。

服务的水平复制直白来说，是通过冗余、多部署几个相同的应用/服务实例，应对线上业务流量的增长；部署之后即是做流量的负载均衡；比如对于单体架构，通过 Nginx 等网关做接入负载均衡；对于微服务架构，常见的方式是通过 Ribbon 集合 Eureka、Nacos 等做服务调用负载均衡。

这里需要关注的是，一方面，为了让服务可以快速的进行低成本、无代码改造的水平复制、快速扩容，需要我们在设计服务时，提前考虑服务的无状态化设计，比如 session 数据的存储设计考虑，对于用户 session 数据常见策略是存储在外部 Redis 集群中；另一方面，应用如果无状态，可以快速扩容，并不意味着无限扩容，限制同样明显，如早期数据存储往往依然是集中的单库，系统的性能边界往往是在数据层。

X 轴复制示意图

1. 基于业务的垂直拆分 Y 轴

垂直拆分服务之前，一方面要明确为什么要拆分，明确服务拆分的目标；另一方面需要考虑众多不同角度，比如团队的角度，包括团队的组织架构、团队的技术体系、团队的技术能力等；业务的角度，包括核心业务与非核心业务、确定性业务与不确定性业务、高并发读业务与高并发写业务、高安全性业务与一般安全性要求业务等等；这两个方面分别对应着做正确的事与把正确的事做对。

举个例子，商城系统早期为单体应用，因用户量的增加、需求的爆发、业务的不断发展，需要拆分为业务职责更内聚的服务，其中为了保障用户的下单流程尤其需要将商品业务、订单业务从原有系统中拆分开来。

Y 轴拆分示意图

另外拆分时，同样应遵循一些我们已知的原则，比如”高内聚低耦合“、让服务”小而自制“、”可独立部署“、”避免循环依赖“等等相关原则。

1. 基于相似度的数据划分 Z 轴

数据的分区、数据的划分，往往与 Y 轴-业务的拆分相关联；Y 轴的拆分决定了 Z 轴的业务数据域；如上图所示原先所有数据均存储于同一单体应用数据库中，但伴随 Y 轴的拆分，数据库同样常常会伴随分库而垂直拆分为用户库、商品库、订单库等。

当业务并发、数据量持续增长，基于不同业务场景的考虑，业务数据必然需要按不同的维度做进一步的水平或垂直划分，如基于数据冷热程度、基于读写热度、基于数据范围 包括地区维度、时间维度、ID Range 、基于用户 ID 的”基因维度“即所有用户所产生的业务数据后加上用户 ID 的后 4 个 BIT 等等

1. 最后

如前文所述，架构演进是不断反熵增与提升需求响应力的发展过程，架构的拆分历程，无疑需以提升需求响应力、不断反熵增、降本增效为最高纲领；在做架构拆分时更是要清楚拆分一定不是完全没有副作用，特别是不能为了拆而拆，”是药即有三分毒“，架构拆分同样如此，拆分同样会伴随一些新的成本包括但不限于分布式事务处理、分布式 ID 分配、服务间通信、调用链路跟踪、响应时间延迟等等。

拆解一定要控制住自己，聚焦价值，适度折中；一流的架构拆分，一定是以为了快速响应业务需求、快速验证业务模式、高效支撑业务的发展为目标。