层层考虑可用性的互联网系统

互联网系统7*24小时不分昼夜的为人民服务，那么这样长时间服务的背后究竟有哪些手段保证呢？

这其中包括软硬件，及基础设施的保障。

IT人的努力

分布式系统

软件架构师在设计大型互联网系统时考虑的高可用性是从分布式系统的特点考虑的高可用。主要的思路就是在各个层面做冗余，备份。

访问所有网页的第一步，解析DNS, 全球十二个根服务器，从国家，骨干网，各级运营商核心机房，省级机房，局站都有DNS缓存服务器，保证解析速度。当然，大型网站专门自建的DNS服务器也都是一组集群。

提供服务的web应用只有一个服务器不安全，而部署一组同样功能的服务器集群就降低了单个服务器产生故障的风险。

IDC

一组在同一个IDC中的应用集群在IDC级别是单点（天朝经常遇到挖光缆，遭雷劈），要将应用集群跨机房部署，此时要求应用无状态，可以随意部署。

IDC的建设在国内有运营商（电信、联通、移动）和第三方基础设施提供商（如世纪互联），由于国内的现实状况，运营商提供的IDC网络质量较好，但是不能提供多线互通；而第三方质量比较参差不齐，有好有坏，但能提供BGP多路接入，一般出口带宽较小。

最高级的T3机房的设计要求一条就是要能抗8级地震，也就是跟几年前汶川一样的震级。

高可用软件

Heartbeat与keeplived，此类软件采用IP漂移技术，主要侧重在做服务器的主备切换，在一些本身没有集群功能支持的产品上，如早期Redis上能做简单的主备高可用，并对应用本身无感知，简化应用开发。如果单个一组主备的redis不能满足容量需求，需要做Redis集群，则要用一些简单工具库人为对redis的读写进行分片（如jedis），此时集群维护成本变高，最好组件本身有原生的集群功能支持。

存储

数据库服务器用的硬盘使用raid10保证本地硬盘上的冗余，再通过linux LVM卷管理做本地存储冗余备份，再通过存储厂商的商业解决方案或自研技术将单IDC的数据复制到同城异地IDC的存储系统中，保证如果源站IDC被毁（极端的地震，战争），在同城另一个机房仍有可恢复的备份。

当然如果有地震，那么同城容灾就不够了，还需要异地容灾，因为地震通常是区域性的，杭州地震不会对上海机房有很大影响。

光在存储上做异地容灾是不够的，如果是冷备，平时并没有用起来，也没有合理的机制做演练切换，真到了一个IDC故障需要将应用读取切到备库上去的时候，没人心里有底敢做这个决策，尤其是金融系统，数据库一旦出错会对企业造成可能致命的资损故障。

可以参考工商银行2013年6月23日波及全国的长时间停机故障，说明我国国有银行IT信息化技术储备仍然薄弱，主要解决方案还是被美国厂商绑架。

国企背景的办事思路一般找500强咨询公司要方案并实施，这样负责人可以不用担职业前途的风险，出问题了全部推到合作方身上，并不考虑自己能为企业提供什么价值，典型的官场思维，当然这是题外话了。这个问题现在运营商高层应该已经认识到了，能看到目前运营商的思路有了一些变化，开始在自营业务上做技术和人才的储备了。

设备

常用的硬件负载均衡设备如F5，在设计上都是采用双机冗余，心跳信号可以走设备串口或TCP。

一个4U的机架式服务器，都有冗余的电源设计（2+1，2+2,3+1）等，千兆网卡多块。冗余的电源可以被芯片控制进行负载均衡，与程序员熟知的keeplived做的HA一样，当一个电源不行时可以进行切换。

电力

云计算背景下，单机柜服务器部署密度的增加，对于电力的要求也越来越高，在一个部署了4到6个刀片服务器的机柜最高需要30kW的电力。

电力的冗余体现在UPS和柴油发电机上。并且大型数据中心采用两路独立供电路径，保证一路电力挂掉后另一路仍能为整个数据中心进行供电。

用户享受了

可以看到一个7*24小时的系统需要在方方面面上考虑系统的可用性, 软件架构师要考虑在架构上支持容灾；运维工程师要考虑机房网络，服务器等能满足业务需要；而IDC的建设要考虑选址（避开地震带），电力供应，制冷等建筑规划，能耗上的约束；设备厂家要考虑的是自己的产品能减少硬件故障宕机时间。

所有的努力，最终改变了人们的生活：

你可以坐在家里购物；快递提供迅速的物流；用手机打车，叫外卖；不分白天黑夜的玩网络游戏；随时随地用微信抢红包；在便利店用手机付款；与爸妈远程聊天。

程序员主宰世界！

---

文章来自微信平台「麦芽面包」
微信公众号「darkjune_think」转载请注明。
如果觉得有趣，微信扫一扫关注公众号。