SQL Service Broker - 一个中央SQL和更多卫星SQL

Question

该系统由一个中央SQL服务器和两个或多个卫星服务器组成.卫星服务器收集测量数据并将其发送到中央服务器.看图:

(图片来自官方的Service Broker通信协议文章并进行了修改.)

我需要尽可能简单地添加另一个satelite SQL.我的意思是,设置新添加的卫星SQL应该可能与其他卫星SQL机器相同.有可能吗？

所有SQL服务器都位于同一个域中,不需要基于证书的加密 - 至少现在不行.现在优先考虑部署的简易性和速度.在后期阶段可以改善安全性.

换句话说,卫星SQL可以使用相同的消息类型,相同的合同创建代码,相同的端点设置,......

我对路由和目标绑定有点困惑.你能评论一下吗？

Answer 1

最简单的最简单部署是以下配置:

1. 使用相同的消息类型并在每个地方签订合同.这在任何情况下都是必须的,所以有点不言而喻.
2. 不要使用对话安全性.只是GRANT SEND ON SERVICE::[<servicename>] TO [public]无处不在.这消除了对数据库证书和远程服务绑定的需要.
3. 不要使用证书进行端点,但不换的(出口,进口,创建登录等).有一个技巧:GRANT CONNECT ON ENDPOINT::[<brokerendpointname>] TO [public]允许两个端点使用SSL(证书)连接,甚至无需交换证书.
4. 使用传输路由(意味着启用特殊TRANSPORT路由并使用[tcp://hostname:port/servicename]约定命名您的服务.

让我解释为什么我推荐这个设置:

• 删除对话框安全性可简化部署,例如10倍.对话安全性允许服务对每个消息的发送者进行身份验证和自动化,但是在相对受控的环境(Intranet)中,您可以基于信任进行部署:服务接收的任何消息都被信任来自授权发件人.
• 通常认为使用端点证书是复杂的,因为需要交换证书以允许连接,但是public在代理端点上授予连接的技巧消除了交换证书的要求.使用此技巧的所有计算机可以在没有任何先前设置的情况下相互通信,这比在端点上使用Windows身份验证更好(需要授予连接到domain\machine$ro需要使用特定域帐户部署SQL Server实例).同样,您不能在连接上说"否",您将接受来自Intranet中任何 SQL实例的连接.
• 使用TRANSPORT路由任何加入'party'的SQL Server实例都准备摇滚:因为服务名称包含主机名,所有其他机器已经知道如何与该机器通信并且不需要添加显式路由.

这种配置非常接近"即插即用".新计算机可以立即加入与任何现有SQL Server SSB服务的通信,而无需在其他现有计算机上进行任何配置更改.

以下是如何为此类部署配置计算机的示例.假设您要从部署中央服务器开始MACHINE1:

use master;
go

create database master key...
create certificate [MACHINE1] with subject 'MACHINE1';
create endpoint BROKER as tcp (listener_port 4022) for service_broker 
  (authentication certificate [MACHINE1]);
grant connect on endpoint::BROKER to [public];
go

use db1;
create message type...
create contract ...
create queue ...
create service [tcp://MACHINE1:4022/CentralService] 
   on ...
   ([...]);
grant send on service::[tcp://MACHINE1:4022/CentralService] to [public];
create route transport with address = 'TRANSPORT';
go

而已.现在让ad一个节点,比如主机MACHINE2:

use master;
go

create database master key...
create certificate [MACHINE2] with subject 'MACHINE2';
create endpoint BROKER as tcp (listener_port 4022) for service_broker 
  (authentication certificate [MACHINE2]);
grant connect on endpoint::BROKER to [public];
go

use db2;
create message type...
create contract ...
create queue ...
create service [tcp://MACHINE2:4022/Satellite] 
   on ...
   ([...]);
grant send on service::[tcp://MACHINE2:4022/Satellite] to [public];
create route transport with address = 'TRANSPORT';
go

而已.现在发生了两件事:

• 因为MACHINE1和MACHINE2上的两个端点都使用基于证书的身份验证并已授予连接到公共端,它们可以按原样连接和交换消息,而无需交换(导出和导入)其端点证书
• 因为两个数据库都创建了特殊的TRANSPORT路由,并且服务名称具有特殊[tcp://machine:port/service]语法,所以两个服务可以按原样立即交换消息,而无需任何显式路由.

最好的办法是如何添加一个新节点,比如说MACHINE3:

use master;
go

create database master key...
create certificate [MACHINE3] with subject 'MACHINE3';
create endpoint BROKER as tcp (listener_port 4022) for service_broker 
  (authentication certificate [MACHINE3]);
grant connect on endpoint::BROKER to [public];
go

use db2;
create message type...
create contract ...
create queue ...
create service [tcp://MACHINE3:4022/Satellite] 
   on ...
   ([...]);
grant send on service::[tcp://MACHINE3:4022/Satellite] to [public];
create route transport with address = 'TRANSPORT';
go

现在,对MACHINE1和MACHINE2的任何单一更改进行白化,新节点MACHINE3可以与中央服务交换消息,实际上也可以与MACHINE2的Satellite交换,如果需要的话.端点接受任何人连接,因此欢迎MACHINE3,并且使用的服务名称由特殊的TRANSPORT路由机制自动路由.这就是这种配置之美,即插即用:添加新节点需要在其他节点上进行0配置.

什么给出了什么？最大的问题是安全性.任何员工都可以在他的桌面上下载SQL Server Express,设置未经授权的Satellite节点并开始与Central服务交换消息.真的没有什么能阻止他,你明确地打开了所有的大门.一个更微妙的问题是服务何时移动.当服务[tcp://MACHINE3:4022/Satellite]移动(例如,通过数据库备份/恢复)到MACHINE4服务的名称仍然是有效的TRANSPORT路由语法名称,但是不正确.根据保留现有会话的重要性,您可以选择核心服务并创建一个名为[tcp://MACHINE4:4022/Satellite]party 的新服务(您不能重命名服务,必须删除并创建一个新服务).如果维护现有会话至关重要,那么就有解决方法,因为在中央服务数据库上为其添加显式路由将优先于最后的传输途径,并且消息将被正确重定向.重要的是有解决方案:)