在服務間共享數據

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），併爲每個服務單獨的機器。