服务保护

我心中的服务保护

做服务保护已经很长时间了，记得来公司大概1个月后，就去服务保护这个团队进行开发了。可以说服务保护伴随了我的成长，也可以说我陪着服务保护这个项目走完了他的开始到结束。

服务保护项目是什么

简答来说服务保护项目就是为了保证服务的稳定性而出生的一套保护方案。包括降级，限流，故障演练和预案等多重功能。

为什么要做服务保护

简单来说在线上环境任何依赖的中间系统我们都可以认为是不可靠的，例如数据库有可能会down机。例如缓存有可能会down机，但是面对这些问题我们的系统需要有能力做到减少故障时长，快速降级。引用Hystrix框架

复杂分布式体系结构中的应用程序具有许多依赖关系，每个依赖关系在某些时候都不可避免地失败。如果主机应用程序不与这些外部故障隔离，则有可能被拆除。

例如，对于依赖30个服务的应用程序，每个服务的正常运行时间为
99.99％，以下是您所期望的：

99.99 30 = 99.7％正常运行时间
10亿次请求中的0.3％= 3,000,000次故障
即使所有依赖关系都具有出色的正常运行时间，每次宕机时间仍然为2小时> 以上。

现实通常更糟糕。

即使所有依赖性都能很好地发挥作用，如果您没有设计整个系统的弹性，那么几十项服务中每项服务的停机时间甚至达到0.01％的总体影响等同于每月停机时间可能达到的小时数。

降级

面对非核心流程我们需要有能力快速的切换降级问题服务，例如缓存的tair有问题了，我们需要降级到redis。例如某个下游非核心服务有问题了，我们需要快速对其降级。

解决痛点：基于记录，并操作ZK进行配置变更，流程长，降级速度较慢。

痛点

限流

为什么要做限流呢？主要是因为针对非核心流程我们可以进行降级的操作，但是针对核心流程，例如订单创建这种写入数据库的流程或者交易相关记录交易信息的流程，我们不可能进行降级操作。为了保证主流程的稳定性，我们需要对其进行限流，保证系统的吞吐量在我们系统可以支撑的范围只能，防止超高流量把系统打垮。

解决痛点：瞬时高流量冲击，瞬时超高流量对业务系统的冲击太强，RPC请求下游放大，造成系统雪崩。

痛点

故障演练

现在我们的开发同学基本上大部分时间都在讨论需求，写代码，很少有时间去好好锻炼自己线上排查问题的能力，而针对一个大型的系统来说，每次发生问题都可能是大问题，如果没有处理线上问题的经验，就无法果断的切换降级开关，那么线上问题就会越来越麻烦。所以针对这个痛点我们开发了故障演练模块，模拟线上的故障，丰富开发同学处理线上问题的能力。

解决痛点：开发同学缺乏故障降级经验，线上重大故障较少，开发同学缺乏针对重大故障降级的经验。

痛点

降级预案

降级预案，顾名思义这个是一个降级功能的组合，为什么要有这个组合呢？这个主要是针对于某类故障的发生，快速降级某类故障，例如在不同的服务中，都会对某一个tair集群进行访问，那么如果这个Tair集群发生问题了，我们怎么办呢？一个一个处理分布在不同服务中的开关？然后在过程中还不知道要设置什么值。这个时候如果在故障发生前总结好预案，就可以在问题发生之前快速的进行处理问题了。

解决痛点：针对某类功能进行降级的时候，一个一个操作ZK会浪费很多时间。

痛点

服务保护可以做什么

说到可以做什么，我认为服务保护的思想在任何一个互联网公司都是需要具备的。

事故前

事故前我们需要做好准备，什么叫准备，就是我们要主动创造困难培养自己应对线上问题的能力。
通过服务保护的故障演练模块，主动制造故障，锻炼开发同学解决线上问题的能力，这样当线上着火的时候我们就可以快速的切换开关执行预案甚至进行限流了。

事故中

事故发生了，在不发版的情况下唯一可以改变线上运行状态的就是开关了，通过扳动开关我们可以进行降级操作，操作预案完成对于整个功能的降级。通过执行限流操作，抵抗大批量的流量，防止服务被大流量打挂。

事故后

通过事故后，总结故障演练场景，丰富预案的开关，从而完成针对某一种类型故障的快速解决方案，为线上稳定性建设添砖加瓦。