分布式系统的故障治理

1、需求分析

监控：

a)需要监控具体那个机器，那个服务发生了问题

b)需要监控到那个用户出现故障，在那个服务调用的级别出现了问题

隔离与降级：

a)容错保护：机器和服务发生了故障，如何保证不影响主要业务的使用

b)过载保护：超过一定的指标要求的时候，可以拒绝后续的服务

2、当前业界发展与现状分析

2、1 阿里的双11的经验

在内部，我们称为叫二套环境。它的核心原理是在基础环境之上，动态区分出一些小环境，他们分别是某个业务的子集。项目之间彼此独立，不会互相调用，只有当依赖的服务不在时，才会去访问基础环境的服务。数据库和缓存是公用的。

下一个问题就是故障规则和业务识别，我们曾考虑在用户请求的入口就打上标记，置入故障规则，不过发现对于post请求，异步js请求，定时任务等都有比较大的改造成本，有安全隐患。 所以就增加了一个服务端，直接下发故障规则到依赖插件上。故障插件通过对流量的调用拦截+业务识别唯一确定影响哪一个请求，然后通过故障规则判断是注入异常还是超时。从而达到模拟故障的效果。 因为插件可扩展的设计，所以我们默认是可以同时注入多种故障场景的。同时插件也会把影响到请求的详细信息异步上报给服务端做分析。

2.2 腾讯的tars方案：

• 容错保护： 容错保护通过两种方式实现：名字服务排除和 Client 主动屏蔽。
• 过载保护： 为了防止业务因为访问量突增或服务器故障造成系统整体的繁忙，进而导致全部服务的不可用，框架内部做相应设计来应对。实现请求队列，服务调用通过非阻塞方式实现异步系统，从而达到提升系统处理能力的目的。并且对队列的长度进行监控，当超过某个阀值，则拒绝新的请求。对请求设置超时时间，当请求包从队列里读取出来是判断请求是否超时，如果超时则不做处理。
• 消息染色： 框架提供了对某服务某接口的特定请求进行染色的能力，染色的消息可以透传到后面需要访问的所有服务上，对染色的请求，服务自动把日志上报到特定的染色日志服务器上，使用者只需在染色服务器上即可分析请求访问的路径，方便跟踪定位问题。
• IDC 分组： 为了加快服务间的访问速度，建设跨地区、跨机房调用带来的网络资源消耗，减少网络故障带来的影响，框架提供了跨地区、跨机房，就近接入的功能。
• SET 分组： 为了方便对业务服务部署管理进行标准化和容量化，框架提供了 Set 部署能力，set 之间没有调用关系，互不干扰，故障隔离，提高运维效率和服务可用性。

2.3 Netflix的Chaos Monkey

     netflix提供的熔断隔离框架Hystrix

2.4 现状分析

阿里和腾讯的框架在实现上，和传统的网管系统相比较，更加深入业务，主要包括：

a)用户请求消息打标记，可以将特定的用户消息从整体消息中分离出来

b)基于消息id整体的访问路径和问题定位

c)服务分组，不同分组之间的服务隔离，腾讯使用set来进行分组，阿里的dubbo框架也有group的概念，如何从接入的用户转发到那个set或者group，各家有各家的解决方案

3、简单的故障隔离系统的选型

a)对服务的隔离采用Hystrix

b)消息分离与监控：

1>采用一个全局分布式id生成组件

2>传输协议中增加一个消息标记类型的字段

3>针对标记的日志，发送到一个集中处理的中心，在中心进行分析

c)接入消息分析：客户端请求的时候，拿到对应列表，可以直接从客户端，根据自己的用户id所属于的区域或者服务进行对应的请求

d)日志收集系选型：通过logstash采集日志到kafka,kafka负责提供数据给Hbase,通过Hbase进行数据分析

4、参考文档：

http://jm.taobao.org/2017/06/22/20170622/   阿里电商故障治理和故障演练实践

http://www.linuxeden.com/a/3013  腾讯开源微服务架构 Tars，高性能 RPC 开发框架

http://www.brendangregg.com/     netflix大牛Brendan D. Gregg的网站

http://www.bijishequ.com/detail/388687?p=   跟着小程学微服务-自己动手扩展分布式调用链

（后续待完善)