写文章累死了怎么办

低并发编程

共 2254字,需浏览 5分钟

 ·

2021-05-14 03:04

低并发编程
战略上藐视技术,战术上重视技术

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

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

日复一日,年复一年。


X


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

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

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

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

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


Y


但随着粉丝数量的继续增多,我发现我即使再多分身也没用。

因为慢慢地,事情已经不仅仅是写文章就够了,文章技术答疑,广告对接等等工作。

每一个分身,不再像以前那样只处理一项工作,因此效率也降低了。

此时我不能再通过分出多个一模一样的我,来处理相同的事情,必须根据业务进行不同功能的划分

这样,写文章的闪客,就专心写文章,技术答疑的闪客,就专心进行技术答疑,做广告的闪客,就专心数钱。

每个人的任务再次变得单一,也专注了起来,效率又上了一个台阶。

此时已经可以轻松驾驭上万个粉丝的需求啦。


Z


但又随着粉丝数量的继续增长,我发现,按功能分身也没用了,因为某个单一的功能,也变得极为复杂。

比如技术答疑,有的读者问的是职业规划,有的读者问的是技术细节,还有的读者是问我婚否饭否。

负责技术答疑的分身,已经无法再进行自身业务属性上的拆分了,但又越来越无法招架用户五花八门的问题,怎么办呢?

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

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

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

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

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


AKF


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

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

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

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

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

当然还有更具体的。

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

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

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

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 的思考方式,很多中间件、业务、甚至现实生活中的组织架构和人员分配的设置,都可以站在一个更高更全面的视角去看待,这就是一个典型的架构思维


后记





今天这篇文章的 AKF 这个概念,也是我最近才知道的。
这个名词好多人都没听说过,但我了解了它的思想之后越发觉得对架构思维真的有用。之前很多架构上的设计,现在似乎有了一个更高层的理论支撑,这种感觉还是挺爽的,因此当然毫无保留地分享给大家。
其实 AKF 可扩展立方体模型,在《架构及未来》一书中的概念更广义,适用于所有抽象的、具体的组织形式的扩展,只不过用到技术架构上,也刚好合适。
所以这让我越发觉得这个思维的牛逼之处,也让我觉得,有的时候技术架构就是一种管理层面的东西,这么说完全不为过。
OK,今天就分享到这里啦,欢迎大家加我好友(公众号菜单里有)一起讨论技术,或看我朋友圈里的一惊一乍,下期再见咯。

浏览 24
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报