转载

谈服务流量控制

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

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

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

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

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

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

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

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

原文 http://blog.sina.com.cn/s/blog_493a84550102we6k.html

正文到此结束