基于 SQL Server 2008 Service Broker 构建企业级消息系统

1、引言

Microsoft 在 SQL Server 2005 引入了服务代理 （Service Broker 简称 SSB） 为技术支持代理设计模式和面向消息的中间件 (MOM) 的原则。Service Broker 在 SQL Server 2008 上得到完善, SQL Server Service Broker 为消息和队列应用程序提供 SQL Server 数据库引擎本机支持。这使开发人员可以轻松地创建使用数据库引擎组件在完全不同的数据库之间进行通信的复杂应用程序。开发人员可以使用 Service Broker 轻松生成可靠的分布式应用程序。使用 Service Broker 的应用程序开发人员无需编写复杂的内部通信和消息，即可跨多个数据库分发数据工作负荷。因为 Service Broker 会处理会话上下文中的通信路径，所以这就减少了开发和测试工作。同时还提高了性能。

企业系统和网站系统都需要处理大量的邮件、短信等消息通知系统。在进行系统设计时，除了对安全、事务等问题给与足够的重视外，性能也是一个不可避免的问题所在，必须充分地考虑访问量、数据流量、服务器负荷的问题。解决性能的瓶颈，除了对硬件系统进行升级外，软件设计的合理性尤为重要。对于一些实时性不是很高的模块我们可以使用了消息队列技术来完成异步处理，利用消息队列临时存放要操作的数据，将队列的数据进行异步的处理。本文基于 SQL Server 2008 Service Broker、WCF、Windows 服务以及调度框架 Quartz.NET 实现一个消息通知系统。

2、消息队列

2.1 队列在异步运作的架构中是非常常用的数据结构

基于消息的应用程序的工作方式是提交一条消息，应用程序执行其工作。然后，再检查看是否收到确认消息已得到处理的信息。如果你的应用程序充满了待处理的请求，通常应该增加另外一条处理队列来缓解系统的总体处理压力。微软消息队列（MSMQ）提供一个开发这类应用程序的框架。它使得应用程序可以在不同种类的网络间进行通信，并且需要保证消息传送（guaranteed message delivery）、路由和可配置安全。过去 20 年来，我们对关系数据库系统的依赖程度显著增加。最初，存储数据并对数据进行某种处理，是建立商业关系数据库系统的主要目的。随着关系数据库系统的发展，其功能和复杂性的变化，它的主要用途已由单一数据存储转变为更加主流的商业智能目的、更加复杂的 ETL 处理、数据报告、数据通知；微软认为，允许你在数据库内建立基于消息的应用程序，这样才有意义。Service Broker 是 SQL Server 2005 中新添加的基础程序，在 SQL Server 2008 上得到加强，主要用于在数据库引擎内建立基于消息的应用程序。SQL Server Service Broker 是以数据表来实现队列，并提供标准的 T-SQL 操作方式，让系统设计人员可以善用消息沟通的特色设计应用程序。Service Broker 应用程序以松散连接的应用程序而开发，它具有高度可扩展性，并提供其它消息平台所不具备的功能，如消息组协调和锁定。这些应用程序充分支持事务，并能够跨越数据库实例和服务器。SQL Server 2008 Service Broker 支持的消息可以达到 2G，支持 SQL 的 varbinary 和 varbinary(max) 数据类型，支持消息优先级，而且“饥饿机制”保障较低优先级的消息也有机会获得发送。

2.2 消息系统架构

消息的整体架构上分为三部分，消息系统客户端，消息队列系统，消息队列发送程序，序列图如下：

客户端准备好消息，通过消息客户端接口发送到消息队列系统，消息队列发送程序定时轮询获取消息进行发送，发送的过程中发生错误重新放入队列，发送成功的队列归档到消息数据库。以邮件发送为例在具体的实现的流程如下：

上述多个部分协作，共同完成消息的发送任务，在本实现方案总共有六个部分，以下对这几个部分进行详细描述。

1. 消息体 MessageBase
   自定义消息体的好处很多，采用自己定义的格式可以节省通信的传递量等等, 也是这个消息系统的消息合约。

上面图中我们可以看到我们定义了 3 种常见的消息类型：邮件、短信和 RTX（腾讯通 RTX 是腾讯公司推出的企业级即时通信平台），可以根据需要灵活的扩展企业消息的类型。

5. 客户端组件
   客户端组件负责验证消息和将消息输入消息队列系统，为了支持在整个企业环境提供服务，采用 WCF 方式发布，采用 TCP 和 SOAP 方式发布，TCP 方式的客户端通过.NET 组件包发布，另外通过 SOAP 方式发布的标准 Web Service 支持其他跨平台 (C++/Java/PHP/Python/Ruby) 的调用，同时为调用进行服务的验证，需要使用消息服务的业务系统首先需要在系统中注册，获得服务调用的 appkey，通过 SOAP Header 进行传递，服务端依据系统的注册信息（appkey 和注册的系统服务器 IP）进行验证。

6. SQL Server 2008 Service Broker 队列系统
   SQL Server 2008 Service Broker 支持会话优先级，可以支持 1 到 10 的 10 个优先级，为目标服务创建 10 个优先级，只有一个约定，但每个级别都有单独的发起方服务。所有发起方服务都与一个中心目标服务通信。在系统的中分配了高 (8) 中 (5) 低 (2) 三个优先级, 消息也有一个优先级高 (1) 中 (0) 低 (-1)，进入消息系统的优先级等于系统优先级 + 消息优先级，这样就使用了 1-9 优先级，10 优先级为系统保留优先级，这样就可有效的利用 Service Broker 的优先级和控制业务系统对消息优先级的使用。

7. 消息处理器
   消息处理器从队列中取出消息，进行发送处理，发送失败的消息重新放回队列，并增加重试次数计数，当重试计数超过最大的重试次数，进行归档处理，发送成功的消息进行归档处理。每个月的数据分表存储，避免数据量过大的系统性能损耗。

8. 消息队列调度器
   消息队列的调度采用 Windows 服务承载，使用 Quartz.NET 进行作业的调度。Quartz.NET 是一个开源的作业调度框架，是 OpenSymphony 的 Quartz API 的.NET 移植，它用 C#写成，项目地址是 http://quartznet.sourceforge.net。它提供了巨大的灵活性而不牺牲简单性。你能够用它来为执行一个作业而创建简单的或复杂的调度。它有很多特征，如：数据库支持，集群，插件，支持 cron-like 表达式等等。 消息的处理器包装成 Quartz Job 加入调度系统。通过添加一系列的消息发送 Job 来加强消息发送的扩展性。Quartz.net 本身支持集群性部署，结合 Service Broker 的分布式架构和 Quartz 的分布式部署就可以达到系统扩展性。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。