我有以下情况。有一个中央SQL Server（2008 R2，标准版）和更多（比如10个）技术SQL Server（2008 R2，Express）。技术服务器位于“真实”机器附近，它们从传感器捕获数据。数据将以某种方式传递到中央SQL Server以进行处理。所有计算机都位于同一个域中。选择Service Broker将数据发送到中央服务器。
我已经尝试过标准的MSDN教程Completing a Conversation Between Instances，该教程展示了如何在没有登录的情况下创建用户，证书等。总而言之，有很多东西需要参数化。两个服务器的手动设置没有问题，但是......
使用更多服务器时，通常的做法是什么？如果将来要添加服务器，将参数（计算机名称，端口等）插入某个配置表或使用硬连线常量创建一些存储过程是否合理...能够（重新）构造新增SQL服务器的通信渠道？
所有SQL服务器都位于同一个域中。通过不创建用户和证书来简化部署是否合理？我在Service broker with only domain account找到了Remus Rusanu关于如何做到这一点的答案？你会在真实环境中使用这种方法吗？有什么优点和缺点？
谢谢，彼得
答案 0 :(得分：2)
当我们设计Service Broker时，我们试图明确区分设计时间（编写代码时）和部署时间（代码实际用于生产时）。我们采取了非常明确的措施，能够在不更改应用程序代码中的单行的情况下完全重新配置部署。我们考虑了用作设计时间的消息类型，合同和服务名称。如何编写激活的过程和RECEIVE，发出BEGIN DIALOG / SEND动词的代码再次被视为设计时。
部署时间就像路由信息（当网络的物理拓扑发生变化时更改），用于安全性的证书（它们过期并需要更换），权限，端点端口等。
特殊情况是dialog security和远程服务绑定：它是设计时间（应用程序代码指定WITH ENCRYPTION = ON）和部署时间（存在remote service binding）的混合。我们的想法是，如果应用程序需要对话安全性，则必须指定ENCRYPTION = ON（如果未指定，则为默认值），然后管理员在部署时必须配置对话安全性。或者，如果应用程序不需要对话框安全性，则可以指定ENCRYPTION = OFF，然后在部署时由管理员决定是否配置对话框安全性。
与端点安全性（transport security）相关的所有内容都被视为部署时间。
最后，为了使编程体验和可用API的行为完全相同，无论您的服务对是在数据库中，在同一实例上的两个数据库中还是在两个单独的实例上（即。确保coupling不会进入。）
我提供了这样的解释，希望它能够提供一些亮点并使事情变得更好。要回答您的问题：您当然可以编写一个与部署的实际物理布局完全无关的应用程序，包括主机的名称，位置，侦听端口和编号参与其中。基本上，应用程序代码全部与服务交换服务，并且有关于路由，证书，端点等的0知识。但这都是从应用程序开发的角度出发的。实际上，部署通常是自动化的，并且是一个应用程序本身。即使像往常一样，是同一个人或团队编码两个 appciations（或同一个应用程序的 sides ）是健康的，可以认为它是两个强制分开任务（或应用程序）。如果你可以进行这种分离并保持代码清洁，那么你就是那里。 “应用”代码不知道 与之对话的服务是什么，或者它处理的消息从发送到哪里。配置代码（或应用程序）就是要确切了解服务所在的位置，如何配置路由，哪些端点正在侦听哪些端口等等。
作为旁注，有一个名为Service Broker Dynamic Routing的东西允许使用SSB本身配置大型部署站点的配置（即SSB可以联系中央存储库以查找路由信息）但是我不推荐它。