【稳定性day2】当当网的高可用之道

本文来自当当架构部总监史海峰的分享。

 

系统中的非功能性需求

今天我们的主题是当当高可用架构设计之道，高可用并不是功能性的需求，而是传统的IT当中非功能性需求的一部分。大家可以看到我这里罗列了很多非功能性需求，但是这当中并没有「高可用」这三个字。

举一个例子，比如说你买了一台苹果手机，无论是作为手机还是电脑，还是MP3，还是专门用来看视频的，都是功能；那么非功能性呢，比如说大家很崇拜乔布斯，产品设计极致体验，苹果手机只有1个键，简单好用，这就是一个非功能性需求。另外还有很多朋友买土豪金的手机，就是为了区分开，因为颜色不一样。这个颜色也是非功能性需求。

我们简单介绍几个非功能性需求。

扩展性，有一些类似的可以抽象成统一模型的东西，如果说做好的话就可以支持扩展。用一个以前的例子，我以前是做电信行业的，比如说有一个需求要在全球通上开一个5块钱的套餐，接着又要在动感地带开一个10块钱的套餐，那么我们就可以做成一个模型，做成一个套餐的产品，品牌是一个属性，价格也是一个属性。这样的话，神州行再来一个50块钱的套餐，我们就不需要改什么应用，增加一些配置，定义一些产品属性就可以了，这就是扩展性。

高效率是说你对现有的资源使用是不是足够高效。比如说有的人写的代码比较烂，一启动就百分之几十的CPU使用率，这就不太合理。

还有可测试，很多开发的同学不当回事，觉得开发好功能逻辑就够了。但是你做出来的东西是要保证质量的。开个玩笑，如果说测试的妹子很漂亮，你愿意手把手的教她如何来测试功能，但要是妹子走了，来了一个糙爷们还需要你还手把手的教，你就不愿意了。因此必须要有一个测试的完整方法、功能说明、测试用例。

这些非功能性的需求，是整个系统是不是正常稳定、可靠运转，以及被一个团队长期沿用下去的一个前提。

而可用性，涉及到很多方面。比如说伸缩性，是否能够在业务量增长的前提之下，通过水平扩展可以很容易支撑更多的业务。比如说安全性、可靠性，数据会不会丢失？所以这里面很多的点，最终都是决定了可用性。

那么可用性是什么呢？可用性就是这套系统最终是给用户用的，是有这些功能的，但是其他方面如果不能保障好，不能N个用户一直用，那你这个系统就无法体现它的价值。这是非常重要的，很多刚刚工作几年的，或者是一直在做产品研发的同学，对这方面没有切身的体会，没有在大晚上被人打电话说出了什么问题你赶紧来处理一下，没有这样切身的痛苦的体会。

 

「高可用」到底是什么

接下来我们说一下什么是高可用。CAP理论是指在分布式数据的场景来形容三者不可兼得，就是一致性、可用性和分区容忍性。在整个系统层面也可以这么理解，因为多数系统的核心就是数据，数据本身受限于这三个特性只能满足两个，不能三个一起满足，整个系统也是如此。

在互联网场景里，因为数据量大分区容忍性是必须要支持的。一致性可以稍微容忍一些，但是可用性是一定要保证的。所以最后多数的互联网公司多数的业务系统就是牺牲一致性，保证可用性和分区容忍性。

我们继续往下看，什么可以影响可用性。

首先是天灾，去年杭州发生了一起「惨案」，支付宝机房的光缆被挖掘机挖断了，这就算是一种天灾了。还有青云的广州机房被雷劈了，这也是一种天灾。以上的情况基本上是不可抗的。

其次是人祸，携程公司去年也发生了「惨案」，系统宕机一下午，一直到晚上才恢复；还有阿里云，去年上了一个云盾的功能，用户在执行可执行文件的时候，就把这个可执行文件给删了，回头用户再找这个可执行文件的时候就找不到了。还有是BUG，在某一些特定场景下系统出问题，这是很正常的。

设计缺陷是要重点说的，它比BUG更宏观一些，是结构上的问题，不是说你增加几个判断，改一下代码就可以解决的。基本上是属于一旦发现了，要么就是大改，要么就是重构，调整原来的设计，很难马上去解决。

至于说性能瓶颈和资源不足，大家知道就是这么多的服务器，如果代码性能写得好，可能能扛住更多请求，如果写得差，可能稍微增长一些就不行了。

性能瓶颈就是短板，比如说负责某个模块是一个没有什么经验的小同学，代码质量不太高，他就可能成为了整个系统的短板，这个模块出了问题，其他的代码写得再好，整个系统还是不能用。

最后还有一些未知的情况。大家做技术做的时间长会遇到很多无法解释的「未解之谜」，我们一般称之为「灵异事件」，这个是指经常发生的，你不知道问题在哪里，但是过段时间就来一次，就好象冥冥之中有人玩你一样，但是总归是可以找到原因解决的。

至于说黑天鹅的事件，则是以前从来没有出现过的情况，突然出现了࿰