架构即未来--AKF 可扩展立方体

灰太狼 2022-10-20 00:53 199阅读 0赞

我是一个服务，我的名字叫闪客。

![图片][f6b2cf53d5f50bd7f1655dbc11e8ee48.png]

我提供的服务很简单，给我一个标题，我输出一篇文章, 日复一日，年复一年。

![图片][e9e125c3ddebcd928141b81472c62b17.gif]

**X**

但随着粉丝数的不断增多，我对文章的质量也有了更加严格的要求，所以我很容易累死，累死了就会鸽文。

为了防止这种情况发生，我使用了我的技能，分身术。

我分出了 N 多个和我**一模一样**的服务，平时他们**不干活**，但当我累死的时候，他们随时顶上来。

![图片][b388c720386cf6a315911d2c276b8e83.gif]

当然，他们也可以和我**一起干活**，或者帮我**干一部分活**，分担一下我的压力，减少我累死的概率。

这样，我通过简单的分身之术，就可以轻松驾驭几千个粉丝的需求啦。

![图片][42dee4b5bb5222cfae6108b39abad461.gif]

**Y**

但随着粉丝数量的继续增多，我发现我即使再多分身也没用。因为慢慢地，事情已经不仅仅是写文章就够了，文章技术答疑，广告对接等等工作。每一个分身，不再像以前那样只处理一项工作，因此效率也降低了。此时我不能再通过分出多个一模一样的我，来处理相同的事情，必须**根据业务进行不同功能的划分**。

![图片][2dbf6ba0290c32532890e2d3e6538ab7.gif]

这样，写文章的闪客，就专心写文章，技术答疑的闪客，就专心进行技术答疑，做广告的闪客，就专心数钱。每个人的任务再次变得单一，也专注了起来，效率又上了一个台阶。此时已经可以轻松驾驭上万个粉丝的需求啦。

**Y**

但又随着粉丝数量的继续增长，我发现，按功能分身也没用了，因为某个单一的功能，也变得极为复杂。比如技术答疑，有的读者问的是职业规划，有的读者问的是技术细节，还有的读者是问我婚否饭否。负责技术答疑的分身，已经无法再进行自身业务属性上的拆分了，但又越来越无法招架用户五花八门的问题，怎么办呢？

那就**根据用户的问题**继续分解我的服务！

![图片][eb2eb9889a71de458ada08a33f7c9c35.png]

关心技术问题的用户，通通与答疑闪 1 进行对话。

关心职场术问题的用户，通通与答疑闪 2 进行对话。

关心婚恋问题的用户，通通与答疑闪 3 进行对话。

这样，虽然这些服务都是负责答疑这个业务，但是却根据用户的不同进行划分，减少了每个服务的压力和需要处理的事情。

**AKF**

上面只是跟大家开个玩笑，下面要严肃一些咯。

上面的那一堆胡说八道的废话，就叫 **AKF 可扩展立方体**。这个概念出自《架构即未来》一书中提出的可扩展模型。

这个立方体有**三个轴线 XYZ**，每个轴线描述扩展性的一个维度。

**X：无差别的克隆服务和数据。**

让请求很均匀的分散在不同的服务实例上，就像上面我说的第一种分身方式。

![图片][27d4fa26ad13a8edb3cadedf75dd1215.png]

当然还有更具体的。

还记不记得刚刚我说的，我可以让分身平时不工作，只是随时待命，等主身挂了再顶上来，这个叫**主备模型**。

当然我也可以让分身和我承担一样的工作，无差别地提供服务，这个叫**主主模型**。

我还可以让分身只承担部分工作，例如分身只提供读，而主身提供读写，这个叫**主从模型**。

**Y：根据自身业务拆分**

提供不同业务类型的服务，就像上面我说的第二种分身方式。

![图片][9be87d388b255e8b5075c02c2c28b174.png]

我们公司里一般按业务进行微服务的拆分，不管是垂直的还是水平的，都是这种 Y 轴的划分方式。

**Z：根据用户属性或数据拆分**

