完整word版当当网高可用架构之道.docx

完整word版当当网高可用架构之道.docx

《完整word版当当网高可用架构之道.docx》由会员分享，可在线阅读，更多相关《完整word版当当网高可用架构之道.docx（9页珍藏版）》请在冰豆网上搜索。

完整word版当当网高可用架构之道

嘉宾：

史海峰，当当架构部总监。

2012年加入当当，负责总体架构规划、技术规范制定，善于把握复杂业务需求，提出创新性解决方案，参与重点项目方案设计，对系统架构进行持续改造优化，推动技术革新，组织内外部技术交

以下为分享整理正文：

系统中的非功能性需求

今天我们的主题是当当高可用架构设计之道，高可用并不是功能性的需求，而是传统的IT当中非功能性需求的一部分。

大家可以看到我这里罗列了很多非功能性需求，但是这当中并没有「高可用」这三个字。

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

另外还有很多朋友买土豪金的手机，就是为了区分开，因为颜色不一样。

这个颜色也是非功能性需求。

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

扩展性，有一些类似的可以抽象成统一模型的东西，如果说做好的话就可以支持扩展。

用一个以前的例子，我以前是做电信行业的，比如说有一个需求要在全球通上开一个5块钱的套餐，接着又要在动感地带开一个10块钱的套餐，那么我们就可以做成一个模型，做成一个套餐的产品，品牌是一个属性，价格也是一个属性。

这样的话，神州行再来一个50块钱的套餐，我们就不需要改什么应用，增加一些配置，定义一些产品属性就可以了，这就是扩展性。

高效率是说你对现有的资源使用是不是足够高效。

比如说有的人写的代码比较烂，一启动就百分之几十的CPU使用率，这就不太合理。

可测试，很多开发的同学不当回事，觉得开发好功能逻辑就够了。

但是你做出来的东西是要保证质量的。

开个玩笑，如果说测试的妹子很漂亮，你愿意手把手的教她如何来测试功能，但要是妹子走了，来了一个糙爷们还需要你还手把手的教，你就不愿意了。

因此必须要有一个测试的完整方法、功能说明、测试用例。

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

而可用性，涉及到很多方面。

比如说伸缩性，是否能够在业务量增长的前提之下，通过水平扩展可以很容易支撑更多的业务。

比如说安全性、可靠性，数据会不会丢失？

所以这里面很多的点，最终都是决定了可用性。

那么可用性是什么呢？

可用性就是这套系统最终是给用户用的，是有这些功能的，但是其他方面如果不能保障好，不能N个用户一直用，那你这个系统就无法体现它的价值。

这是非常重要的，很多刚刚工作几年的，或者是一直在做产品研发的同学，对这方面没有切身的体会，没有在大晚上被人打电话说出了什么问题你赶紧来处理一下，没有这样切身的痛苦的体会。

「高可用」到底是什么

接下来我们说一下什么是高可用。

CAP理论是指在分布式数据的场景来形容三者不可兼得，就是一致性、可用性和分区容忍性。

在整个系统层面也可以这么理解，因为多数系统的核心就是数据，数据本身受限于这三个特性只能满足两个，不能三个一起满足，整个系统也是如此。

在互联网场景里，因为数据量大分区容忍性是必须要支持的。

一致性可以稍微容忍一些，但是可用性是一定要保证的。

所以最后多数的互联网公司多数的业务系统就是牺牲一致性，保证可用性和分区容忍性。

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

首先是天灾，去年杭州发生了一起「惨案」，支付宝机房的光缆被挖掘机挖断了，这就算是一种天灾了。

还有青云的广州机房被雷劈了，这也是一种天灾。

以上的情况基本上是不可抗的。

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

还有是BUG，在某一些特定场景下系统出问题，这是很正常的。

设计缺陷是要重点说的，它比BUG更宏观一些，是结构上的问题，不是说你增加几个判断，改一下代码就可以解决的。

