写文章累死了怎么办
共 2254字,需浏览 5分钟
·
2021-05-14 03:04
我是一个服务,我的名字叫闪客。
我提供的服务很简单,给我一个标题,我输出一篇文章。
日复一日,年复一年。
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 的思考方式,很多中间件、业务、甚至现实生活中的组织架构和人员分配的设置,都可以站在一个更高更全面的视角去看待,这就是一个典型的架构思维。
后记