需要协调的事情交给我
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响应方式
“东西交给了我，您放心”
在SQL Server 2000中管理员已经能够通过多种方式完成保证数据可用性：用复制来创建一个数据库克隆、通过Archive Log重建数据库、备份和恢复。
微软在SQL Server 2005又引入了一个新的机制，它可以实现自动的错误恢复，同时允许将一个SQL Server中的数据库内容镜像到另一个SQL Server，同时它还提供了故障过程中通过镜像快速进行错误恢复的支持。数据库镜像是将数据库处理从一个SQL Server数据库移动到不同SQL Server环境中的另一个SQL Server数据库中。镜像的拷贝是一个备用的拷贝，不能直接访问，只用在SQL Server错误的情况用于恢复。
Mirroring工作机制
要进行数据库镜像所需的最小需求包括了两个不同的SQL Server运行环境——Principal Server 和 Mirror Server。Principal数据库就是实际使用的数据库，Mirror数据库是数据库的备用拷贝。当事务写入你的Principal服务器的时候，它们也同样被传送到并写入Mirror数据库中。
除了Principal Server和Mirror Server之外，还可以引入另一个可选的组件——Partners。Partners数据库是第三个SQL Server 2005运行实例，它在判断什么时候进行错误恢复，用于Principal Server和Mirror Server之间内部交流。有了Partners就可以实现的自动的错误处理。
Mirroring主要可以采用如下三种方式工作。
高可用：这个操作模式选项允许在两台服务器上同步事务写入，并支持自动错误恢复。要使用这个选项，你必须还要使用一个Partners服务器。
高数据保护：这个选项可以在两台服务器上同步事务写入，但是错误恢复是手工的。因为自动的错误恢复不是这个选项的一部分，所以也不会用到Partners服务器。
高性能：这个选项不关心两台服务器上的写入是否是同步的，因此在性能上有所提高。当使用这个选项的时候，你只能假设镜像服务器上的所有事情都是成功完成。这个选项只允许手工的错误恢复，因此不会用到Partners服务器。
但是，笔者一般建议对于企业的敏感数据可以考虑采用高数据保护方式，尤其是那些对于企业业务控制比较关键的参数数据，虽然修改频率和数据量都不大，但是一旦丢失对业务的影响很大；对于生产OLTP业务数据还是考虑采用高可用的方式。当然具体如何使用最后还要基于业务代价计算后决定。
通知服务就是一个按照您的要求把消息告诉您的机制，通过它可以把您需要的通知以定义好的格式呈现在各种设备上。通知服务笔者认为和以前的BP机、现在的短消息有很多可比性，虽然多了会犯愁，但是无论如何最起码Sender还是要看看。
通知服务可以应用于如下应用优势：
比起网站公告、电子邮件等方式，通知服务可以以更为迅速的方式（短信、语音短信，笔者认为通过扩展彩信机制也不是难题）通知领导、合作伙伴或者关键人员相对重要的事件。
通过经常性的联络，可以通过向客户及时提供他们需要的通知，增进客户关系。
可以增加IT服务的主动性。
执行过程
从实现上讲，通知服务很类似复制，它采用的也是一个基于“出版/预定”模式的主动信息提供结构。笔者这里举个现实的订阅报刊的例子来说明通知服务的执行过程。
1． 首先，每年年底邮局会寄给我们报刊订阅单，其中说明了可以提供的报刊杂志，我们根据喜好和价格选择自己需要的报刊，然后邮局把这些订阅意向反馈给各个出版社。
文章来源于领测软件测试网 https://www.ltesting.net/
