当当网高可用架构之道

《当当网高可用架构之道》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、技术规范制定，善于把握复杂业务需求,提出创新性解决方案，参与重点项目方案设计，对系统架构进行持续改造优化，推动技术革新，组织内外部技术交以下为分享整理正文：系统中的非功能性需求今天我们的主题是当当高可用架构设计之道，高可用并不是功能性的需求，而是传统的IT当中非功能性需求的一部分。大家可以看到我这里罗列了很多非功能性需求，但是这当中并没有「高可用」这三个字。举一个例子，比如说你买了一台苹果手机，无论是作为手机还是电脑，还是MP3,还是专门用来看视频的，都是功能；那么非功能性呢，比如说大家很崇拜乔布斯,产品设计极致体验,苹果手机只

2、有1个键，简单好用，这就是一个非功能性需求。另外还有很多朋友买土豪金的手机,就是为了区分开，因为颜色不一样。这个颜色也是非功能性需求。我们简单介绍几个非功能性需求。扩展性,有一些类似的可以抽象成统一模型的东西，如果说做好的话就可以支持扩展。用一个以前的例子，我以前是做电信行业的，比如说有一个需求要在全球通上开一个5块钱的套餐，接着又要在动感地带开一个10块钱的套餐,那么我们就可以做成一个模型，做成一个套餐的产品,品牌是一个属性，价格也是一个属性。这样的话,神州行再来一个50块钱的套餐,我们就不需要改什么应用，增加一些配置,定义一

3、些产品属性就可以了,这就是扩展性。高效率是说你对现有的资源使用是不是足够高效。比如说有的人写的代码比较烂，一启动就百分之几十的CPU使用率，这就不太合理。可测试，很多开发的同学不当回事，觉得开发好功能逻辑就够了。但是你做岀来的东西是要保证质量的。开个玩笑，如果说测试的妹子很漂亮，你愿意手把手的教她如何来测试功能，但要是妹子走了，来了一个糙爷们还需要你还手把手的教,你就不愿意了。因此必须要有一个测试的完整方法、功能说明、测试用例。这些非功能性的需求，是整个系统是不是正常稳定、可靠运转，以及被一个团队长期沿用下去的一个前提。而可用性

4、，涉及到很多方面。比如说伸缩性，是否能够在业务量增长的前提之下,通过水平扩展可以很容易支撑更多的业务。比如说安全性、可靠性，数据会不会丢失？所以这里lil很多的点，最终都是决定了可用性。那么可用性是什么呢？可用性就是这套系统最终是给用户用的，是有这些功能的，但是其他方面如果不能保障好,不能N个用户一直用z那你这个系统就无法体现它的价值。这是非常重要的,很多刚刚工作几年的，或者是一直在做产品研发的同学，对这方面没有切身的体会，没有在大晚上被人打电话说出了什么问题你赶紧来处理一下,没有这样切身的痛苦的体会。「高可用」到底是什么什么是

5、咼可用ConsistencyalldieotitMcunwrttEaMeqMrdlMSofordeMesAvailabilityIMtyMemccatimiMtoopwcate”exp«ledcvwrwithvicxletenure*rwetworliormeM*g

6、性。在整个系统层面也可以这么理解，因为多数系统的核心就是数据，数据本身受限于这三个特性只能满足两个,不能三个一起满足,整个系统也是如此。在互联网场景里，因为数据量大分区容忍性是必须要支持的。一致性可以稍微容忍一些，但是可用性是一定要保证的。所以最后多数的互联网公司多数的业务系统就是牺牲一致性,保证可用性和分区容忍性。我们继续往下看，什么可以影响可用性。首先是天灾,去年杭州发生了一起［■惨案」,支付宝机房的光缆被挖掘机挖断了,这就算是一种天灾了。还有青云的广州机房被雷劈了,这也是一种天灾。以上的情况基本上是不可抗的O其次是人祸，携

7、程公司去年也发生了「惨案」，系统宕机一下午，一直到晚上才恢复；还有阿里云,去年上了一个云盾的功能,用户在执行可执行文件的时候,就把这个可执行文件给删了,回头用户再找这个可执行文件的时候就找不到了。还有是BUG,在某一些特定场景下系统出问题，这是很正常的。设计缺陷是要重点说的,它比BUG更宏观一些,是结构上的问题,不是说你增加几个判断,改一下代码就可以解决的。基本上是属于一旦发现了，要么就是大改,要么就是重构,调整原来的设计,很难马上去解决。至于说性能瓶颈和资源不足，大家知道就是这么多的服务器，如果代码性能写得好，可能能扛住更多请

8、求，如果写得差，可能稍微增长一些就不行了。性能瓶颈就是短板，比如说负责某个模块是一个没有什么经验的小同学，代码质量不太高，他就可能成为了整个系统的短板，这个模块出了问题，其他的代码写得再好，整个系统还是不能用。灵异事件•黑夭鹅效应•未解之谜擋示硏轴理白金定律・分