我们有一个带有中央数据库（SQL Server）和小型客户端（KIOSK-带有本地数据库（SQL Express））的遗留系统，它使用WPF应用程序进行写入。客户端和中央数据库之间的数据同步是使用C＃，ADO.NET sql语句完成的。这会对性能造成巨大损失。目前我们拥有的客户数量是400，而且还会增加。每个客户端每天向中央数据库发送100,000条记录。
我们计划使用 SQL Service Broker
重新编写此同步部分主要问题之一，客户端和中央DB之间的架构是不同的。这些表没有规范化，最糟糕的情况是大多数列使用nvarchar数据类型来存储日期时间，整数数据。
我担心使用Service Broker，因为大多数业务逻辑都是使用存储过程编写的。
我想了解一下使用此技术是否最好还是我们需要考虑使用Message Queue创建基于REST的服务。
答案 0 :(得分：1)
TL; DR：我建议不要在这种环境中使用Service Broker。
详细答案
虽然Service Broker确实是一种非常轻量级且可靠的通信机制，但它的设计考虑了不同的目标。也就是说，它在静态拓扑中效果最佳，当管理员设置一次，然后整个系统运行多年，几乎没有变化。
从我的解释中了解到，您的连接主机网络更加动态，主机每天都在进出。这将导致支持的高维护成本，因为为了在属于不同SQL Server实例的两个Service Broker端点之间建立通信，您将需要（在许多其他方面）生成至少一对证书并交换它们的公钥参与实例之间，必须在双方的master和主题数据库中部署它们。
此证书交换和部署应在Service Broker消息传递之前完成，因此您需要在服务器之间建立另一个通信通道才能进行交换。通常，这是由DBA手动完成的，因为与潜在的传输级密钥丢失相关的高安全性风险。然而，在您的环境中，人们很有可能根本无法跟上。更不用说人为错误的可能性，由于大量重复的手工工作，这种错误会很高。
简而言之，我建议寻找易于部署和维护的东西。 Change tracking可能是一个好的开始;至于交通方面，你有一个完整的大杂烩选择，从WCF到WebAPI（到过去几年出现的其他任何东西）。