复制或网络服务

Question

我们正在考虑整合 3 个不同的系统（由不同的公司拥有），这些系统需要协调数据（数据的一个企业所有者）。一种选择是使用 Web 服务将数据从一个系统推送到另一个系统。所有系统都在sql server上，所以有限数据的复制也是可能的。

任何尝试过这两种技术的人愿意评论利弊吗？每个系统都可能是要推送到其他系统的数据子集的主控系统。具体来说，我很好奇 Web 服务中如何处理失败的事务。

Answer 1

我们有一个类似的环境，我们在其中保持 3 个系统同步（Access、企业拥有的 SQL Azure 和第 3 方 SQL Azure）。我们从 Web 服务集成开始，但主要出于性能原因，我们正在慢慢转向更紧密的 SQL 到 SQL 复制。我们的实现是完全自定义的（不使用 SQL Server 提供的任何内置同步或复制服务），基本上使用 BulkImport 和基于集合的查询进行同步。

网络服务

优点

• 松散耦合（如果设计正确），因此如果任何部分发生更改或被替换，可以更好地进行风险管理。
• 更好的访问控制
• 与基于数据库的现有应用程序更好地集成。
• 高度可扩展。

缺点

• 移动大量数据可能会非常缓慢。
• 事务和数据处理必须手动处理 - 但可以完成。

SQL 集成

优点

• 更高的吞吐量。
• 如果表结构映射起来相对简单，管理起来会更容易。
• 事务支持。

缺点

• 容易犯大错，比如清除整张表、弄乱整列等。
• 如果您必须为基于集合的复制推出自己的集成，则很难构建可靠的错误处理。
• 如果表的结构非常不同，即一个是像我们系统这样的 EAV 模型，系统之间的紧密集成将非常困难。

如果我可以选择并且性能不是问题，我肯定会选择 Web 服务。我们的 3 个系统的本质是它们具有非常不同的表结构，因此将后端表结构抽象为一个简单的 POCO 数据结构的 Web 服务可以让事情变得更简单。此外，三个系统中的一个驱动一个网站，该网站公开一个“正常工作”的 Web 服务，而不用担心缓存记录、同步更新等。

我们目前通过 Web 服务集成处理事务更新的方式是这样的（服务器应该是更复杂且更有可能失败的一方）：

1. 客户端启动与服务器的连接。
2. 客户端开始本地事务。
3. 服务器开始本地事务。
4. 服务器处理请求。
5. 服务器根据成功/失败提交/回滚本地事务。
6. 服务器发回带有成功/失败和错误消息的响应。
7. 客户端处理响应。
8. 客户端根据成功/失败提交/回滚本地事务。