高可用系统指南原创
金蝶云社区-艾贺521
艾贺521
3人赞赏了该文章 1,015次浏览 未经作者许可,禁止转载编辑于2019年06月10日 07:08:39


高可用已经成为互联网公司的标配,如何实现高可用呢,首先这不是一个很容易就解决的问题,如果说仅仅是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 架构拆分 服务治理,分为水平拆分和垂直拆分,拆分不是以减少不可用时间为目的,而是以减少故障影响面为目的。因为一个大的系统拆分成了几个小的独立模块,一个模块出了问题不会影响到其他的模块,从而降低故障的影响面。

image.png



服务分级

首先对服务进行分级与进行服务可用性衡量指标类似,分清影响的严重程度,制定不同的方案,核心应用与服务优先使用更好的硬件

比如有以下服务级别标准,每个公司的标准不同,根据自己标准来进行重要程度划分,一般来说核心购买链路不能中断:

服务级别定义标准
一级服务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点钟之后,用户还是访问,但是我们也不提供服务能力,一切在控制范围之内呢。


一般请求的路径如下:

image.png


  • 假设网关有热切换的能力,那么在20:00的时候,启动开关,然后在开关打开之后的请求有另外一种方式处理,比如说拒绝或者重定向到公告页。   所谓的开关即一个配置中心的配置。  那么如何判断请求处理完了呢?一般前端的请求都会设置一个超时的时间,在时间之后的请求要不处理完就超时了。所以在超时时间之后,就认为没有影响升级的请求了。

  • 如果网关不具备热切换能力,这个时候可以通过Linux的iptables控制请求只出不进。

# 防火墙命令
iptables -A INPUT -s 0.0.0.0 -j DROP



最后

在技术的道路上还有很多难题需要解决,高可用不仅仅是一种工程的实践,更是一种科学,对个人来说则是升职加薪的衡量指标,一定要重视啊。


参考


注:

本文独家发布自金蝶云社区


图标赞 3
3人点赞
还没有人点赞,快来当第一个点赞的人吧!
图标打赏
0人打赏
还没有人打赏,快来当第一个打赏的人吧!