基本上是属于一旦发现了，要么就是大改，要么就是重构，调整原来的设计，很难马上去解决。

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

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

最后还有一些未知的情况。

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

至于说黑天鹅的事件，则是以前从来没有出现过的情况，突然出现了，让你不知道应该怎么办，而且可能是一两年才出现一次，你会要考虑值不值得找它如何出现的。

还有一些以后就再也不出现了，谁也不知道是怎么回事，你就不知道怎么办了。

最后一个是未知的，我们不知道会出现什么样的事情，出现的情况我们也不知道如何应对。

科学告诉我们，已知的我们可以去努力解决，但是未知的，我们无法判断。

关于系统故障，有一个海因法则，意思是说出现一起严重的事故，都是由很多的隐患，很多的小问题，或者说一些问题没有暴露出来，最终引发特别大的事故。

负责运维的同学都知道，公司对系统的可用性是有指标的，是99.9%还是99.99%，还是99.999%，如果说公司没有这个东西压着你作为KPI，那就太幸运了，出了问题不至于让你拿不到奖金。

如果说你的公司有，我希望研发和架构的同学都要清楚，而不是只有运维的同学知道，否则就是公司管理不到位，举个例子如果可用性标准是99.99%，一年系统可以挂的时间是53分钟，99.999%则是5分钟，大家想想就知道，携程挂了一下午，整个可用指标就完不成了，KPI就完成不了。

高可用同时是一个概率的问题。

一个复杂的系统，比如说很多模块或者子系统组成的系统，是可以通过一些方式大概去估算的。

前些年云计算很火，很多人都说我们有一个云要自动运行，几万台服务器必须要有自动恢复的系统，最好是分钟级恢复，秒级恢复。

这些都是一个概率，怎么去算呢？

比如说我有两个手机，最近一个月内有3次差一点丢1台手机，这是未遂事件，那么基本上我丢失的概率就确定了，比如说是1/30。

我有两个手机的话有什么好处，没有手机用的概率就是1/900。

但是丢手机的概率增加了，我就要做好心理准备，没准哪天就会失去一个。

多数系统是几台或者是几十台服务器组成一个小的集群，还有很多跟它平行和上下依赖的系统。

这种系统都可以用这种方式去算，大概是什么样的概率。

这个还涉及到容量评估，要考虑系统负载是多少？

比如说像我们以前做企业级系统用小型机，小型机的可靠性非常高，平时就是50%左右的负载，这个时候三四台机器加在一起就够用了，因为挂一台基本上系统不会有太大影响。

但是如果用不太可靠的PC服务器或者其他解决方式，因为担心可能出现的状况，所以现在很多互联网公司采取的是常年运行10%的CPU或者是20%的CPU状态。

我们可以考虑一个系统，比如说一台机器挂了，影响系统部分出现问题的概率有多高，多个系统总有一天会出问题，如果说系统足够大，大家可以想像，无论是Facebook、谷歌，还是BAT基本上每天都会有各种各样的小问题。

所以越复杂的系统越是难以评估，我们要保证出现问题的时候可控。

高可用并不是万无一失，我们是用更多出问题的概率去降低整个系统出问题的概率。

还有一个说法叫墨菲定律。

基本上你想到的最坏的事情它总会发生的。

上学的时候，数学老师会说，小概率事件基本上不会发生。

但是在IT，在一个复杂环境当中，在上千台上万台服务器的集群中，几百人几千人做的系统，一定会有一天出问题的。

所以人算不如天算，你算出来概率很低，你保证我出问题的概率哪怕是几十万分之一，你觉得这辈子就赶不上了？

不见得的。

那么怎么办？

就是时刻准备着。

这是我做了这么多年开发最大的体会。

我们做的是一个7×24小时对外服务的系统，不能停。

不能停的概念不是说像有的公司那样，白天有人用，晚上没人用，晚上出事了，我们来得及修补修补。

但是像电商是7×24小时的，半夜三四点都有下单的。

