Service Broker 的作用
Service Broker 可帮助开发人员构建异步的松散耦合应用程序,在这些应用程序中彼此独立的组件相互配合来完成一项任务。这些应用程序组件会交换包含完成任务所需信息的消息。本主题将介绍 Service Broker 的下列内容:
会话
消息排序和协调
事务性异步编程
支持松散耦合应用程序
Service Broker 组件
会话
Service Broker 是围绕发送和接收消息这一基本功能设计的。每个消息都构成某个“会话”的一部分。每个会话都是一个可靠的持久性通信信道。Service Broker 要求每个消息和会话都必须具有一个特定的类型,以帮助开发人员编写可靠的应用程序。
通过新增的 Transact-SQL 语句,应用程序可以可靠地发送和接收这些消息。应用程序向“服务”发送消息,“服务”是一组相关任务的名称。应用程序从“队列”中接收消息,“队列”是一个内部表的视图。
同一任务的消息是同一会话的一部分。在每个会话中,Service Broker 保证应用程序对每个消息只接收一次,并按照消息的发送顺序来接收消息。实现某个服务的程序可以与“会话组”中此服务的相关会话相关联,详细信息请参阅 Service Broker 的优点。
基于证书的安全机制有助于保护敏感消息并控制对服务的访问。如果进行类比,Service Broker 就像是邮政服务。若要与远方同事展开会话,您可以通过邮政服务发送信件进行联络。邮政服务对信件进行排序和投递。然后,您和您的同事从邮箱中取出信件、阅读它们、撰写回信并发送新的信件,直至会话结束。信件传递是异步的,也就是说您和您的同事同时可以处理其他任务。
就像利用邮政服务那样,程序可以使用 Service Broker 支持与其他程序之间的异步会话。Service Broker 消息的作用与信件相似。Service Broker 服务就好比是邮局投递信件的地址。队列就好比是在信件投递后用于保存它们的邮箱。应用程序接收消息、对消息进行操作,然后发送响应。
当某应用程序向 Service Broker 服务发送消息时,它与会话另一端的应用程序的实现细节是隔离的。这样,就可以在不影响发送应用程序的情况下,对接收应用程序进行动态重新配置或用新代码替换它。甚至可以暂时关闭接收应用程序,唯一的影响是 Service Broker 将在接收应用程序重新启动之前不断向其队列中添加新消息。
消息排序和协调
Service Broker 在处理队列(一种常见的数据库编程方法)时,主要在两个方面与传统产品存在不同:
Service Broker 队列集成在数据库中。
队列对相关消息进行协调和排序。
集成队列意味着日常的数据库维护和管理会将 Service Broker 包括在内。通常,管理员无需进行与 Service Broker 有关的日常维护任务。
Service Broker 框架提供了一个用于收发消息的简单 Transact-SQL 接口,以及用于确保消息传递和处理的一系列强有力保障。Service Broker 保证程序按照消息的发送顺序而不是消息进入队列的顺序接收消息,并且会话中的每个消息只接收一次。传统队列产品则按照消息进入队列的顺序提供消息。这要求应用程序确定消息的顺序和分组。Service Broker 保证两个队列读取器不能同时处理来自同一会话或同一相关会话组的消息。
每个 Service Broker 会话均有两个端点。开始会话的一端称为发起方;另一端称为目标。每一端都有一个服务:发起方服务和目标服务。每个服务都有一个关联的消息队列。
下面将说明在典型的对话会话中消息的交换过程:
在发起方处:
程序启动对话。
程序生成一个消息,其中包含执行任务所需的数据。
程序将此消息发送给目标服务。
在目标处:
该消息被置于与目标服务关联的队列中。
程序从队列接收消息并执行相应的任务。
程序通过向发起方服务发送消息来进行响应。
在发起方处:
该响应消息被置于与发起方服务关联的队列中。
程序接收响应消息并对其进行处理。
这个循环不断重复,直至发起方由于没有更多要发送到目标的请求而结束会话。
Service Broker 支持为每个对话设置优先级,优先级从 10(高)到 1(低)。这可确保优先级较低的任务不会妨碍优先级较高的任务。可以将 Service Broker 系统配置为提供不同级别的服务。有关详细信息,请参阅会话优先级。
Service Broker 可处理编写消息传递应用程序所涉及的最困难任务。这些困难任务包括消息协调、可靠的消息传递、锁定和启动队列读取器。这使数据库开发人员能够将精力集中在解决业务问题上。
事务性异步编程
在 Service Broker 基础结构中,应用程序间的消息传递是“事务性”和“异步”的。由于 Service Broker 消息传递是事务性的,因此,如果某个事务回滚,则该事务中的所有 Service Broker 操作都将回滚。这包括发送和接收操作。在异步传递中,应用程序在数据库引擎处理传递的同时继续运行。为了提高伸缩性,Service Broker 提供了一些机制,当处理队列的程序需要进行一些必要的工作时,通过这些机制可自动启动这些程序。有关详细信息,请参阅 Service Broker 激活。
异步编程可以帮助开发人员编写使用队列的应用程序。很多数据库应用程序都包含用作工作队列的表,其中包含当资源允许时所要完成的工作。队列可以为数据库应用程序带来两个优点:
应用程序可在将用户的工作请求置于队列中之后立即响应交互式用户。应用程序在响应之前不必等待完成所有与请求关联的工作。进入队列的请求在资源可用时会被处理。这使得数据库既可保持对交互式用户的响应又可有效使用可用资源。
单个请求涉及的工作有时可以分为多个工作单元,每个单元都作为单独的事务进行处理。这时候,数据库应用程序可通过将请求置于队列中来启动每个工作单元。Service Broker 扩展了此概念,使应用程序可以将工作分散到不同计算机上的多个 Service Broker 实例中。
编写应用程序来对队列中的项目进行正确排序和处理通常比较复杂。开发人员可以使用数据库引擎中内置的 Service Broker 功能来简化成功实现数据库队列所需的编码工作。
支持松散耦合应用程序
Service Broker 支持松散耦合应用程序。松散耦合应用程序由多个相互间独立发送和接收消息的程序组成。这样的应用程序必须包含相同的交换消息定义,并且必须为服务之间的交互定义相同的总体结构。不过,此类应用程序不必同时运行,不必在相同的 SQL Server 实例中运行,也不必共享实现细节。应用程序不必知道会话中其他参与者的物理位置或实现细节。
Service Broker 组件
Service Broker 有三种类型的组件:
**会话组件。**会话组、会话和消息构成 Service Broker 应用程序的运行时结构。应用程序将消息作为会话的一部分进行交换。每个会话都是会话组的一部分;一个会话组可以包含多个会话。每个 Service Broker 会话都是一个对话。对话就是只有两个参与者交换消息的会话。有关会话组件的详细信息,请参阅会话体系结构。
**服务定义组件。**这些组件是设计时组件,用于指定应用程序所用会话的基础结构。它们定义应用程序的消息类型、应用程序的会话流和应用程序的数据库存储。有关服务定义组件的详细信息,请参阅服务体系结构。
**网络和安全组件。**这些组件定义了用来在数据库引擎实例之间交换消息的基础结构。为了帮助数据库管理员管理不断变化的环境,Service Broker 允许管理员独立于应用程序代码来配置这些组件。有关网络和安全组件的详细信息,请参阅网络和远程安全。
服务定义组件、网络组件和安全组件是数据库和 SQL Server 实例的元数据的一部分。会话组、会话和消息是数据库所包含的数据的一部分。