再谈服务限流和熔断(6.20)

标签： IT咨询 | 发表时间：2019-06-20 10:35 | 作者：人月神话
出处：http://blog.sina.com.cn/cmmi
对于服务限流和熔断，在我博客前面文章中已经多次谈到，今天还是对实现思路做一个进一步的总结。

对限流熔断的理解，首先本文谈到的服务限流和熔断，和常规我们说的限流和熔断有区别，具体说明为：

1. 服务限流：取消某个消费方对某个服务的访问授权，只单个消费方受影响
2. 服务熔断：直接对该服务进行下线处理，或将该服务状态设置为不可用，所有消费方受影响

其次，对于服务流控我们需要设置具体要监控哪些指标，注意这个指标监控是在单位时间里面的监控指标，即计算在单位时间的累计数据，当触发后即进行流控。具体包括：

1. 运行次数：单位时间里面的运行次数累计，比如一个消费方大并发调用，可以限流
2. 业务系统异常次数：即源服务出现异常的次数，也可以考虑异常占比率
3. 系统异常：即出现系统级异常次数，本身包括Token失效，也包括ESB总线本身故障
4. 报文量：即单位时间内传输的报文量达到某个值，考虑是输入+输出报文量和的累计

对于运行时长更多是预警，而实际上直接限流和熔断不现实。因此主要的流控指标就是上面这些，基于以上指标本身又有两种操作，一种是限流，一种是整个服务熔断。而实际上可以看到。

1. 限流：运行次数，Token失效，报文量
2. 熔断：业务系统异常，系统ESB本身故障异常

限流熔断解除，最后，在还需要考虑的就是在实施了限流和熔断后如何解除的问题，在实际实现的时候，对于限流可以在规定时间后自动解除，而对于熔断最好还是人工恢复解除。即比如对CRM系统访问MDM的查询供应商服务进行限流后，在启动限流后的某个时间间隔后，比如2小时后，可以自动进行解除。这个时间间隔可以灵活配置。

以上限流和熔断实现基本可以满足我们大部分的业务需求场景，同时本身又对ESB总线和业务系统实现保护作用，防止出现大并发大数据量的调用出现的影响。当然对于限流也可以人工进行恢复，人工恢复好处是可以跟踪到消费方端是否已经修改了消费方法，当确认修改后再进行重新授权恢复调用。

我们结合本文最前面的图来说明下整个实现过程

前期已有和已经实现的工作有

1. 所有的服务消息调用实例日志数据全部入JMS，再异步写入到数据库。
2. 运行每分钟的定时任务，将实例日志汇总为分钟级的统计表，Group By 消费方ID+服务ID

接着我们来看，需要增加的实现过程

1. 构建一个服务限流熔断实时记录表集合，暂约定为集合A
    1.1 在内存中记录，可以不入库
    1.2 表应该包括字段为消费方ID，服务ID，开始记录时间，数据量累计，次数累计，异常累计

2. 再增加一个定时任务，每分钟执行一次
   2.1 找到最近1分钟配置了限流熔断的服务信息，提出一个服务子集合B
   2.2 对集合B进行循环，判断集合B里面的的记录行是否在集合A中能够检索到
       2.2.1 如果检索不到，增加一行
       2.2.2 如果检索到，判断当前时间-开始记录时间是否大于统计时间间隔
          a) 如果小于间隔，则对所有数据进行累加处理
          b) 如果大于间隔，则对该行数据进行擦写重新计数，开始记录时间为当前新时间
   2.3 对该行处理数据进行判断，是否满足了限流熔断条件？
       1.3.1 如果满足限流条件，则对该消费方取消对该服务的授权，记录限流状态和限流开始时间
       1.3.2 如果满足熔断条件，直接对该服务进行熔断，标记状态，并记录熔断时间

3. 再增加一个定时任务，可以每1分钟运行一次，进行限流解除操作
    3.1 对集合A里面的数据进行循环，找到当前状态为限流或熔断的服务
    3.2 判断当前时间-限流开始时间是否大于设置间隔，如果大于并超时，就进行限流恢复

该实现思路存在的问题点

注意该实现思路并非是基于流处理模式的，可以持续监控连续的时间间隔下面是否出现了超过指标阈值的情况，即我们在数据处理的时候也不是持续的去取最近1个时间的汇总数，如果这样处理本身会消耗更多的资源和性能。考虑到实际应用场景，虽然没有实现连续的流监控，但是基本能够满足限流熔断需求。

 

相关 [服务] 推荐：

服务禁语

