复杂系统是如何失败的

注解

在解析系统架构之前,我首先要当头棒喝一下 : “不要构建过分复杂、功能堆砌的系统!!!”

芝加哥大学认知技术实验室医学博士 richard I. Cook 有一篇关于复杂系统发生故障的评述,其实也是我们计算机基础架构的真实写照。

如果你在一家大型软件/硬件公司,或者互联网头部公司工作,你会见到或者参与过匪夷所思的故障发生,有些甚至是灾难性和毁灭性的(也许是企业、也许是个人)。

在网络漫画 xkcd (Randall Munroe 绘制轻松、古怪的简笔幽默画),有一幅描绘令人眼花缭乱、看似坚不可摧的现代数字基础架构其实依赖着( 2347: Dependency ) 阿喀琉斯之踵

../_images/dependency.png

在这幅 2347: Dependency 漫画的原文和网友讨论中,我们会看到毫不起眼的基础架构组件小小失误 直到大厦崩塌 才被看见。

“庞大而复杂”的诱惑

作为云计算的技术公司,我感觉可能有一种对”庞大而复杂”系统的冲动,毕竟很多技术leader对于规模有一种迷恋,信奉 “大就是好” 。这一定程度确实是一种技术挑战,毕竟把 Distributed System Atlas 规模做大,确实可能对于调度资源来说,理论上不容易出现分配浪费。不过,骨子里可能还是 “技术炫耀” ,做到业界第一的规模。

但是,从我的经验来看,规模大并不是一个分布式系统,或者说 Kubernetes Atlas 应该片面追求的指标:

  • 集群规模过大则在管控平面有极大的压力,使得很多动态功能效率降低且难以稳定:

    • 随着节点硬件的不断增强,单节点管理的资源(pods)急剧增加,并且引入了 Service Mesh 之后,单个节点已经是非常复杂的微系统生态,叠加到整个集群以后,对 etcd - 分布式kv存储 和 apiserver / scheduler 核心组件产生巨大的压力。而Kubernetes管控组件能否做到无限的横向扩展,以及扩展过程中控制数据交换的开销,是难度和成本骤增的挑战。

    • 中心化管理确实带来的管控开发和维护的便利,但是对于不断增长的集群规模,中心化管理存在瓶颈,并且可能在不断动态变化的任务(并发大规模创建和销毁)出现雪崩

参考