对于服务流量控制往往是ESB平台实现SLA和Qos管理的一个重要内容，对于业界主流的商用ESB总线产品基本包括了服务流量控制的内容，下面简单谈下服务流量控制的一些重点。

首先看下对于服务流量应该包括两个层面的内容，一个是服务单位时间调用的并发量，一个是服务单位时间调用的消息报文的数据量。对于有些服务虽然调用的频率不高，但是如果调用传递的数据量很大仍然会影响到ESB总线整体性能，因此也需要进行专门的流量控制。其次对于流量控制本身而言，可以对ESB服务总线所有的服务调用总量进行控制，也可

其次对于流量控制本身而言，可以对ESB服务总线所有的服务调用总量进行控制，也可以按具体的服务域控制，最细粒度应该还可以单独控制到每一个服务。当控制到单个服务的时候，我们可以在流量控制策略的时候更好的和服务的SLA等级定义进行绑定。

最后，对于服务的流量控制往往包括了入口流量控制和出口流量控制两个层面的内容，对于入口流量控制往往比较容易理解，即当触发流量控制策略后直接在服务调用访问的时候就Reject掉而不再进行处理。而对于出口流量控制最重要的目的是对于服务提供方系统往往存在单位并发下处理能力的瓶颈，而这个时候刚好可以利用ESB中的消息中间件和MQ机制，控制向目标的数据流入速度。

对于整个流量控制的技术实现方式往往通用的做法仍然是在ESB服务总线的服务调用中增加inBound和outBound处理插件和拦截器，在插件中实时的获取到服务调用次数和服务调用数据量信息，然后再内存中进行计算，当满足了流量控制策略后即实时出发流量控制。

对于ESB服务总线集群化部署的时候可以看到，要对ESB总线调用服务进行流量控制就需要考虑内存实时计算的次数和数据量的结果不能存储在单台计算节点上，而需要考虑集中化内存存储。基于这个思路，一个关键的实现策略即是可以结合分布式缓存来实现内存计算结果的存储。

在分布式缓存实现过程中，由于存在对缓存数据的多点并发写入和更新问题，很容易引起脏读或脏写，为了解决这个问题可以引入分布式并发锁机制来解决一致性问题，但是当增加了锁机制后带来的就是影响到整个服务的调用性能。因此是否真正引入锁机制还需要进一步权衡。

另外一种实现方法即是对于分布式缓存数据的读写进行分离操作，即各分布式ESB计算节点仍然从分布式缓存读取数据，但是各个计算节点在通过业务拦截器获取到服务调用次数和数据量信息后首先写入到集中的一个消息中间件中，然后由消息中间件处理后再统一更新缓存信息以避免发生并发更新情况。

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

1. 服务限流：取消某个消费方对某个服务的访问授权，只单个消费方受影响

2. 服务熔断：直接对该服务进行下线处理，或将该服务状态设置为不可用，所有消费方受影响

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

1. 运行次数：单位时间里面的运行次数累计，比如一个消费方大并发调用，可以限流

2. 业务系统异常次数：即源服务出现异常的次数，也可以考虑异常占比率

3. 系统异常：即出现系统级异常次数，本身包括Token失效，也包括ESB总线本身故障

4. 报文量：即单位时间内传输的报文量达到某个值，考虑是输入+输出报文量和的累计

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

1. 限流：运行次数，Token失效，报文量

2. 熔断：业务系统异常，系统ESB本身故障异常

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

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