大部分時候，微服務(wù)都是建立在一種基于請求和響應(yīng)的協(xié)議之上。比如，REST等。這種方式是自然的。我們只需要調(diào)用另外一個模塊就是了，然后等待響應(yīng)返回，然后繼續(xù)。這樣的方式確實也滿足了我們的很多的場景：用戶通過點擊頁面的一個按鈕然后希望發(fā)生一些事情。

但是，當我們開始接觸許多獨立的service的時候，事情就發(fā)生改變了。隨著service數(shù)量急速的增長，同步交互比例也隨著service在急速增長。這時候，我們的service就會遇到很多的瓶頸。

于是，不幸的ops工程師們就被我們坑了，他們疲憊的奔波于一個又一個的service，拼湊在一起的二手信息片段，誰說了什么，去往哪里，什么時候發(fā)生等等。。。

這是一個非常典型的問題。市面上也有一些解決方案。一種方案就是確保您的個人服務(wù)具有比您的系統(tǒng)更高的SLa。Google提供了這樣做的協(xié)議。另一種方法是簡單地分解將服務(wù)綁定在一起的同步關(guān)系。

上面的做法都沒有從模式上根本解決問題。我們可以使用異步機制來解決這個問題。比如，電商網(wǎng)站中你會發(fā)現(xiàn)這樣的同步接口，比如getImage()或者processOrder()，也許你感覺蠻正常。調(diào)用了然后希望馬上有一個響應(yīng)。但當用戶點擊了“購買”后，觸發(fā)了一個復雜且異步的處理過程。這個過程涉及到購買、送貨上門給用戶，這一切都是發(fā)生在當初的那一次的按鈕點擊。所以把一個程序處理邏輯切分成多個異步的處理，是我們需要解決的問題。這也正符合我們的真實的世界，真實世界本來就是異步的，擁抱異步吧。

在實際情況下，我們其實已經(jīng)自動擁抱了異步了。我們發(fā)現(xiàn)自己會定時輪詢數(shù)據(jù)庫表來更改又或者通過cron定時job來實現(xiàn)一些更新。這些方法都是一些打破同步的方式，但是這種做法總讓人感覺有種黑客范兒，感覺像是黑客行為，怪怪的。

在本文中，我們將會討論一種完全不同的架構(gòu)：不是把service們通過命令鏈揉到一塊，而是通過事件流（streamofevents）來做。這是一個不錯的方式。這種方式也是我們之后要討論的一系列的一個基礎(chǔ)。

當我們進入正式的例子之前，我們需要先普及三個簡單的概念。一個service與另外一個service有三種交互方式：命令（Commands）、事件（Events）以及查詢（Queries）。

事件的美妙之處在于“外部數(shù)據(jù)”可以被系統(tǒng)中的任何service所重用。

而且從service的角度來說，事件要比命令和查詢都要解耦。這個很重要。

服務(wù)之間的交互有三種機制：

Commands。命令是一個操作。希望在另一個服務(wù)中執(zhí)行某些操作的一個請求。會改變系統(tǒng)狀態(tài)的東西。命令期待有響應(yīng)。

Events。事件既是一個事實也是一個觸發(fā)器。發(fā)生了一些事情，表示為通知。

Queries。查詢是一個請求，是一個查找一些東西的請求（request）。重要的是，查詢不會使得系統(tǒng)狀態(tài)發(fā)生改變。

一個簡單事件驅(qū)動流程

讓我們開始一個簡單的例子：用戶購買一個小東西。那么接下來要發(fā)生兩件事情：

支付。

系統(tǒng)檢查是否還有更多的商品需要被訂購。

在請求驅(qū)動（request-approach）的架構(gòu)中，這兩個行為被表現(xiàn)為一個命令鏈條。交互就像下面這樣：

首先要注意的問題是“購買更多”的這個業(yè)務(wù)流程是隨著訂單服務(wù)（OrderService）一塊被初始化的。這就使得責任不獨立，責任跨了兩個service。理想情況下，我們希望separationofconcerns，也就是關(guān)注隔離。

現(xiàn)在如果我們使用事件驅(qū)動，而不是請求驅(qū)動的方式的話，那么事情就會變得好一些。

在返回給用戶之前，UIservice發(fā)布一個OrderRequested事件，然后等待OrderConfirmed（或者Rejected）。

訂單服務(wù)（OrdersService）和庫存服務(wù)（StockService）react這個事件。

仔細看這里，UIservice和OrdersService并沒有改變很多，而是通過事件來通信，而不是直接調(diào)用另一個。

這個Stockservice（庫存服務(wù)）很有趣。OrderService告訴他要做什么。然后StockService自己決定是否參與本次交互，這是事件驅(qū)動架構(gòu)非常重要的屬性，也就是：ReciverDrivenFlowControl，接收者驅(qū)動流程控制。一下子控制反轉(zhuǎn)了。

這種控制反轉(zhuǎn)給接收者，很好的解耦了服務(wù)之間的交互，這就為架構(gòu)提供了可插拔性。組件們可以輕松的被插入和替換掉，優(yōu)雅!

隨著架構(gòu)變得越來越復雜，這種可插拔性的因素變得更加重要。舉個例子，我們要添加一個實時管理定價的service，根據(jù)供需調(diào)整產(chǎn)品的價格。在一個命令驅(qū)動的世界里，我們就需要引入一個可以由庫存服務(wù)（StockService）和訂單服務(wù)（OrdersService）調(diào)用的類似updatePrice()這樣的方法。

但是在事件驅(qū)動（event-driven）世界更新價格的話，service只需要訂閱共享的stream就是了，當相應(yīng)的條件符合時，就去執(zhí)行更新價格的操作。

事件（Events）和查詢（Queries）的混合

上面的例子只是命令和事件。并沒有說到查詢。別忘了，我們之前可是說到了三個概念?，F(xiàn)在我們開始說查詢。我們擴展上面的例子，讓訂單服務(wù)（OrdersService）在支付之前檢查是否有足夠的庫存。

在請求驅(qū)動（request-driven）的架構(gòu)中，我們可能會向庫存服務(wù)（StockService）發(fā)送一個查詢請求然后獲取到當前的庫存數(shù)量。這就導致了模型混合，事件流純粹被用作通知，允許任何的service加入flow，但查詢卻是通過請求驅(qū)動的方式直接訪問源。

對于服務(wù)（service）需要獨立發(fā)展的較大的生態(tài)系統(tǒng)，遠程查詢要涉及到很多關(guān)聯(lián)，耦合很嚴重，要把很多服務(wù)捆綁在一起。我們可以通過“內(nèi)部化”來避免這種涉及多個上下文交叉的查詢。而事件流可以被用于在每個service中緩存數(shù)據(jù)集，這樣我們就可以在本地來完成查詢。

所以，增加這個庫存檢查，訂單服務(wù)（OrderService）可以訂閱庫存服務(wù)（StockService）的事件流，庫存一有更新，訂單服務(wù)就會收到通知，然后把更新存儲到本地的數(shù)據(jù)庫。這樣接下來就可以查詢本地這個“視圖（view）”來檢查是否有足夠的庫存。

網(wǎng)站標題：是時候改變你對微服務(wù)的認知了
地址分享：http://jinyejixie.com/news8/123058.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)建站、網(wǎng)站導航、網(wǎng)站排名、網(wǎng)站設(shè)計、網(wǎng)頁設(shè)計公司、企業(yè)網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)