谈轻量服务总线

上次谈数据集中化和拆分的时候谈到了轻量总线的问题，在这里再对轻量总线的思考做一个简单的说明。首先来看下对于一个ESB总线本身的模型简化，如下图:



在这种ESB总线模式下，通过inbound 和 outbound pipeline会做大量的的工作。包括访问控制，流程控制，协议转换和适配，日志logging等。这些插件本身是可插拔的配置，有些是对消息头信息的简单处理，有些是需要对消息体信息进行处理。除掉这部分内容，剩下的包括了服务代理，数据处理，服务轻量编排，路由功能等，这些也是核心的ESB功能。

从消费方发起一起服务请求调用，整个过程可以简化为首先是通过inbound pipeline进行访问控制，流量控制，进行协议的转换，对输入的信息进行log记录。然后进行实际处理环节，包括proxy service的解包，数据的处理和转换，路由分发；然后进入到提供方实际的服务调用，服务调用完成后对于返回的服务调用信息再进行相关的协议转换和日志记录处理，最终返回结果给服务消费方。

在这个过程中，可以看到整个服务调用数据流都需要在总线上运行和传输，一个是数据量本身很大，一个是每次数据适配和解析都可能是一次性能消耗。针对全新规划的系统建设可以看到，不会有太多的遗留系统适配和协议转换问题，在ESB总线上也不会处理太多的数据映射处理和转换工作。同时流量控制本身也不是必须的功能要求。因此对于简单的总线，其核心功能重点将放在代理服务，路由，日志记录，访问控制四个核心内容上。

对于上述四个核心内容的实现，基本可以参考上面的ESB总线模型进一步简化，那总线的瓶颈可能受到的最大影响就是日志记录这块，在这块初步的思路就是日志记录是接JMS+MQ，对于总线接收到的日志记录进行异步持久化处理，这样日志记录的瓶颈和性能问题可以减轻。

以上问题都考虑后，是否还可以对总线模型做简化，总线更加重要的是统一服务目录库（proxy service)的提供，服务鉴权和路由功能。如果仅仅考虑这些功能，那么整个消息流是否一定要走在服务总线上？基于这个思路，可以看到在轻量总线上可以进一步考虑控制流和消息流的进一步分离，如下图：



在这种场景下，消费方对服务的调用由原来的一次调用转换为两次，首先第一次调用传入相关的消费方系统，请求地址，和消息头信息。对于总线根据这些信息进行服务鉴权，流量控制，根据proxy找到具体的原始服务提供地址，在这个地方中还涉及到路由。这些内容都处理完成后，根据拿到的目标端信息和控制令牌等信息发起对目标端的直接调用。目标服务提供端也可能涉及到需要和总线交互进行相关的鉴权操作，完成后返回数据信息给服务消费方。

在整个过程中，服务总线上不承载具体的消息数据流，也不会对消息流进行协议转换或数据映射处理等。重点还是实现统一的服务目录库，对服务进行访问控制和鉴权，根据消息头参数对目标端进行路由等。由于不承载具体的消息数据流，服务总线将很轻，即使在大并发量和大数据量下也不会出现较大的瓶颈。这种总线模式将适合类似技术服务，DaaS数据库服务，数据服务等大量数据传输的场景。

在这种模式下，可能会出现一个新的问题，即对于服务消费方往往需要两次调用才能够实现。对于这个问题很简单，我们可以考虑实现了一个前置的轻量ESB服务代理包，在ESB服务代理包中对两次调用过程进行封装，以简化应用对服务的消费。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密