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