在 WCF 中构建可靠的服务答案

【问题标题】：Building a reliable service in WCF在 WCF 中构建可靠的服务
【发布时间】：2011-04-14 08:00:30
【问题描述】：

我目前正在设计一个用于返回敏感数据的服务 (wsHttp)。一旦客户要求提供这些数据，我就从数据库中获取它，编译一个列表，然后从数据库中删除数据并返回该列表。

我担心的是在返回客户端的路上发生了一些事情（网络问题，...）我已经从数据库中删除了数据，但客户端永远不会得到它。

我有哪些开箱即用的解决方案？

【问题讨论】：

【解决方案1】：

这是分布式计算中的一个固有问题。 没有简单的解决方案。问题是从此类错误中恢复有多重要。

例如，如果一个人删除了一些记录，但客户端断开连接，下次连接时，他会看到这些记录已删除。即使他再次尝试删除它们（数据保留在 UI 中），这也不会造成任何伤害。

对于银行转账，它们有一个错误解决机制，可以匹配它们之间在第二个流程中发生的交易。将手动处理冲突。

NServiceBus 等一些系统依赖于 MSMQ 来存储消息和 最终一致性，在这种情况下，发往客户端的消息最终会在客户端再次连接时到达。

【讨论】：

【解决方案2】：

对此没有开箱即用的解决方案。您需要实现某种形式的用户/自动确认数据已被接收，并且只有在返回后才删除。

埃德

【讨论】：

【解决方案3】：

有一个简单的解决方案。但它不是装在盒子里的。

像 WS-ReliableMessaging（或同样的 TCP/IP）这样的协议在消息传递下为您提供了一层可靠性，但是一旦该层将消息卸载到上面的层，所有的赌注都将失败。

因此，可靠性只能在绝对最高层（应用层）完全解决，而不是通信堆栈的任何较低层。这使其成为一流的业务问题，而不是纯粹的技术问题。

对删除敏感数据的过程稍作改动即可解决问题。

与其立即删除，不如将其标记为删除。然后，在驱动您的服务的业务流程中构建客户必须确认收到敏感数据的断言。然后，当您收到确认后，您可以安全地删除标记为删除的数据，知道它已收到。

我最近写了一封 blog post 的理由是可靠性是一流的业务问题，不能转移到较低层。

【讨论】：