“出租車”交互示例

讓我們仔細(xì)看看什么是 REST API。它基本上是一種交互模式；系統(tǒng)可以相互交互的方式。

REST API 交互：

為了理解這兩種交互形式，讓我們考慮一個等效的現(xiàn)實生活用例，即用戶從代理處訂購出租車。

現(xiàn)在，用戶問這個問題：“我的出租車什么時候到達(dá)？” 在 REST API 措辭中，請求的用戶是“消費(fèi)者”，響應(yīng)的機(jī)構(gòu)或個人是“提供者”（又名“生產(chǎn)者”）

上面顯示的這種實時交互與REST API的工作方式完全匹配。它轉(zhuǎn)化為以下內(nèi)容：

現(xiàn)在讓我們換個問題：“我的車準(zhǔn)備好了嗎？”

由于答案不是預(yù)期的，消費(fèi)者將繼續(xù)直到他們最終收到預(yù)期的答案。從人類的角度來看，這種情況是相當(dāng)重復(fù)和煩人的。

以上從消費(fèi)者到生產(chǎn)者的重復(fù)查詢集模仿了以下 API。

REST API 限制

那么，這兩個例子有什么區(qū)別呢？是時候了！

信息的價值隨著時間的推移而降低。但是，對于所有信息，速率的下降并不相同。

讓我們再看一下“打車”的例子來理解“信息價值與時間的比例”

駕駛室的估計到達(dá)時間可能僅在駕駛室到達(dá)之前是相關(guān)的。

最重要的是，當(dāng)用戶積極等待出租車以便及時到達(dá)某個地方時，沒有什么比這個“你的車已經(jīng)到了”通知更重要了。而一旦行程開始，這個通知就沒有任何價值了。

還有很多其他此類實時場景，其中很少有：

• 股市
• 庫存
• 送餐服務(wù)

在很短的時間內(nèi)具有很高的價值。

一個人可以問“我的騎行準(zhǔn)備好了嗎？”

機(jī)器很容易提供資源的狀態(tài)，例如“準(zhǔn)備好/未準(zhǔn)備好”。但預(yù)測（“10 分鐘內(nèi)到達(dá)”）很少見。

要具有相關(guān)性，它必須是準(zhǔn)確的。如果它在預(yù)計的時間還沒有準(zhǔn)備好怎么辦？如果提前準(zhǔn)備好呢？這是一個非常復(fù)雜的問題。它們是處理這個問題的簡單得多的方法。

如果我們能問“什么時候準(zhǔn)備好告訴我”，問題就迎刃而解了。

REST API 交互模式意味著消費(fèi)者總是發(fā)起與提供者的交互。這就是它的工作原理。因此，使用 REST API 無法要求“知道它何時準(zhǔn)備就緒”。你猜怎么著？

這正是事件驅(qū)動 API 提供的價值。

事件驅(qū)動的 API 交互：

事件驅(qū)動的 API 交互模式不同于 REST API。我們將在下面看到，如何。有多種形式，其中兩種流行的是：

• 網(wǎng)絡(luò)鉤子
• 流媒體

Webhook（用“taxi-ride”場景描述）

讓我們回到上面討論的“出租車”示例。并使用“告訴我我的旅程何時準(zhǔn)備就緒”交互模式。

我們可以在這里清楚地看到差異?，F(xiàn)在該事件由提供者（生產(chǎn)者）發(fā)起，在本例中為出租車代理。消費(fèi)者必須定義生產(chǎn)者可以調(diào)用的端點(diǎn)（即 URL），以便將通知發(fā)送給消費(fèi)者。一旦信息準(zhǔn)備好，就會通知消費(fèi)者。

這種交互類型稱為Webhook，是異步 API 的首選樣式。

這種交互構(gòu)成了均勻驅(qū)動架構(gòu)的基礎(chǔ)。

API 流式處理（用“出租車”場景描述）

讓我們稍微改變一下提供者的能力。而不是回答“準(zhǔn)備好/未準(zhǔn)備好”，現(xiàn)在的答案是出租車的當(dāng)前狀態(tài)。

機(jī)器告訴資源狀態(tài)是很自然的。

