微服務建議關注兩個服務

之間共享狀態我下面的微服務架構，我們有兩個independed服務微服務建議關注兩個服務

（UserService，OtherService）

UserService寫入到它自己的數據源（mysql和Redis的）

將更新寫入UserService的客戶端

另一方面，客戶端從OtherService獲取需要來自UserService的某個用戶狀態的數據。

其他服務的延遲和吞吐量非常重要。

幾個選項：

UserService將更新OtherService時的狀態變化（比我打破OtherService域的責任，因爲它不應該維護用戶指出
OtherService會問UserService（通過API）爲用戶狀態（添加了很多對我來說很重要的延遲，我可以緩存，但仍然......不確定這是否正確）
具有共享數據存儲，而UserService wri te和其他服務讀取..打破共享相同的數據源時也微服務原則

你們認爲什麼是正確的？謝謝，雷。

來源

2015-11-19 rayman

您可以讓UserService公開某種可觀察的接口，其中的其他服務可以註冊以通知UserService更改。它仍然是OtherService的工作，從UserService獲取相關數據。通過這種方式，兩個服務之間的耦合不會是明確的，您可以允許其他服務實現相同的模式。 – Cosu

如何暴露「某種可觀的界面」。該服務使用休息互相通話.. – rayman

UserService應該有一個訂閱端點，其他感興趣的服務將調用。他們應該提供自己的回調端點，UserService將發送更改通知。當狀態改變時，用戶服務通知訂戶該事件改變了。更普遍的解釋是使用所有服務都可以發佈事件的事件總線。有關更詳細的解釋，請參見[本文]（https://www.thoughtworks.com/insights/blog/scaling-microservices-event-stream）。 – Cosu

我們在被動方和消息隊列上使用冗餘只讀數據進行這些場景的通信。我的意思是在你的其他服務端有一個用戶狀態表，並更新它，因爲這些信息來自你的用戶服務。它不會影響您的其他服務的可用性，性能和可伸縮性。依賴將幾乎爲零。該方法唯一可能存在問題的方面可能是用戶狀態數據的新鮮度。通過新鮮度問題，我一般在談論毫秒。如果這種新鮮問題在你的情況下非常重要，那麼你最好的辦法就是將兩種服務結合起來。

來源

2015-11-22 10:26:55 cool

感謝您的回覆。 1.「在你的其他服務端有一個用戶狀態表並更新它。」你的表是什麼意思？額外的數據源或？我沒有幾分鐘的刷新要求。 – rayman

1.是的，你應該有重複的數據，但不是所有的只是你的其他服務所需的數據。 2.那麼你不應該有任何問題，這種方法 – cool

不可能重複。但我是否也應該爲每個需要用戶詳細信息數據的其他服務創建單獨的數據源？ – rayman

我認爲你的清單上的選項＃2是正確的做法。你沒有在你的問題中提到有關延遲數字的任何信息。

通常，MS架構意味着您可以在多個地區的許多「機器/泊塢員」上運行，任何實例都可能在任何特定時刻出生或死亡，並且如果您沒有在同一個數據中心中運行，那麼無論您做什麼你會得到延遲。

我們（來自大型企業應用程序）有時很難將應用程序垂直分解爲邏輯功能塊。正因爲如此，我認爲值得考慮從UserService和OtherService中取出部分，然後再製作一個MS。不要以爲這將是太多的MS，公司幾乎在1000年代中期，它的工作正常。不要害怕在盒子外面做。

來源

2015-11-22 13:57:52

微服務建議關注兩個服務

回答

相關問題