高可用已经成为互联网公司的标配,如何实现高可用呢,首先这不是一个很容易就解决的问题,如果说仅仅是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
最后
在技术的道路上还有很多难题需要解决,高可用不仅仅是一种工程的实践,更是一种科学,对个人来说则是升职加薪的衡量指标,一定要重视啊。
参考
注:
本文独家发布自金蝶云社区
推荐阅读