先前有一篇博文，梳理了流控服务的场景、业界做法和常用算法
统一流控服务开源-1：场景&业界做法&算法篇
最近完成了流控服务的开发，并在生产系统进行了大半年的验证，稳定可靠。今天整理一下核心设计和实现思路，开源到Github上，分享给大家
https://github.com/zhouguoqing/FlowControl
一、令牌桶算法实现
先回顾一下令牌桶算法示意图
随着时间流逝,系统会按恒定1/QPS时间间隔(如果QPS=100,则间隔是10ms) 往桶里加入Token(想象和漏洞漏水相反,有个水龙头在不断的加水),
如果桶已经满了就不再加了. 新请求来临时, 会各自拿走一个Token,如果没有Token可拿了就阻塞或者拒绝服务.
令牌添加速度支持动态变化，实时控制处理的速率.
令牌桶有两个关键的属性：令牌桶容量（大小）和时间间隔，
有两个关键操作，从令牌桶中取Token；令牌桶定时的Reset重置。
我们看TokenBucket类：
这个抽象类中，将UpdateToken作为抽象方法暴露出来，给实现类更多的灵活去控制令牌桶重置操作。基于此实现了“固定令牌桶”FixedTokenBucket
固定令牌桶在每次取Token时，都要执行方法ShouldThrottle。这个方法中：
并发取Token是线程安全的，这个地方用了Lock控制，损失了一部分性能。同时每次获取可用Token的时候，都会实时Check一下是否需要到达Reset令牌桶的时间。
获取到可用令牌后，令牌桶中令牌的数量-1。如果没有足够的可用令牌，则返回等待到下次Reset令牌桶的时间。如下代码：
以上就是令牌桶算法的实现。我们继续看漏桶算法。
二、漏桶算法实现
首先回顾一下漏桶算法的原理：
‘
水(请求)先进入到漏桶里，漏桶以一定的速度出水(接口有响应速率),
当水流入速度过大会直接溢出(访问频率超过接口响应速率), 然后就拒绝请求,
可以看出漏桶算法能强行限制数据的传输速率.
有两个变量：
一个是桶的大小,支持流量突发增多时可以存多少的水(burst),
另一个是水桶漏洞的大小(rate)。
漏桶抽象类：LeakTokenBucket，继承与令牌桶抽象父类 TokenBucket，说明了获取令牌(漏出令牌)在底层的方式是一致的，不一样的是重置令牌的方式（务必理解这一点）
可以看出，漏桶是在令牌桶的基础上增加了二个重要的属性：这两个属性决定了重置令牌桶的方式
stepTokens：每间隔时间内漏的数量
ticksStepInterval：漏的间隔时间
举个例子：TPS 100，即每秒漏出100个Token，stepTokens =100， ticksStepInterval=1000ms
漏桶的具体实现有两种：空桶和满桶
StepDownTokenBucket 满桶：即一把将令牌桶填充满
StepUpLeakyTokenBucket 空桶：即每次只将stepTokens个数的令牌放到桶中
三、流控服务封装
第二章节，详细介绍了令牌桶和漏桶的具体实现。基于以上，要重点介绍接口：IThrottleStrategy：流控的具体方式
有了这个流控方式接口后，我们还需要一个流控策略定义类：FlowControlStrategy
即定义具体的流控策略：以下是这个类的详细属性和成员： 不仅定义了流控策略类型，还定义了流控的维度信息和流控阈值，这样流控就做成依赖注入的方式了！
同时，流控策略类型，我们抽象了一个枚举：FlowControlStrategyType
支持3种流控策略：TPS、Sum(指定时间段内请求的次数)，Delay延迟
面向每种流控策略类型，提供了一个对应的流控器，比如说TPS的流控器
Sum(指定时间段内请求的次数)流控器：
同时，通过一个创建者工厂，根据不同的流控策略，创建对应的流控器（做了一层缓存，性能更好）：
有了流控策略定义、我们更进一步，继续封装了流控Facede服务，这样把流控的变化封装到内部。对外只提供流控服务接口，流控时动态传入流控策略和流控个数：FlowControlService
以上，统一流控服务完成了第一个版本的封装。接下来我们看示例代码
四、示例代码
是不是很简单。
大家如果希望了解详细的代码，请参考这个项目的GitHub地址：
https://github.com/zhouguoqing/FlowControl
同时也欢迎大家一起改进完善。