人家在熬夜开心下单的时候，你出了问题，阻止人家的下单，要不然就是打电话投诉，要不然是找地方吐槽。

系统故障不仅是技术上的问题，最严重的是影响客户体验，前一段时间我们的评论系统出了点小问题：

一个客户买了一个面条机，反馈说并不是因为产品本身做不好面条要退货，因为其他原因，这个因为产品已经用过了所以按照规定是不能够退货的。

结果用户想评论的时候评论不了，用户就觉得说当点击评论按钮时，系统告知接口错误，觉得这是在针对他，其实这只是系统故障，但是用户并不会这么想。

当你做了各种各样的准备，觉得万无一失了，难免有一天可能还是会翻船了。

但是遇到这样的事情也是好事，经验都是在这个时候积累起来的。

那么什么是高可用？

基本上就是三句话，降低故障出现的概率；缩小故障影响的范围；出现故障快速恢复。

不能因为是个小问题就觉得无所谓，反正我一堆的服务器，挂一个就挂一个吧，这种情况不好说会不会另外一个也挂了。

因此有问题要尽快处理，最终的目的就是让用户可以正常的使用。

如何设计高可用架构

高可用架构设计常用的「姿势」。

大家看到这是一架飞机。

我们有一个比喻说做运维这种系统，就是开着飞机修飞机。

首先系统一直运行，其次运营、产品各种业务部门会不停提各种各样需求，然后领导也许不懂技术，不懂什么叫分支、什么叫循环、什么叫面向对象；但是懂两个词，一个是敏捷，一个是迭代。

所以做这件事情的时候难度是比较高的。

我们不能让这架飞机停下来歇几天，把翅膀换了再飞上去；而是常年在天上飞的，飞上去的时候也许就是个阿帕奇直升机，特别是创业公司。

回头要拓展一个业务，增加一些功能，做着做着原来的业务不行了，新的业务变成了主营业务，结果变成了F15，从直升机变成了战斗机，然后变成F16，变成F22。

一旦技术团队没有做好，一头栽下去，技术团队的名声就砸了。

要么是没做出来，要么是做出来之后一上线挂了，市场费用都白花了，这个责任要技术来承担。

我在四个领域里面分别提炼了几条高可用相关的架构方式。

业务架构就是指产品是什么功能，有什么要求。

∙首先是领域切分，不要把鸡蛋放在一个篮子里，比如说一些传统网站，有非常多的二级域名。

某一个二级域名挂了，都是不同的服务器，其他的还可以提供正常的服务。

∙系统分级，哪些系统对用户来说比较重要，级别就会更高，我们就要花更多心思去保障，其他的相对差一些。

∙降低耦合，最近在架构圈当中流行一个词叫康威定律（编者注：

Conway’slaw:

Organizationswhichdesignsystems[…]areconstrainedtoproducedesignswhicharecopiesofthecommunicationstructuresoftheseorganizations），是指系统架构是和公司组织架构是有关系的。

降低耦合也是如此，不要把系统搞得太复杂，你的组织和团队不要和太多的部门打交道。

优化架构，让系统的关系尽可能的简单、明确。

这样出现问题范围可控。

∙有损服务是什么意思呢？

可以牺牲一些用户体验来保证基本功能的可用。

系统架构当中，分以下几点。

∙第一个是数据独立，不允许跨系统访问数据库这个常识大家都懂，但是很多公司做不好，因为没有强有力的措施去控制。

这种事情做起来不太容易，需要管理或者说大家认可才行，但是实际上是非常关键的，因为数据如果不切分，系统很难切分，耦合就非常严重。

时间长了出了问题，你连谁写的，谁改的这个数据都不知道，那怎么办？

∙第二点是集群分布，这个就不提了。

∙第三个是冗余部署。

比如说电商业务是有波动的，每天的上午11点或者是下午4、5点订单量都会增长，上班族都要休息一下，给自己的辛苦找一些心理安慰，这个时候开始购物。

但不能说就这