写文章累死了怎么办
我是一个服务，我的名字叫闪客。
我提供的服务很简单，给我一个标题，我输出一篇文章。
日复一日，年复一年。
X
但随着粉丝数的不断增多，我对文章的质量也有了更加严格的要求，所以我很容易累死，累死了就会鸽文。
为了防止这种情况发生，我使用了我的技能，分身术。
我分出了 N 多个和我一模一样的服务，平时他们不干活，但当我累死的时候，他们随时顶上来。
当然，他们也可以和我一起干活，或者帮我干一部分活，分担一下我的压力，减少我累死的概率。
这样，我通过简单的分身之术，就可以轻松驾驭几千个粉丝的需求啦。
Y
但随着粉丝数量的继续增多，我发现我即使再多分身也没用。
因为慢慢地，事情已经不仅仅是写文章就够了，文章技术答疑，广告对接等等工作。
每一个分身，不再像以前那样只处理一项工作，因此效率也降低了。
此时我不能再通过分出多个一模一样的我，来处理相同的事情，必须根据业务进行不同功能的划分。
这样，写文章的闪客，就专心写文章，技术答疑的闪客，就专心进行技术答疑，做广告的闪客，就专心数钱。
每个人的任务再次变得单一，也专注了起来，效率又上了一个台阶。
此时已经可以轻松驾驭上万个粉丝的需求啦。
Z
但又随着粉丝数量的继续增长，我发现，按功能分身也没用了，因为某个单一的功能，也变得极为复杂。
比如技术答疑，有的读者问的是职业规划，有的读者问的是技术细节，还有的读者是问我婚否饭否。
负责技术答疑的分身，已经无法再进行自身业务属性上的拆分了，但又越来越无法招架用户五花八门的问题，怎么办呢？
那就根据用户的问题继续分解我的服务！
关心技术问题的用户，通通与答疑闪 1 进行对话。
关心职场术问题的用户，通通与答疑闪 2 进行对话。
关心婚恋问题的用户，通通与答疑闪 3 进行对话。
这样，虽然这些服务都是负责答疑这个业务，但是却根据用户的不同进行划分，减少了每个服务的压力和需要处理的事情。
AKF
上面只是跟大家开个玩笑，下面要严肃一些咯。
上面的那一堆胡说八道的废话，就叫 AKF 可扩展立方体。这个概念出自《架构即未来》一书中提出的可扩展模型。
这个立方体有三个轴线 XYZ，每个轴线描述扩展性的一个维度。
让请求很均匀的分散在不同的服务实例上，就像上面我说的第一种分身方式。
当然还有更具体的。
还记不记得刚刚我说的，我可以让分身平时不工作，只是随时待命，等主身挂了再顶上来，这个叫主备模型。
当然我也可以让分身和我承担一样的工作，无差别地提供服务，这个叫主主模型。
我还可以让分身只承担部分工作，例如分身只提供读，而主身提供读写，这个叫主从模型。
Y：根据自身业务拆分
提供不同业务类型的服务，就像上面我说的第二种分身方式。
我们公司里一般按业务进行微服务的拆分，不管是垂直的还是水平的，都是这种 Y 轴的划分方式。
Z：根据用户属性或数据拆分
就像我刚刚说的第三种分身方式。
这种拆分方式一般是数据集的拆分，经典的如 Redis 的集群模式，就是按数据的哈希值进行分片。
三种方式是可以同时存在的，组合起来就是这样。
画得好丑。
万物皆可 AKF
刚刚也隐隐约约提到了，我们把这个模型试着往 Redis 里套一下，你就明白了。
Redis
单节点的 redis 很不稳定，所以有了很多保障可用性的扩展方式。
redis 中的主从模式，就是 AKF 中的 X 轴方向的扩展。
redis 中的集群模式（也就是数据分片），就是 AKF 中的 Z 轴方向的扩展。
如果你再按照业务拆分，比如用户数据访问 redis1，订单数据访问 redis2，那你其实相当于在做 AKF 中的 Y 轴方向的扩展。
这是拿中间件举例。
我们再尝试着套一下公司中的普通业务项目。
普通项目
一个项目部署好几十台机器，比如我们的 API 服务部署了 128 个节点，那这个其实就是 X 轴。
根据业务划分了很多微服务，比如有用户模块服务，订单模块服务，推荐模块服务，服务之间用 rpc 进行通信，这其实就是 Y 轴。
Z 轴一般在业务侧比较少，数据数据集的拆分方式，我们还没有这样的拆分，拿 Redis 的集群分片举例比较合适。
不过你要是说，根据用户的 IP 属性，将请求打在不同机器上，其实也算吧，没有特别严格的定义，只是一种思维方式。
总之，如果你能在架构侧拥有 AKF 的思考方式，很多中间件、业务、甚至现实生活中的组织架构和人员分配的设置，都可以站在一个更高更全面的视角去看待，这就是一个典型的架构思维。
后记