高可用已经成为互联网公司的标配，如何实现高可用呢，首先这不是一个很容易就解决的问题，如果说仅仅是2个9，那就不用怎么讨论了，如何做到阿里云宣传的5个9呢，一年之内只有5分钟的宕机时间，也就是代表着一年不能出现一次故障。
高可用就是保证服务7*24小时，在任何时间，任何地点，任何人访问任何服务都有结果。
为什么需要高可用
硬件总是会出问题的：
生命周期 硬件总是会逐渐的老化
硬件故障 在机器数量不断增多的情况下，出错的概率会逐渐的增加
网络划分 在CAP理论中，只要有网络分区，那么就要考虑服务是否可用了
软件：
bugs 不管程序怎么样总是会有bug的，普遍来说，普通程序员在5~15行就会有一个bug，程序超过3行就有有漏洞的风险
性能极限
软件间相互影响
环境：
流量突发 超出现有系统容量， 明显八卦
大型促销活动 618活动 双11活动
硬件和软件总是会有可能出问题，之外还有不可预料的坏境因素，而我们又要保证服务的7*24小时正常服务，那么必须要保证高可用
高可用评估手段
如何测量系统的高可用性，一般称为SLA(Service Level Agreement)，即几个9的高可用性：
| 系统可用性% | 宕机时间/年 |
|---|---|
| 90% (1个9) | 36.5 天 |
| 99% (2个9) | 3.65 天 |
| 99.9% (3个9) | 8.76 小时 |
| 99.99% (4个9) | 52.56 分 |
| 99.999% (5个9) | 5.26 分 |
上面的评估方式有一点局限性，在系统中总有流量高峰期与流量低峰期，不同时间段故障对系统产生的影响也是不同的。
还有一种评估方式为：
1 - (停机时间影响请求量/全年的请求量)
如果你没办法衡量，你就没办法改进
所以知道高可用的衡量指标，才能去谈如何保证高可用
设计手段
1 服务冗余 无状态化，无状态层的服务可以平行扩展，请求落到哪台服务器都没有关系。平行扩展也有利于系统容量的扩充，快速扩容应对突然爆发流量的冲击。
2 负载均衡 幂等设计，一台机器宕机，可以将请求转移到其他机器
3 超时机制 异步化设计，异步调用不关心返回结果，不会传递依赖方的错误，进而避免造成更大规模的不可用。
4 服务限流降级熔断 数据复制/缓存/Sharding，在系统真的出现了不可用的时候，需要有兜底方案。比如一些提示安抚用户，或者有跳转链接转移用户的请求。
5 架构拆分 服务治理，分为水平拆分和垂直拆分，拆分不是以减少不可用时间为目的，而是以减少故障影响面为目的。因为一个大的系统拆分成了几个小的独立模块，一个模块出了问题不会影响到其他的模块，从而降低故障的影响面。
服务分级
首先对服务进行分级与进行服务可用性衡量指标类似，分清影响的严重程度，制定不同的方案，核心应用与服务优先使用更好的硬件
比如有以下服务级别标准，每个公司的标准不同，根据自己标准来进行重要程度划分，一般来说核心购买链路不能中断：
| 服务级别 | 定义标准 |
|---|---|
| 一级服务 | 1 服务每天PV5000W以上、2 收入到达公司在线收入的1/10 |
| 二级服务 | 1 服务每天PV1000W以上，收入到达公司在线收入1/20 |
| 三级服务 | 其它 |
事故定级：
| 事故定级 | 影响程度低 | 影响程度中 | 影响程度高 |
|---|---|---|---|
| 一级服务 | 严重 | 重大 | 特大 |
| 二级服务 | 一般 | 严重 | 重大 |
| 三级服务 | 无 | 一般 | 严重 |
影响程度定级：
| 影响程度定级 | 影响程度低 | 影响程度中 | 影响程度高 |
|---|---|---|---|
| 对外完全停止服务时间 | 2-7分钟 | 7-30分钟 | 30分钟以上 |
| 系统对用户产生拒绝占当日预期流量比例 | 0.1%~1% | 1%~6% | 6%以上 |
| 系统返回结果不符合预期占当日比例 | 0.5%~2% | 3%~15% | 15%以上 |
| 受影响用户占系统用户比例 | 3%~20% | 20%~40% | 40%以上 |
| 影响数据程度 | 部分数据丢失，但能恢复 | 部分数据丢失不能恢复 | 所有数据丢失不能恢复 |
| 收入损失，占日平均营收 | 2%~5% | 5%~30% | 30%以上 |
| 网络丢包率 | 5%~10% | 10%~30% | 30%以上 |
通过规范来定义这些事情，方便公司进行管理，这个只是作为参考
服务升级
公司业务不断的发展，肯定要进行服务的升级操作，而高可用又要要求我们不能停机进行升级，不过有些十分特殊的情况，需要暂时进行停机升级。
日常任务：备份，容量规划，用户和安全管理，后台批处理应用
运维相关：数据库维护、应用维护、中间件维护、操作系统维护、网络维护
升级相关：数据库、应用、中间件、操作系统、网络、包括硬件升级
大型网站一般使用灰度发布模式：即把集群服务器分为若干部分，每天只发布一部分服务器，观察运行稳定没有出现故障，那么第二天再继续发布另一部分的服务器，这样持续几天才会把整个集群都发布完毕。期间如果发现问题，就只需要回滚那些已发布的那部分服务器就行。
当然蚂蚁金服还有一套蓝绿发布模型：蚂蚁金服蓝绿发布实践，自动化是一直都在探索的方向。
一个无缝升级的案例
有一个需求要晚上8点钟进行升级，但是要暂时停止服务，那么要怎么做呢。
有的公司可能会提前挂公告说晚上8点升级，然后让用户8点后不要访问。 但是这个没办法让用户在8点钟之后不放问，用户可能还是会访问
能不能保证在晚上8点钟之后，用户还是访问，但是我们也不提供服务能力，一切在控制范围之内呢。
一般请求的路径如下：
假设网关有热切换的能力，那么在20：00的时候，启动开关，然后在开关打开之后的请求有另外一种方式处理，比如说拒绝或者重定向到公告页。 所谓的开关即一个配置中心的配置。 那么如何判断请求处理完了呢？一般前端的请求都会设置一个超时的时间，在时间之后的请求要不处理完就超时了。所以在超时时间之后，就认为没有影响升级的请求了。
如果网关不具备热切换能力，这个时候可以通过Linux的iptables控制请求只出不进。
# 防火墙命令 iptables -A INPUT -s 0.0.0.0 -j DROP
最后
在技术的道路上还有很多难题需要解决，高可用不仅仅是一种工程的实践，更是一种科学，对个人来说则是升职加薪的衡量指标，一定要重视啊。
参考
注：
本文独家发布自金蝶云社区
推荐阅读