在服务间共享数据

Question

我需要拆分我的双工服务，并且想要将大型传输封装到一个服务中并从其他服务中检索。我曾经在一项服务中使用它，但现在需要从缓冲切换到流媒体，以考虑大小/内存调节。 我已经看到几个问题here和here，但它们已经很老了

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

服务A公开2种方法Guid Upload(stream)，Stream Download(Guid)，并使用的net.tcp流，这是运作良好，

现在我想坚持到服务B？这是命名的管道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. Client显示到终端用户

Answer 1

是的，你可以使用命名管道作为WCF绑定只要comunicating进程在运行相同的服务器。基本上，您创建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（G uidFromCall_1）（内部）
6. ServiceC调用ServiceB_Proxy.Upload（GuidFromCall_1，someLargeItemProcessed）
7. 客户端然后调用ServiceA_Proxy。下载（GuidFromCall_1）（再次，您需要确保处理完成）
8. ServiceA调用ServiceB_Proxy.Download（GuidFromCall_1）并返回到客户端。
9. 客户端显示给终端用户

我不知道我没惹的东西了。正如你所看到的，这变得非常复杂。 你需要问自己，这是要走的路，如果以这种方式分离你的服务真的会使它更具可扩展性？您计划使用NamedPipes，这样所有的处理过程仍然会在同一台机器上。

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

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