3

我需要分解我的双工服务，并希望将大量传输封装到一个服务中并从其他服务中检索。我曾经在一项服务中拥有所有功能，但现在需要从缓冲切换到流式传输以考虑大小/内存调整。我在这里和这里看到了一些问题，但它们已经很老了

我将在服务之间使用什么 IPC，命名管道？

服务 A公开了 2 个方法Guid Upload(stream)，Stream Download(Guid)并使用 net.tcp 流式传输，效果很好，

现在我想坚持服务 B吗？这会是 namedPipe WCF 吗？

服务 C --> 业务层 -->服务 B使用Guid，检索和计算项目，持久回 B

我的问题是什么用于持久性/服务 B

从客户的角度

  1. 客户来电ServiceA_Proxy.Upload(someLargeItem)返回Guid
  2. 客户然后调用ServiceC_Proxy.DoSomeWork(GuidFromCall_1)
  3. 客户然后调用ServiceA_Proxy.Download(GuidFromCall_1)
  4. 客户端显示给最终用户
4

1 回答 1

0

是的，只要通信进程在同一台服务器上运行，您就可以使用命名管道作为WCF 绑定 。基本上，您创建 WCF 服务就像您使用任何其他绑定（如 TCP/IP）一样，但您需要将端点配置为使用.netNamedPipeBinding

如果您想保留/保存数据，则可以根据您的要求将其保存到文件甚至数据库中。如果您只是想保留数据直到 ServiceC 调用它，那么Dictionary<Guid, SomeLargeItem>就足够了。

所以你的流程看起来像：

  1. 客户端调用 ServiceA_Proxy.Upload(someLargeItem) 返回 Guid
  2. ServiceA 调用 ServiceB_Proxy.Upload(GuidFromCall_1, someLargeItem)
  3. 客户端然后调用 ServiceC_Proxy.DoSomeWork(GuidFromCall_1) （您需要首先确保上传完成）
  4. ServiceC 调用 ServiceB_Proxy.Download(GuidFromCall_1)
  5. ServiceC 调用 DoSomeWork(GuidFromCall_1) （内部）
  6. ServiceC 调用 ServiceB_Proxy.Upload(GuidFromCall_1, someLargeItemProcessed)
  7. 客户端然后调用 ServiceA_Proxy.Download(GuidFromCall_1) （同样，您需要确保处理完成）
  8. ServiceA调用ServiceB_Proxy.Download(GuidFromCall_1)，返回给Client。
  9. 客户端显示给最终用户

我不确定我没有搞砸什么。如您所见，这变得非常复杂。您需要问自己这是要走的路，如果以这种方式拆分您的服务真的会使其更具可扩展性吗？您计划使用 NamedPipes，因此所有处理仍将在同一台机器上。

你真的应该考虑你的设计。也许将功能拆分为一些 *.dll 并直接调用它们就足够了？这样，您将实现层的逻辑分离。 从缓冲通信切换到流通信不需要您将逻辑拆分为更多服务。

如果您想要真正的可扩展性，请考虑使用队列（例如MSMQ）并为每个服务使用单独的机器。

于 2012-04-03T23:15:03.350 回答