在服务之间共享数据

本文关键字：数据 共享 之间 服务 | 更新日期: 2023-09-27 18:29:58

我需要分解我的双工服务，并希望将大型传输封装到一个服务中，然后从其他服务中检索。我过去把它都放在一个服务中，但现在需要从缓冲切换到流媒体，以考虑大小/内存的调节。我在这里和这里看到了一些问题，但它们是相当古老的

在服务之间的IPC中，我将使用什么，命名为dPipe？

服务A公开了两个方法Guid Upload(stream)、Stream Download(Guid)，并使用net.tcp流，运行良好，

现在我想坚持服务B？这会是命名管道WCF吗？

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

我的问题是使用什么来实现持久性/服务B

从客户角度来看

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

在服务之间共享数据

是的，只要通信进程在同一服务器上运行，就可以将命名管道用作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），并为每个服务使用单独的机器。

相关文章：