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

Question

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

（图片来自官方Service Broker Communication Protocols文章并进行了修改。）

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

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

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

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

Answer 1

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

1. 使用相同的消息类型并在每个地方签订合同。这在任何情况下都是必须的，所以不言而喻。
2. 不要使用dialog security。到处都是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的技巧会消除交换证书的要求。使用此技巧的所有计算机可以相互通信 w / o任何先前的设置，这比在端点上使用Windows身份验证更好（需要授予连接到domain\machine$ ro需要部署SQL使用特定域帐户的服务器实例）。同样，您不能在连接上说“不”，您将接受来自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]语法，所以两个服务可以立即交换消息 as-is ，而无需任何显式路由。

最好的办法是如何添加一个新节点，比如说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

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

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