就像我刚刚说的第三种分身方式。

![图片][9328ce03e83b666ecaf0032d4d39ea55.png]

这种拆分方式一般是数据集的拆分，经典的如 Redis 的集群模式，就是按数据的哈希值进行分片。

三种方式是可以同时存在的，组合起来就是这样。

![图片][80b2dce4bd1a1a7e485b7c33ef847363.png]

画得好丑。

**万物皆可 AKF**

刚刚也隐隐约约提到了，我们把这个模型试着往 Redis 里套一下，你就明白了。

**Redis**

单节点的 redis 很不稳定，所以有了很多保障可用性的扩展方式。

redis 中的**主从模式**，就是 AKF 中的** X 轴**方向的扩展。

redis 中的**集群模式**（也就是数据分片），就是 AKF 中的 **Z 轴**方向的扩展。

如果你再按照**业务拆分**，比如用户数据访问 redis1，订单数据访问 redis2，那你其实相当于在做 AKF 中的 **Y 轴**方向的扩展。

这是拿中间件举例。

我们再尝试着套一下公司中的普通业务项目。

**普通项目**

一个项目部署好几十台机器，比如我们的 API 服务部署了 128 个节点，那这个其实就是** X 轴**。

根据业务划分了很多微服务，比如有用户模块服务，订单模块服务，推荐模块服务，服务之间用 rpc 进行通信，这其实就是 **Y 轴**。

**Z 轴**一般在业务侧比较少，数据数据集的拆分方式，我们还没有这样的拆分，拿 Redis 的集群分片举例比较合适。

不过你要是说，根据用户的 IP 属性，将请求打在不同机器上，其实也算吧，没有特别严格的定义，只是一种思维方式。

总之，如果你能在架构侧拥有 AKF 的思考方式，很多中间件、业务、甚至现实生活中的组织架构和人员分配的设置，都可以站在一个更高更全面的视角去看待，这就是一个典型的**架构思维**。

今天这篇文章的 AKF 这个概念，也是我最近才知道的。

这个名词好多人都没听说过，但我了解了它的思想之后越发觉得对架构思维真的有用。之前很多架构上的设计，现在似乎有了一个更高层的理论支撑，这种感觉还是挺爽的，因此当然毫无保留地分享给大家。

其实 AKF 可扩展立方体模型，在《架构及未来》一书中的概念更广义，适用于所有抽象的、具体的组织形式的扩展，只不过用到技术架构上，也刚好合适。

所以这让我越发觉得这个思维的牛逼之处，也让我觉得，有的时候技术架构就是一种管理层面的东西，这么说完全不为过。

[f6b2cf53d5f50bd7f1655dbc11e8ee48.png]: /images/20221004/1143b9fa81374af0a576a3923a90f430.png
[e9e125c3ddebcd928141b81472c62b17.gif]: /images/20221004/193b8e1ac2eb465bac71f92ffafb6797.png
[b388c720386cf6a315911d2c276b8e83.gif]: /images/20221004/bc2e0dbb24f74e91907ef096c99c700d.png
[42dee4b5bb5222cfae6108b39abad461.gif]: /images/20221004/3811f98b93c84ca682a852b6b95fd410.png
[2dbf6ba0290c32532890e2d3e6538ab7.gif]: /images/20221004/6897e614faef40358686230628425da3.png
[eb2eb9889a71de458ada08a33f7c9c35.png]: /images/20221004/e1ff49a64a0e43cb87e1a42e914f46cb.png
[27d4fa26ad13a8edb3cadedf75dd1215.png]: /images/20221004/73525ddc285d498aa88f5861f7debe16.png
[9be87d388b255e8b5075c02c2c28b174.png]: /images/20221004/98a46fbc33394ce89664043b4bd95d72.png
[9328ce03e83b666ecaf0032d4d39ea55.png]: /images/20221004/5edbb87ae238435f8a5dad632285714b.png
[80b2dce4bd1a1a7e485b7c33ef847363.png]: /images/20221004/4e5979eb97c24f279455c25b38697db0.png