- tiancaicai - 白板报
前几天在一个公交汽车站拍到了一张规定，里面规定了服务禁语和礼貌用语，看了大乐. 3、乘车高峰车厢内拥挤时，禁语：“快往里走，站在前面又没有钞票检. ”文明语：“请尽量往里走，照顾没有上车的乘客”. 4、车子抛锚，禁语：“车子抛锚没有办法，人都要生毛病的，车子坏了也正常. ”文明语：“对不起，车子出现故障修一下，请大家理解.

服务熔断

- - CSDN博客推荐文章
服务熔断也称服务隔离，来自于Michael Nygard 的《Release It》中的CircuitBreaker应用模式，Martin Fowler在博文 CircuitBreaker中对此设计进行了比较详细说明. 本文认为服务熔断是服务降级的措施. 服务熔断对服务提供了proxy，防止服务不可能时，出现串联故障（cascading failure），导致雪崩效应.

面向服务与微服务架构

- - CSDN博客推荐文章
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices， 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务，和我最近几年工作的实践比较相关感觉深受启发. 本文吸收了部分原文观点，结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构 SOA 思想概念的提出已不是什么新鲜事，大概在10年前就有不少相关书籍介绍过.

经理服务生

- netcasper - 坏脾气的小肥
2007年的时候，我和内容团队一起去报道上海车展，累得够呛，写稿子到凌晨一两点，早上八点钟又要爬起来去现场或更新早班. 有天上午，编辑都挤在大会议室里忙活着整理、发布、撰稿，而我搞完了竞品检查/数据分析/计划修订，一时间闲着，就打算去买些零食给大家. 环顾四周，没人有空，只好自己下楼，嘿咻嘿咻拎了两三百块钱的零食上来.

Kernel.org恢复服务

- Adam - Solidot
kernel.org 王者归来 写道 "Linux内核官网在八月份遭入侵，之后于9月11日linux.com linux.org kernel.org LinuxFoundation.org皆无法访问，进行安全维护. 经过紧张的修复，kernel.org终于恢复服务. LinuxFoundation.org也可以正常访问.

谈领域服务

- - 人月神话的BLOG
对于跨系统和模块间的SOA服务识别和分析我前面文章谈的比较多，这块的SOA服务重点是实现跨系统和模块的业务交互和协同，而对于领域服务而言则更加关心的是对于单个系统或模块，其应该如何抽象领域对象并将其能力以粗粒度服务方式保留给应用层用. 在领域建模中的整体思路中，我们做两个层面的理解，其一是领域模型层重点是隔离传统的数据表并抽象为领域对象；而对于领域服务层重点是则将应用层和领域模型层解耦，模型层提供的能力是以领域服务的方式暴露到应用层使用的.

DNS服务-详解

- - 操作系统 - ITeye博客
DNS（Domain Name System）域名系统，在TCP/IP网络中有非常重要的地位，能够提供域名与IP地址的解析服务. <1> 客户机提交域名解析请求，并将该请求发送给本地的域名服务器. <2> 当本地的域名服务器收到请求后，就先查询本地的缓存. 如果有查询的DNS信息记录，则直接返回查询的结果.

初识微服务

- - ITeye博客
微服务架构越来越火，有必要学习一下. 软件开发过程中碰到什么问题. 一个简单的应用会随着时间推移逐渐变大. 在每次的sprint中，开发团队都会面对新“故事”，然后开发许多新代码. 几年后，这个小而简单的应用会变成了一个巨大的怪物. 一旦你的应用变成一个又大又复杂的怪物，那开发团队肯定很痛苦. 敏捷开发和部署举步维艰，其中最主要问题就是这个应用太复杂，以至于任何单个开发者都不可能搞懂它.

TopBeat服务安装

- - ITeye博客
TopBeat是一个简单的服务器数据采集脚本，已经获取服务器进程的CPU，内存，磁盘使用数据. 并将数据输出到ElasticSearch，Redis等服务中，非常的简单易用. 1.下载TopBeat.     修改topbeat.yml,中的localhost，改成ES主节点IP 192.168.100.92.

Google  的 favicon 缓存服务

- 小猫 - 我爱水煮鱼
在添加友情链接或者其他操作的时后需要应用其它网站的图标（favicon），如 iPad 网址导航，如果一个一个去找会非常麻烦，Google　提供了一个比较快速得到相应网站 favicon 的服务，使用下面的　URL　调用　GOOGLE　的　favicon　缓存，将后面的域名改成相应网址即可，没有favicon的网站会显示一个小地球.