聊聊服务灾备 _服务灾备

2018年，有半年的时间在做服务灾备，由于当时对这一块的知识掌握得比较零碎，直接上手实践，没有较系统地学习，在后续的工作中，通过不断实践+学习补充这一块的知识，以及反思当时的实践，逐渐明白了要做灾备的原因和这么做的理由。在此写下自己的小小总结。

文章插图

为什么要做灾备？当时开始要做灾备的原因，是因为有一次机房A故障了，当时大部分的服务都不可以用：时长上涨、接口失败，原因是：
1、很多服务都部署到A机房了，导致大部分服务不可用
2、服务依赖的数据服务（MySQL、redis）是单点

文章插图

出现的问题表现是：时长上涨和接口失败，导致了页面不可用、服务受损。
这个问题的根本原因是出现服务单点的情况，没有备用的服务可以切换，导致请求/服务上游一直等待，等待一定时间后，就失败了。
知道问题的根本原因后，解决问题的核心方向就是解决单点问题，解决单点问题的方案有：服务冗余（多一份可用的服务），做灾备。
什么是灾备灾备，简单点说，就是生产环境上部署的服务，假如有一个服务（集群）挂了，有另一个地方的同一个服务（集群）可以继续使用。
灾备分主备和双活两种部署。假设有两个机房A、B 。
主备：大部分流量都会到主集群A上，当A挂了，备点B能承担主集群的角色；
双活：流量会平均分配到A、B两个机房，两个机房都能正常对外服务。v
如何做一个合理的灾备怎么去做一个合理的灾备呢？
【聊聊服务灾备】笔者结合自己的工作经历及理论知识，觉得做灾备主要是以下的几点，如果还有其他遗漏的，还望各位指正。
一、业务梳理个人觉得，对于业务方来说，做一个应用的灾备最重要的一点就是业务梳理。理由如下：
1、达到需要做灾备的业务，通常都是存活了有一定时间的业务，这些业务都会由于各种因素而有一些在做灾备时觉得不合理的设计，简称历史原因。这些历史原因有：依赖的服务单点；依赖的数据存储系统单点；依赖的服务无法做灾备等等。这些原因，如果没有解决完，那么业务方也无法完成灾备。
2、不熟悉业务，对里面的逻辑不清楚，就不知道如果服务异常会导致什么问题发生，贸然去做灾备，等到真正有异常时，可能会发现没有达到预期的效果。
业务梳理，需要检查以下几个要点：
1、业务有多少个依赖服务？依赖服务是否还有其他的依赖？
2、依赖服务的灾备情况如何？双活还是单点？
3、依赖服务是否支持重试？重试失败怎么处理？
4、业务使用了什么数据存储系统？部署情况如何？纯DB还是有Redis？主从还是多主？是否支持自动切换主库？
5、业务用到的数据存储系统的灾备情况如何？是否满足灾备？是否支持分布式？
6、依赖的服务是否可降级？降级是否可以返回默认值？返回默认值对业务是否有损？
7、依赖服务多次重试依然失败，是否可以熔断？熔断对业务是否有损？
业务梳理完成之后，再根据对应不满足的点去完成，直到所有情况都考虑完成了或者使用折中的方案来解决。
二、负载均衡负载均衡的意思是将流量负载分布到多台服务器，从而提高程序的性能和可靠性。通过负载均衡技术，可以分发集中的流量，可以解决两种情况：
1、流量暴涨，所有流量到一台机器，将应用拖垮
2、其中一个集群的所有应用挂了，可以将流量转发到另一个集群
注：在笔者实践负载均衡的经历中，使用到最多的就是Nginx的负载均衡配置，将多个集群的机器添加到nginx配置的upstream中， nginx会根据配置文件中指定的策略来分发流量。