【IT168 技术文档】

    需要协调的事情交给我

    SQL Server 2005中增加了一个全新的组成——Service Broker，它主要提供了一个以异步方式操作与协调各方的平台，其本身提供了扩展性、安全性、事务性的很多支持。以往为了完成类似的平台支持，很多企业需要购买价格不菲的第三方中间件产品，Service Broker提供了跨越进程、应用、服务器甚至是网络的分布式处理能力。通过Service Broker的异步处理能力可以减少交互过程的用户等待时间，提高整体业务应用的吞吐率，尽管它的处理方式是异步，但是所有的操作是基于一个可信的消息通道完成的，对于每个功能单元内部的处理异常也有很多强力措施保证。 

    Service Broker的主要技术优势如下：

 （1）进一步增强SQL Server 2005集成应用的性能
 （2）简化SQL Server管理
 （3）简化协作性消息的处理
 （4）提供更为松散的应用架构
 （5）通过消息锁机制保证多个应用实例可以处理同一队列的消息
 （6）自动的根据消息处理数量激活处理实例

    Service Broker的技术架构

    Service Broker由三类组件组成，如下说明。

 会话组件（Conversation components）：主要完成运行过程中的消息交换。

 服务定义组件（Service definition objects）：主要在设计态定义消息类型、会话交换流程和应用相关信息的数据库存储。

 路由和安全控制类组件（Routing and security components）：主要用来定义和支持消息交换的外部运行环境。 

    从外层看，笔者认为Service Broker是微软花了大力气在.Net和SQL Server平台上开发的具有Message Queuing支持的COM+服务，他把很多以往通过“Request-Response”方式很难完成或者完成成本很高的处理承担下来。

    消息的交换

图1：两个Service间的会话过程

    对于开发人员而言，整个会话过程可以视为在一个非常可靠的消息通道内交换消息，而这个可信通道的建立则是按照非常类似TCP协议的方式，其中也增加了一个Timer进行生命期的管理。商业应用中往往需要对发送的消息提供回执，因此日后读者如果需要开发这种具有业务连贯性动作的应用，则可以完全依赖Service Broker内置建立的这种可信通道完成。出于效率、安全性等多方面考虑，Service在处理本地调用与跨Instance调用的时候，采用的是不同的方式：本地调用时，需求服务与响应服务共同使用同一个队列，不同Instance时需求服务需要通过双方各自的队列与响应服务进行交互。

图2：不同的Service Broker响应方式