前次谈数据集中化和拆分的时分谈到了轻量总线的问题，在这里再对轻量总线的考虑做一个简略的阐明。首要来看下关于一个ESB总线自身的模型简化，如下图:
在这种ESB总线形式下，经过inbound 和 outbound pipeline会做很多的的作业。包含拜访操控，流程操控，协议转化和适配，日志logging等。这些插件自身是可插拔的装备，有些是对音讯头信息的简略处理，有些是需求对音讯体信息进行处理。除去这部分内容，剩余的包含了服务署理，数据处理，服务轻量编列，路由功用等，这些也是中心的ESB功用。
从消费方建议一同服务恳求调用，整个进程能够简化为首要是经过inbound pipeline进行拜访操控，流量操控，进行协议的转化，对输入的信息进行log记载。然后进行实践处理环节，包含proxy service的解包，数据的处理和转化，路由分发；然后进入到供给方实践的服务调用，服务调用完成后关于回来的服务调用信息再进行相关的协议转化和日志记载处理，终究回来成果给服务消费方。
在这个进程中，能够看到整个服务调用数据流都需求在总线上运转和传输，一个是数据量自身很大，一个是每次数据适配和解析都或许是一次功用耗费。针对全新规划的体系建造能够看到，不会有太多的留传体系适配和协议转化问题，在ESB总线上也不会处理太多的数据映射处理和转化作业。一起流量操控自身也不是有必要的功用要求。因而关于简略的总线，其中心功用要点将放在署理服务，路由，日志记载，拜访操控四个中心内容上。
关于上述四个中心内容的完成，根本能够参阅上面的ESB总线模型进一步简化，那总线的瓶颈或许遭到的最大影响便是日志记载这块，在这块开始的思路便是日志记载是接JMS+MQ，关于总线接收到的日志记载进行异步耐久化处理，这样日志记载的瓶颈和功用问题能够减轻。
以上问题都考虑后，是否还能够对总线模型做简化，总线愈加重要的是一致服务目录库（proxy service)的供给，服务鉴权和路由功用。假如只是考虑这些功用，那么整个音讯流是否一定要走在服务总线上？依据这个思路，能够看到在轻量总线上能够进一步考虑操控流和音讯流的进一步别离，如下图：
在这种场景下，消费方对服务的调用由本来的一次调用转化为两次，首要第一次调用传入相关的消费方体系，恳求地址，和音讯头信息。关于总线依据这些信息进行服务鉴权，流量操控，依据proxy找到详细的原始服务供给地址，在这个地方中还涉及到路由。这些内容都处理完成后，依据拿到的方针端信息和操控令牌等信息建议对方针端的直接调用。方针服务供给端也或许涉及到需求和总线交互进行相关的鉴权操作，完成后回来数据信息给服务消费方。
在整个进程中，服务总线上不承载详细的音讯数据流，也不会对音讯流进行协议转化或数据映射处理等。要点仍是完成一致的服务目录库，对服务进行拜访操控和鉴权，依据音讯头参数对方针端进行路由等。因为不承载详细的音讯数据流，服务总线将很轻，即便在大并发量和大数据量下也不会呈现较大的瓶颈。这种总线形式将合适相似技术服务，DaaS数据库服务，数据服务等很多数据传输的场景。
在这种形式下，或许会呈现一个新的问题，即关于服务消费方往往需求两次调用才能够完成。关于这个问题很简略，咱们能够考虑完成了一个前置的轻量ESB服务署理包，在ESB服务署理包中对两次调用进程进行封装，以简化使用对服务的消费。
