Kafka微服務正確使用案例

Question

在我新工作的項目中，我發現微服務不會直接從一個微服務向另一個微服務發出post / put API調用，而是會向kafka生成一條消息，然后由單個微服務使用。

例如，訂購微服務將發布一條記錄到“待定訂單”主題，然后由庫存微服務（沒有其他使用者）使用。 反過來，在使用記錄並進行了一些處理之后，庫存微服務將產生一條記錄為“已處理訂單”，然后該記錄僅由訂單微服務使用。

這是正確的用例嗎？ 還是在這種情況下僅在微服務之間進行API調用會更好？

Answer 1

在基於微服務的應用程序中，Kafka有兩個強大的用例：

1. 作為單個最終用戶活動的一部分，您需要在多個微服務中進行狀態更改。 如果通過依次或並行調用所有適當的微服務API來執行此操作，將有兩個問題：首先，您失去原子性，即無法保證“全有或全無”。 對微服務A的調用很可能會成功，但對服務B的調用會失敗，這將導致永久的數據不一致。 其次，在雲環境中，不可預測的延遲和網絡超時並不少見，因此當您在一個呼叫中進行多個呼叫時，這些呼叫之一被延遲或失敗的可能性會極大地影響用戶體驗。 因此，這里的一般建議是，您將Kafka主題中的用戶操作原子地寫為一個事件，並具有多個使用者組-每個感興趣的微服務都使用一個使用者組來消耗事件並在其自己的數據庫中進行狀態更改。 如果操作是由用戶從UI觸發的，則您還需要提供“自己讀寫”保證，即用戶希望在寫完后立即查看其數據。 因此，您需要先在第一個微服務的本地數據庫中編寫事件，然后再進行基於日志的事件源 （使用aporopriate Kafka Connector）將事件數據傳輸到Kafka。 這將使您能夠從本地數據庫向用戶顯示數據。 您可能還需要更新緩存，搜索索引，分布式文件系統等，所有這些都可以通過使用各個微服務發布的Kafka事件來完成。

2. 您需要從多個微服務中提取數據以執行某些活動或聚合數據並顯示給用戶，這並不少見。 通常，由於上述延遲和超時問題，因此不建議這樣做。 通常建議我們根據其他微服務更改狀態時發布的Kafka事件，在微服務本地數據庫中預先計算這些聚合。 這將使您更快地將聚合數據提供給用戶。 這稱為物化視圖模式。

這里唯一要記住的一點是寫Kafka日志或代理，並以異步方式從中讀取信息，可能會有一點時間延遲。

Answer 2

微服務作為消費者，對我來說似乎是可疑的。 您可能意味着該主題的偵聽器將使用該消息，並且可能會調用您的第二個微服務，即庫存微服務。

是的，該模型很好，特別是當您想要異步行為和通過它處理的流量負載時。

當您有多個要從1個終結點調用的微服務時，請設想一個場景。 在這里，您需要要么聚合服務的聚合層，然后調用它一次，要么您想要向Kafka發布幾條消息，然后該任務就可以完成。

還要考慮讀取服務，如果您需要調用微服務從其他地方讀取一些數據，那么您將無法使用Kafka。

這完全取決於您的要求和設計。