阿里云双11大宕机(文后有福利)
11月12号，往年这个时候，我们应该看到铺天盖地的双11数据。今年，双11有点静巧巧，换成铺天盖地阿里云事故。
我懒的去猜事故真正原因，而且，root cause的追索，并不是一件容易的事。真正的“起因”，有时也调查不出来，只是有一个看起来还行的“说法”而已。
故障，永远是复杂系统无法避免之痛。应对故障，冗余，是共识。但还有一点，不仅被忽略，大厂无一例外的还反其道而行之，那就是复杂度。
越复杂的系统出现故障的可能性越高，而且，出现故障后的修复时间越长。这是常识，但如今，很遗憾，却不是共识。
我们总想“既要、又要”，既要快速的性能，又要极高的高可用性。
既要稳定的系统，又要方便、快速的故障恢复时间，美其名曰：缩短RTO。
……
怎么去实现各种各样的“既要 又要”呢，
简单啊，比如，本来一主一备，那就增加冗余度，一主多备。把“主“拆散，备放在各个地方，……
备太多了不好管理怎么办，切换的时候都不知道要用谁切谁？
上套管理系统啊，各种元数据都管起来，主的一部分功能挂了，自动切换备。管理系统起个名，盘古。高端吧，开天辟地。
管理系统挂了呢？没关系，管理系统也冗余起来，一主一备。
不行，一主一备的管理系统韧度不够，管理系统要拆散，每个部分要多备、备要放在不同机房、甚至地区。
管理系统太复杂了，怎么办。上套管理管理系统的系统。注意断句：管理“管理系统“的系统。就叫混沌吧，盘古前面的，大气磅礴的名字，也就混沌了。
混沌系统又是单点，……
系统就是这样变复杂的。
系统原来的代码量，可以万行到十万行左右，几年下来，轻松破百万。
考核程序员的重要指标，就是代码量。因此，代码量的扩展是必然的。系统复杂度的增长，也是必然的。
当系统的复杂度达到一定程度后，不可控事件的出现，就是必然的。
我说的玄乎了吗？看个实在点的例子。使用Perf 统计PostgreSQL执行一条简单SQL使用多个CPU指令，Perf命令如下：
有兴趣都可以试下。我在不同CPU下，统计select * from … where id=1这样的SQL（ID列是主键列）的指令数，大概在10万到15万条指令间。
某在业内以遥遥领先著称的大厂，以PG9为基础版本，开发了数年，推出了一款遥遥领先数据库。
此厂以狼性文化著称，给钱多、加班狠，996不是常态而是休息，常态是更狠的007。
几年007下来，看最左边的统计结果：
注：同一台机器、相同数据量、相同表结构、相同SQL不同数据库的统计结果
不出意外的，这指令数量比PG多出快10倍了，真不愧是遥遥领先数据库。
和MySQL、Oracle的比值就不分析了，此遥遥领先数据库毕竟是以PG为基础版本修改而来。
007不是闹着玩的，多10倍的指令数，说明这几年程序员真没闲着。增加了N多既要又要的功能，……
但是，我执行同样的SQL、检索同样的数据量，原生PG用了11万多条指令，你用了100多万条指令。
这就好像开车，开同样的距离，别人的油耗是11，你的油耗是100。这油耗，真是遥遥领先啊。
怎么办，简单啊。油耗太TM高，跑不过人家是吧，咱上分布式啊，中国人都知道，scalable架构+不一样的feature，才是新产品制胜之道。
这家大厂遥遥领先数据库的分布式scalable版本并没有开放出来，在既要又要思路下，加上007超高的执行力，代码量我相信在原基础上Double一下是没问题的，甚至再高个10倍我也相信。必竟，scalable也没那么容易实现的是吧。
回到系统复杂度的问题，代码量的过度增长，只是表象之一，是使用perf命令可以直观看到、感受到的。
系统总的复杂度，没故障时不太容易感受出来。但其实如同代码量一样，一步、一步，走向不可控。
一次和朋友聊到遥遥领先数据库时，我就说，如果他们能招个，996、007的缩减代码规模，我就相信他们能成为国产数据库中成功者之一，否则，……
好了，到了文后福利阶段：
阿里云系统还是很好的，抗过了双11，到12号才崩，真不容易了。
而且，99块钱就能买一年阿里云主机，好像还能有49元的返现，那就是50块钱买台云主机啊。还能99块的价格，再续两年。
对我们个人用户，12号宕一会也没啥关系是吧。