這將允許另一種交互：API Streaming。

上面的API版本是：

消費(fèi)者實時接收狀態(tài)的每個變化。

通常，Webhook旨在從應(yīng)用程序到應(yīng)用程序，而Streaming更針對于與用戶端的人進(jìn)行實時交互，直接實時消費(fèi)信息。

現(xiàn)在從微服務(wù)架構(gòu)模式的角度來看這個

設(shè)計微服務(wù)有不同的方法，本博客主要關(guān)注微服務(wù)架構(gòu)模式，請求驅(qū)動和事件驅(qū)動。

什么是微服務(wù)？

它是一個松耦合、高度可測試、獨(dú)立部署、定義清晰的業(yè)務(wù)領(lǐng)域邊界并由相對較小的團(tuán)隊輕松維護(hù)的應(yīng)用程序。

請求驅(qū)動的微服務(wù)

電子商務(wù)應(yīng)用示例

優(yōu)點(diǎn)

• 有明確的流程控制，看編排器的代碼，我們可以確定動作的順序。

權(quán)衡取舍

• 單點(diǎn)故障 如果 Orchestrator 服務(wù)出現(xiàn)故障，這將是單點(diǎn)故障。當(dāng)此服務(wù)關(guān)閉時，整個流程將不會執(zhí)行。
• 重播數(shù)據(jù)以進(jìn)行恢復(fù)并不容易 沒有簡單的方法可以通過重新處理對依賴服務(wù)的失敗調(diào)用來恢復(fù)操作。
• 緊密耦合的服務(wù)（相對） 如果依賴服務(wù)之一出現(xiàn)故障，則很有可能排除對其他服務(wù)的調(diào)用。依賴服務(wù)的 Rest API 不能輕易修改。如果改變了，API的消費(fèi)者也需要修改。因此，微服務(wù)不是松耦合的。

事件驅(qū)動的微服務(wù)

讓我們將之前的請求驅(qū)動應(yīng)用程序轉(zhuǎn)換為事件驅(qū)動的電子商務(wù)應(yīng)用程序。

事件驅(qū)動架構(gòu)的優(yōu)勢

• 松耦合服務(wù) 消息的生產(chǎn)者不需要知道哪個服務(wù)有興趣接收它。這使得以后在不影響現(xiàn)有功能的情況下添加附加功能變得更加容易。
• 異步 當(dāng)您發(fā)出一個事件時，它是異步的，這意味著微服務(wù)可以立即繼續(xù)其工作，而無需等待事件的使用者完成。這意味著事件峰值不會減慢用戶界面或其他關(guān)鍵功能。
• 可擴(kuò)展性 由于微服務(wù)專注于做好一件事而不與其他服務(wù)緊密耦合，因此您可以單獨(dú)擴(kuò)展具有最大工作負(fù)載的服務(wù)，以確保每個微服務(wù)的工作日志都是最新的。
• 恢復(fù) 事件是易于存儲的時間點(diǎn)事實，并且與任何其他數(shù)據(jù)自然分離。
• 可維護(hù)性 事件可以通過重放事件日志簡單地丟棄并用新模式重新填充。不再需要復(fù)雜的數(shù)據(jù)遷移！

權(quán)衡取舍

• 沒有中央?yún)f(xié)調(diào) 器 沒有明確的中央位置（協(xié)調(diào)器）來定義整個流程。
• 回滾很復(fù)雜 管理分布式事務(wù)可能很復(fù)雜。有多個服務(wù)消耗一個事件，因此，如果其中一個服務(wù)發(fā)生異常，那么整個流程應(yīng)該發(fā)生什么或?qū)崿F(xiàn)回滾過程是具有挑戰(zhàn)性的。

結(jié)論

兩種模式都有好處，權(quán)衡取舍，它們的適用性還取決于用例。還可以根據(jù)應(yīng)用需求選擇使用混合架構(gòu)。但是，如果有機(jī)會實現(xiàn)事件驅(qū)動的微服務(wù)，那肯定會為構(gòu)建松散耦合的微服務(wù)提供良好的基礎(chǔ)。

本文使用 文章同步助手 同步