“1个小时内打500万到我卡上，否则别怪我们不客气，嘟嘟嘟........”
“本市富二代王某某被绑架，目前绑匪要求支付500万赎金，x市电视台为您现场报道”
“打打打，快把500万通过网上银行打给他，我的宝贝儿子啊.....”
“王总，您在xx银行的网上账户转账显示系统异常，请稍后重试”
“本市富二代王某某因未支付赎金，已被绑匪杀害，目前警方已介入调查，x市电视台为您报道”
...............
从人民的生活来讲，一个互联网产品，保证其实时是正确可用的是十分重要的，同时对互联网产品来说，其产品“随时”可用是一个品牌价值的延续，品牌服务的“宕机”可能不仅仅会造成客户的流失，以2015年支付宝被“蓝翔技校“挖断光纤为例，当天支付宝部分用户被迫停止服务2个小时，随着社会舆论发酵，有些用户以为支付宝要”跑路“了，对大型互联网公司来说，类比这种宕机导致的经济损失，其品牌信任度损失是更加严重的。
那么高可用到底是什么？简单的说就是服务每时每刻都是可用的，当然，保证每时每刻的可用性，是十分困难的，我们在本文中先探讨下高可用为什么这么难，同时讨论当前常用保证高可用的几种方案。另外，本文只讲高可用的概述，下面会有具体的文章详细介绍某些高可用方案的详细原理。
一、高可用为何这么难-系统是如何宕机的
（一）性能过载
我们都记得前几年在12306购买火车票时，12306主站经常因为流量过大而拒绝服务，这就是12306性能过载导致的。虽然机器的计算能力比人脑大很多，但机器总有处理能力上限，当请求的负载多于其所能承受的值的时候，响应会过慢，而继续增加其负载，会导致拒绝服务，而拒绝服务后，用户因为无法完成某种业务，会更加次的请求服务，导致恶性循环。
（二）应用异常
应用是人写的，人是无法保证所有代码是正确的，虽然应用上线前经过了严格的测试，但测试仅仅是一直模拟的验证行为，有些缺陷在用户数据量少的时候无法被发现，或者在某种特定情况下才发生，测试时难以构造此类场景，一旦这类缺陷影响了逻辑路径的主链路，将导致整个服务无法对外提供服务。
（三）中间件异常
大型应用无法离开中间件，一般企业应用中间件的来源为成熟的商用中间件，或者基础架构提供的自研中间件。比如较为成熟的商用中间件有：redis（内存性数据库），zookeeper（分布式应用程序协调服务），dubbo(阿里的序列化传输协议)，kafka（消息队列），hadoop（google的大文件存储系统），这些中间件在应用与应用间传输数据等需求提供着连接作用，一旦此类中间件停止服务一般会导致整个服务宕机。有些系统用到多类中间件，每个中间件的稳定性和中间件的规模和配置有关，中间件的稳定性普遍要低于普通应用，因此中间件如果出现异常，影响范围是极广的。
（四）物理因素
支付宝2015年被挖断机房光纤，导致网络中断，这种类似情况是时常发生的，除去网络因素，机房掉电而备用电源未启动导致整机房宕机、机房失火、物理网络设备过热宕机等都将导致服务宕机。
（五）发布更新
系统总要增加新功能，每次增加新功能都会对系统进行更新，将新代码发布到对应服务器，在发布过程中，绝大多数系统都是需要重启应用服务的。这就决定了在发布更新的过程中，整个系统是无法使用的。
（六）人为操作
我们来看下2017年发生因为删库导致的宕机事件：
17年2月，Gitlab数据库被误删，导致部分用户数据暂时丢失
17年6月Verelox 官网今天挂出了一封公告，称前系统管理员删除了所有客户数据，清空了大部分的服务器。
17年7月，花旗银行的前员工伦农·雷·布朗，通过非法执行命令，删除了花旗银行的内部网络上10只核心路由器上的配置文件
17年8月，腾讯公司公关总监称微信公众平台后台保存被清空。
嗯。。。除去删库以外，你还要可能删整台服务器，不行你执行“rm -rf /”试试
（七）黑客攻击
现在黑客攻入一台应用服务器是十分不简单的，但是让服务拒绝访问是有可能的，在国际互联网上，大家的ip都是可以被知晓的，这样就无法避免黑客进行一些网络攻击，如著名的DDOS网络洪水等，通过各种“肉鸡”发送大量请求到某一IP地址，导致正常网络流量不可达。
二、保证高可用的常用方案
如何保证高可用，现在用到的主流思想一般都是“备份”和“热切”，备份是指不止一个机器或不止一个集群在运行，当其中一台服务器或一个集群宕机时可以使用备份继续服务，热切是指在服务切换到备份服务时服务不停止，用户无感知，接下来我们就说一下常用的高可用方案。
（一）性能与高可用
高可用和性能是不可分割的，一个原因是性能足够强才可以承受更多的用户请求，另一个原因是高可用要保证每个服务节点都有备份，在备份的同时保证热切，一般为了避免资源浪费，我们去掉热切这个阶段，让备份服务器也成为主服务器对外提供服务，同时保证各节点间数据一致性，当其中一台宕机时，其余的服务器可以直接提供服务，而不需要热切。
负载均衡
负载均衡就是保证各节点灾备的同时又同时对外提供服务的一种方式。负载均衡存在大型应用的方方面面，一般从网关开始就使用F5或者nginx对应用进行分发，到了应用层，由使用lvs在网络层进行随机负载，或者使用类似dubbo这类总线进行软件负载，在中间件层，一般每个中间件的命中策略里全部采用负载均衡，就这样一层层的负载均衡，保证性能的同时，也起到了容灾的作用。
我们以一张网关负载均衡的图片来讲解负载均衡，当用户访问服务时，我们在中间加一台负载分发机（F5或者Nginx）将服务分发给后面的四台机器进行处理，在将每天服务器负载降低四倍的同时，保证高可用：其中一台宕机时，通过可用性探测断掉到这台的流量，让其他三台负载所有服务请求。
现实应用中的负载均衡要复杂很多，我们这里仅仅用简单的例子来理解复杂均衡。
DNS负载均衡
想一个问题，当我们一个公网ip入口被阻断时怎么切换到另一个可用ip，并且保证这个过程服务是可用的呢？
由此产生了一个产品叫做智能DNS，或者DNS负载均衡
DNS负载解析的步骤示意如下图：
- 用户向本级配置的本地DNS服务器发出查询请求，如果本地DNS服务器有该域名的缓存记录，则返回给用户，否则进行第2步；
- 本地DNS服务器进行递归查询，最终会查询到域名注册商处的授权DNS服务器，这里可能有多个步骤，图中只反映最后一步；
- 授权DNS服务器返回一条NS记录给本地DNS服务器。根据授权DNS服务器上的不同设置，这条NS记录可能是指向随机一个其中一个备份的ip地址或者是所有备份的ip地址；
- 本地DNS服务器向其中一个GSLB地址发出域名查询请求，如果请求超时会向其它地址发出查询；
- 智能DNS设备选出最优解析结果，如果其中一个ip地址是无法提供服务的，那么这里的智能DNS设备将把这台ip地址的解析去掉，最后返回一条A记录给本地DNS服务器。根据全局负载均衡策略设定的不同可能返回一个或多个VIP地址；
- 本地服务器将查询结果通过一条A记录返回给用户，并将缓存这条记录。
因为DNS的缓存特性，我们在IP地址切换时会存在一定的延时，一般DNS缓存最低允许设置的更新时间是10分钟，因此此方法会导致最多十分钟的延时。但对比整个服务宕机，这个延时是可以接受的。
弹性伸缩
弹性伸缩（Auto Scaling），用户根据自己的业务需求和业务策略，自动调整弹性计算管理服务。高峰增长时增加，业务收缩时减少。弹性伸缩主要用在请求量在时间分布上长期不对等的应用架构上，当应用请求多时，应用服务器自动增加和自动部署，并且自动将自己加入应用路由，请求减少时，会释放部分服务器以节省资源。
（二）灾备与高可用
集群多层容灾
如图，在一个大型应用中，其负载均衡和灾备是多层的，一般都如图中所示，网关层采用负载均衡后，往下的每一层，包含每一层的中间件也采用负载均衡和容灾模式。这种层层负载和容灾保证了高可用，当某一个机器发生宕机后，并不会对整个集群和服务造成任何影响。
同城双活与异地灾备
为了防止机房大火大规模停电等因素造成服务中断，一般一个应用在一个城市中搭建两个机房，机房间建立专线，网络延时不是很高，两个机房互为主备，这就是同城双活。
为了防止地震等大规模的自然灾害造成数据永久性损失或长时间宕机，一般会在异地设立另一个备份机房，同时进行数据实时备份，当有灾备需求时，可以保证短时间内切换到异地机房，这叫做异地灾备，当然，业务切分较好的企业，数据库实时性依赖不是很强的情况下，可以做到异地双活。
同城双活和异地灾备是一个复杂的技术，我们将开一篇新文章重点阐述。
（三）产品发布与高可用
产品发布更新时，为了保证不停机，一般进行热发布，或者叫做不停机发布。用到较多的两个场景多为灰度发布和蓝绿发布，其中灰度发布多倾向于生产验证，是一种新老版本同时存在的方式，虽然看起来和不停机发布没有太多关系，但是因为灰度的引流切换是即时的，这种方式更像蓝绿发布，我们就来看下什么是蓝绿发布。
蓝绿发布
蓝绿部署的模型中包含两个集群，就好比海豚的左脑和右脑。
在没有上线的正常情况下，集群A和集群B的代码版本是一致的，并且同时对外提供服务。
在系统升级的时候下，我们首先把一个集群（比如集群A）从负载列表中摘除，进行新版本的部署。集群B仍然继续提供服务。
当集群A升级完毕，我们把负载均衡重新指向集群A，再把集群B从负载列表中摘除，进行新版本的部署。集群A重新提供服务。
最后，当集群B也升级完成，我们把集群B也恢复到负载列表当中。这个时候，两个集群的版本都已经升级，并且对外的服务几乎没有间断过。
（四）架构与高可用
没有最好的架构，只有最合适的架构，最适合自己企业的高可用架构才是最合适的架构。一般在高可用架构中，业务切分十分重要，整个系统应用的架构要跟着业务切分的思路走，这是因为在同城双活和异地灾备时，数据库跨机房或跨地域读取的延时是不能被接受的，这就要求同一个用户的数据要落到同一个机房，不同用户的数据可能落到另一个机房，中间存在数据穿插的部分使用接口调用的方式进行业务请求。用户数据的同机房化，带来的是所有关联表字段的同机房化。解决这个问题不仅仅是数据库横向切分的问题，更涉及到更多层次的架构切分。
详细内容，请期待我的下一篇文章：服务端高可用架构之两地三中心与架构切分