（2012/12/06 的第 2 次更新——新协议，略有不同的观点）
问题是下面的解决方案对您来说是否合理，或者是否有任何我没有注意到的缺陷（对 SQL Server Service Broker 来说很新）......
我想继续分析SQL Service Broker 中提出的问题：从分布式源收集数据。我想关注从卫星 SQL 服务器收集数据时使用的协议问题。SQL Server Service Broker 的使用是必须的——它还受其他未在此处介绍的原因所决定。因此，请不要提出完全替代的解决方案。
我想重点关注应该做什么以及如何自然地使用服务代理（最好的方法）来解决确切的问题。总体目标已在上述问题中提出。先上图：
现在要考虑更多细节...
需要插件架构
卫星机器与真实的物理生产线有关。可能会发生某些机器被添加到技术流程中，某些机器可以消失，某些机器可以被替换的情况，因为它将使用相同的生产线标识，但是它在物理上是不同的——即它的 SQL 服务器是不同的实例。
中央服务器在从卫星获得第一条消息之前对卫星一无所知。没有卫星服务器的集中数据库。不知道系统中要包含什么和多少卫星 SQL 服务器。它总是在卫星站点上决定。
任何与收集数据相关的活动都应由卫星机器生成的事件启动。
重要提示：目标是不断传输所有新创建的数据（来自传感器），并发现和修复丢失 - 独立于可能导致它们的任何原因。
给你一个具体的例子：
由第 3 行（黄色）标识的机器最近被添加到环境中。其 SQL Server Express 启动并开始收集传感器数据（第三方解决方案，特殊结构的专用表）。该机器尚未连接到中央服务器。
唯一的配置是可靠分配的生产线的固定标识（此处为 3），以及连接到中央 SQL 服务器的所有必要细节。但是中央 SQL 服务器不知道这些信息。中央刚刚准备好接受来自任何新源的数据，但不知道何时。（它已经使用 Remus Rusanu对 SQL Service Broker 问题的回答建议的方法在一台机器上进行了测试——一个中央 SQL 和更多卫星 SQL……</a>。）
稍后，该 SQL 软件将部署在机器 3 上。它开始与中央对话。卫星部分并不笨，但它自己的活动是每当将新记录插入传感器数据表时发送传感器数据（参见上面的第 1 点）。根据记录，计算UTC时间（根据专有格式），将一条记录中的多个传感器数据转换为相同数量的规范化记录（格式化为一条XML消息），然后发送到中央SQL服务器。
中央由带有从卫星机器发送的传感器数据的消息激活。Service Broker 队列会屏蔽物理连接的失败。
在合理的时间间隔（这里是一小时）之后，中央服务器检查是否应该处理到目前为止收集的数据。有一个工作单元需要一些生产时间，数据应该被处理并添加到该单元的文档中。仅当单元完成时才应进行处理。
中央还检查它是否拥有该单元的所有数据。由于传感器采样是以已知的定期间隔（这里大约 1 分钟）进行的，因此中央可以检查是否有一些丢失。当卫星没有通过 SSB 连接到中央时，还有一个初始“退出”时间间隔。该机制应从任何情况中恢复。也可能发生故障的传感器或未收集数据的情况。在中心检测到的丢失实际上可能意味着中心询问：“在这段时间间隔内，我没有来自您的数据。如果它们存在，请给我一些数据，或者告诉我它们不存在。”
卫星应该只发送采样时间之间可以发送的数据量。从辍学中恢复可能相当缓慢。在中央服务器处理数据的延迟并不重要。但是，中央应该知道数据何时准备好（或在检测到的时间间隔内不存在）。
一些图片，更多解决方案细节
我选择了Remus Rusanu 的“回收对话”作为卫星与中央通信的基本框架。它定义了EndOfStream消息类型以表示应该丢弃对话句柄并使用新的句柄。生命周期受上面提到的 Service Broker 计时器生成的一小时间隔的限制。
该消息在中央服务器处（错误地）用于激活数据处理。大约在同一时间，中央检查辍学。中央将时间保持在已检查的辍学以下。通过这种方式，它知道准备好处理哪些数据。
你认为这个场景合理吗？你能看出它有什么问题吗？
（我将改进问题以反映您的建议。）
感谢您的时间和经验，祝您有美好的一天。
彼得