微服务设计原则之AKF原则

男娘i 2022-12-28 12:57 192阅读 0赞

在设计微服务的时候，我们一般会遵循以下4个原则：

1）AKF拆分原则

2）前后端分离原则

3）无状态服务

4）restful的通信风格

AKF 把系统扩展分为以下三个维度：

*  X 轴：直接水平复制应用进程来扩展系统，将系统复制多份，即加机器得方式，大大提高系统的总体容量、解决单点问题等（A+A+A+A）
 *  Y 轴：将功能拆分出来扩展系统。（B+C=A）
 *  Z 轴：基于用户信息扩展系统。 将数据做分片

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpYW96aHUwMzAx_size_16_color_FFFFFF_t_70][]

假定我们开发一个博客平台，用户可以申请自己的博客帐号，并在其上发布文章。最初的系统考虑了 MVC 架构，将数据状态及关系模型交给数据库实现，应用进程通过 SQL 语言操作数据模型，经由 HTTP 协议对浏览器客户端提供服务，如下图所示：

![1f81d84eae0ef0c6592d858f36464f52.png][]

X轴水平复制：

在这个架构中，处理业务的应用进程属于无状态服务，用户数据全部放在了关系数据库中。因此，当我们在应用进程前加 1 个负载均衡服务后，就可以通过部署更多的应用进程，提供更大的吞吐量。而且，初期增加应用进程，RPS 可以获得线性增长，很实用，如下图：

![b331d6c372adde8ac6b3278b3e903443.png][]

这就叫做沿 AKF X 轴扩展系统。这种扩展方式最大的优点，就是开发成本近乎为零，而且实施起来速度快！在搭建好负载均衡后，只需要在新的物理机、虚拟机或者微服务上复制程序，就可以让新进程分担请求流量，而且不会影响事务 Transaction 的处理。  
当然，AKF X 轴扩展最大的问题是只能扩展无状态服务，当有状态的数据库出现性能瓶颈时，X 轴是无能为力的。例如，当用户数据量持续增长，关系数据库中的表就会达到百万、千万行数据，SQL 语句会越来越慢，这时可以沿着 AKF Z 轴去分库分表提升性能。又比如，当请求用户频率越来越高，那么可以把单实例数据库扩展为主备多实例，沿 Y 轴把读写功能分离提升性能。下面我们先来看 AKF Y 轴如何扩展系统。

Y轴扩展：

当数据库的 CPU、网络带宽、内存、磁盘 IO 等某个指标率先达到上限后，系统的吞吐量就达到了瓶颈，此时沿着 AKF X 轴扩展系统，是没有办法提升性能的。  
在现代经济中，更细分、更专业的产业化、供应链分工，可以给社会带来更高的效率，而 AKF Y 轴与之相似，当遇到上述性能瓶颈后，拆分系统功能，使得各组件的职责、分工更细，也可以提升系统的效率。比如，当我们将应用进程对数据库的读写操作拆分后，就可以扩展单机数据库为主备分布式系统，使得主库支持读写两种 SQL，而备库只支持读 SQL。这样，主库可以轻松地支持事务操作，且它将数据同步到备库中也并不复杂，如下图所示：

![270f4eff89b411dcfd895ab3b731581c.png][]

当然，上图中如果读性能达到了瓶颈，我们可以继续沿着 AKF X 轴，用复制的方式扩展多个备库，提升读 SQL 的性能，可见，AKF 多个轴完全可以搭配着协同使用。  
拆分功能是需要重构代码的，它的实施成本比沿 X 轴简单复制扩展要高得多。在上图中，通常关系数据库的客户端 SDK 已经支持读写分离，所以实施成本由中间件承担了，这对我们理解 Y 轴的实施代价意义不大。

所以我们再来看从业务上拆分功能的例子。  
比如，把用户的个人信息、身份验证等功能拆分出一个子系统，再把文章、留言发布等功能拆分到另一个子系统，由无状态的业务层代码分开调用，并通过事务组合在一起，如下图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpYW96aHUwMzAx_size_16_color_FFFFFF_t_70 1][]

这样，每个后端的子应用更加聚焦于细分的功能，它的数据库规模会变小，也更容易优化性能。比如，针对用户登录功能，你可以再次基于 Y 轴将身份验证功能拆分，用 Redis 等服务搭建一个基于 LRU 算法淘汰的缓存系统，快速验证用户身份。  
然而，沿 Y 轴做功能拆分，实施成本非常高，需要重构代码并做大量测试工作，上线部署也很复杂。比如上例中要对数据模型做拆分（如同一个库中的表拆分到多个库中，或者表中的字段拆到多张表中），设计组件之间的 API 交互协议，重构无状态应用进程中的代码，为了完成升级还要做数据迁移，等等。  
解决数据增长引发的性能下降问题，除了成本较高的 AKF Y 轴扩展方式外，沿 Z 轴扩展系统也很有效，它的实施成本更低一些，下面我们具体看一下。

Z周扩展通常是指基于请求和用户独特的需求，进行系统划分，并使得划分出来的子系统相互隔离，但又是完整的。

工程领域常见的这种扩展有以下两种方案。

1 单元化架构

在分布式服务设计领域，一个单元就是满足某个分区所有业务操作的自包含闭环。如上面我们所说的y轴扩展的SOA架构。客户端对服务端节点的选择一般是随机的。但是，如果在此加上这周扩展，那么服务的节点选择将不再是随机的。而是每个单元自成一体。如下图。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpYW96aHUwMzAx_size_16_color_FFFFFF_t_70 2][]

2数据分区

为了性能数据安全上的考虑。我们将一个完整的数据集按照一定的维度，划分出不同的子集。一个分区，就是整体数据集的一个子集。比如用尾号来划分用户，那同样尾号的那部分用户，就可以认为是一个分区。数据分析一般包括以下几种数据划分的方式。

数据类型（如：业务类型）

数据范围（如：时间段，用户id）

数据热度（如：用户活跃度，商品热度）

读写分离（如：商品描述，商品库存）

参考文章：[https://baijiahao.baidu.com/s?id=1632326446570197886&wfr=spider&for=pc][https_baijiahao.baidu.com_s_id_1632326446570197886_wfr_spider_for_pc]

[https://www.cnblogs.com/-wenli/p/13584796.html][https_www.cnblogs.com_-wenli_p_13584796.html]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpYW96aHUwMzAx_size_16_color_FFFFFF_t_70]: /images/20221120/59ee56e8ae8646f0be156e79e2c8a7bf.png
[1f81d84eae0ef0c6592d858f36464f52.png]: /images/20221120/10581b8f7399484f93ed315cf8fbb7b1.png
[b331d6c372adde8ac6b3278b3e903443.png]: /images/20221120/ad05f9ce25db4ba2a531acfbd83370fa.png
[270f4eff89b411dcfd895ab3b731581c.png]: /images/20221120/a66671a7c69a453d9d6813e9502c63e3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpYW96aHUwMzAx_size_16_color_FFFFFF_t_70 1]: /images/20221120/f833c3ce3a6046efbf813a4213b6b628.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpYW96aHUwMzAx_size_16_color_FFFFFF_t_70 2]: /images/20221120/716905dbff1b42e4905a27a587f29870.png
[https_baijiahao.baidu.com_s_id_1632326446570197886_wfr_spider_for_pc]: https://baijiahao.baidu.com/s?id=1632326446570197886&wfr=spider&for=pc
[https_www.cnblogs.com_-wenli_p_13584796.html]: https://www.cnblogs.com/-wenli/p/13584796.html