复杂系统是如何失败的

备注

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

芝加哥大学认知技术实验室医学博士 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管控组件能否做到无限的横向扩展，以及扩展过程中控制数据交换的开销，是难度和成本骤增的挑战。

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

参考