在服務之間共享數據

Question

我需要分解我的雙工服務，並希望將大量傳輸封裝到一個服務中並從其他服務中檢索。 我曾經在一項服務中擁有這一切，但現在需要從緩沖切換到流式傳輸以考慮大小/內存調節。 我在這里和這里看到了一些問題，但它們已經很老了

對於服務之間的 IPC，namedPipe 我會使用什么？

服務 A公開了 2 種方法Guid Upload(stream) ， Stream Download(Guid)和 uses.net.tcp streaming，這運作良好，

現在我想堅持服務B ？ 這會是 namedPipe WCF 嗎？

Service C --> Business layer --> Service B with Guid ，檢索並計算item，持久化回B

我的問題是持久性/服務 B使用什么

從客戶的角度

1. 客戶端調用ServiceA_Proxy.Upload(someLargeItem)返回Guid
2. 客戶端然后調用ServiceC_Proxy.DoSomeWork(GuidFromCall_1)
3. 客戶端然后調用ServiceA_Proxy.Download(GuidFromCall_1)
4. 客戶端顯示給最終用戶

Answer 1

是的，您可以將命名管道用作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. 客戶端顯示給最終用戶

我不確定我沒有把事情搞砸。 如您所見，這變得相當復雜。 您需要問問自己，這是通往 go 的路，如果以這種方式拆分您的服務真的會讓它更具可擴展性嗎？ 您計划使用 NamedPipes，因此所有處理仍將在同一台機器上進行。

你真的應該考慮你的設計。 也許將功能拆分為一些 *.dll 並直接調用它們就足夠了？ 這樣您將實現層的邏輯分離。 從緩沖通信切換到流式通信不需要您將邏輯拆分為更多服務。

如果您想要真正的可伸縮性，請考慮使用隊列（例如MSMQ ）並為每個服務使用單獨的機器。