首先我們看看一個(gè)案例，一家?jiàn)蕵?lè)公司價(jià)值10億美元項(xiàng)目需要涉及創(chuàng)建一個(gè)新的系統(tǒng)以及集成現(xiàn)有系統(tǒng)，主要問(wèn)題是如何從一個(gè)系統(tǒng)狀態(tài)變化傳播到其他系統(tǒng)的生態(tài)系統(tǒng)？例如,如果一個(gè)客人購(gòu)買一張票，我們?cè)趺粗肋@種票是否存在？屬于哪個(gè)特定的客人？這樣我們可以顯示他的資料嗎?

我們采用的方式是將這些系統(tǒng)使用事件驅(qū)動(dòng)架構(gòu)。從高一層來(lái)看，這意味著當(dāng)有趣的事情發(fā)生在系統(tǒng)的記錄(SOR)中，我們要求系統(tǒng)能夠發(fā)出事件來(lái)標(biāo)識(shí)當(dāng)前資源已經(jīng)被改變。在上述的背景下具體售票的例子中：當(dāng)一個(gè)客戶購(gòu)買一張票，我們需要票務(wù)系統(tǒng)發(fā)出"創(chuàng)造"事件，標(biāo)識(shí)這張新票，然后,通知其他系統(tǒng)創(chuàng)建了新票。這是圖1所示。

使用EDA應(yīng)用程序有不同的實(shí)現(xiàn)，最常見(jiàn)的是利用企業(yè)服務(wù)總線(ESB)。ESB提供了標(biāo)準(zhǔn)的機(jī)制系統(tǒng)用來(lái)發(fā)布消息給ESB，系統(tǒng)也可以從ESB訂閱消息。消息有兩種形式：

隊(duì)列Queue: 隊(duì)列方便點(diǎn)到點(diǎn)消息傳遞,這意味著消息生產(chǎn)者可以發(fā)送消息到一個(gè)消息消費(fèi)者

主題Topic: 主題使用發(fā)布-訂閱消息傳遞，這意味著消息生成方可以將消息發(fā)布到零個(gè)或多個(gè)訂閱者

隊(duì)列和主題有自己的特定的業(yè)務(wù)場(chǎng)景。例如,如果你想要一個(gè)消息只處理一次，那么就使用一個(gè)隊(duì)列。如果你想發(fā)送一個(gè)消息到一個(gè)特定的目的地，也是使用一個(gè)隊(duì)列。如果你想要一個(gè)消息被任意數(shù)量的其他系統(tǒng)處理，那么使用一個(gè)主題。

因此,在EDA我們傾向于主題,因?yàn)槲覀兿雴⒂眯孪到y(tǒng)能夠訂閱改變現(xiàn)有系統(tǒng)，而無(wú)需改變現(xiàn)有的系統(tǒng)。因?yàn)橄⑸a(chǎn)者不需要知道對(duì)其訂閱用戶，那么我們說(shuō)這兩個(gè)系統(tǒng)之間的關(guān)系是松散耦合的。換句話說(shuō)，如果我們添加一個(gè)新的系統(tǒng)，比如說(shuō)一個(gè)分析系統(tǒng)，用來(lái)跟蹤不同的客人的信息，我們就不需要更新票務(wù)系統(tǒng)來(lái)支持分析系統(tǒng)，分析系統(tǒng)只要訂閱由票務(wù)系統(tǒng)的主題事件即可。圖2顯示了這個(gè)圖形。

圖2顯示了當(dāng)票務(wù)系統(tǒng)引發(fā)一個(gè)事件，客戶檔案服務(wù)以及分析引擎將接收這個(gè)事件。新系統(tǒng)可以訂閱票務(wù)系統(tǒng)的主題和集成它，這些都不需要改變票務(wù)系統(tǒng)。

隊(duì)列必須保證能交付，這意味著當(dāng)一個(gè)消息發(fā)布到隊(duì)列中，ESB將Hold住消息在隊(duì)列中直到有人從隊(duì)列中刪除它。另一方面主題是發(fā)布消息給所有用戶，然后消息即消失。這將導(dǎo)致另一個(gè)問(wèn)題：如果你的主題偵聽(tīng)器死機(jī)了呢？你會(huì)錯(cuò)過(guò)了事件嗎？在正常情況下,答案是"是的"，你將錯(cuò)過(guò)，這就是一個(gè)問(wèn)題！幸運(yùn)的是，大多數(shù)消息代理(ESB的一部分，用來(lái)管理消息)有持久訂戶的概念。如果一個(gè)用戶注冊(cè)成為持久訂戶，那么ESB將Hold住這一信息，直到你的主題偵聽(tīng)器能夠接收消息。從操作的角度來(lái)看，您需要確保所有關(guān)心主題的監(jiān)聽(tīng)器能夠接收所有事件，那么就要以持久durable方式訂閱主題。

輕量和重量事件

事件本身有兩種形式：

輕量Light-weight

重量Heavy-weight

輕量級(jí)事件包含改變資源的標(biāo)識(shí)符,然后需要監(jiān)聽(tīng)器回去調(diào)用SOR獲得資源的詳細(xì)信息。如圖3所示：

重量事件包含事件細(xì)節(jié)，這樣回調(diào)SOR記錄就不需要：

所以你應(yīng)該使用輕量級(jí)還是重量級(jí)事件?這,有一個(gè)權(quán)衡。事件是不能保證同一時(shí)間到達(dá)-事件是異步的。所以如果票務(wù)系統(tǒng)發(fā)布以下事件:

創(chuàng)建票

更新票記錄

將額外特性加入票

但是你接受的事件是如下順序：

創(chuàng)建票

將額外特性加入票

更新票記錄

如果事件擔(dān)負(fù)的機(jī)票信息(重量級(jí)事件)，那，您將創(chuàng)建機(jī)票，將特性添加到票，然后覆蓋機(jī)票已經(jīng)更新的狀態(tài)，這樣機(jī)票最后狀態(tài)就不包括新添加的特性。結(jié)果是，你不會(huì)再有票的當(dāng)前狀態(tài)。怎么解決這個(gè)問(wèn)題？方法之一是要求事件的時(shí)間戳，然后做一些本地處理，以確保你有最新的事件和丟棄任何過(guò)早的事件。

這里存在一個(gè)大量的細(xì)節(jié)工作且容易出錯(cuò)，所以更理想的解決方案是使用一個(gè)輕量級(jí)的事件和回調(diào)。在這個(gè)例子中，票務(wù)系統(tǒng)是票的"真理之源"，所以，當(dāng)你進(jìn)行回調(diào)，你將會(huì)得到保證總會(huì)得到票的正確狀態(tài)。但這是有代價(jià)的，即你的票務(wù)系統(tǒng)需要能夠支持因?yàn)榛卣{(diào)產(chǎn)生額外的負(fù)載。

在當(dāng)前這個(gè)項(xiàng)目中，我們有兩個(gè)場(chǎng)景：新系統(tǒng)可以支持輕量級(jí)事件產(chǎn)生的額外負(fù)載，遺留系統(tǒng),不支持重量級(jí)事件生成的額外的負(fù)載。作為DevOps工程師，你是在最好讓您的開(kāi)發(fā)人員知道這個(gè)建議，因?yàn)槟懔私庀到y(tǒng)是否可以支持額外的負(fù)載。但同時(shí)，如果系統(tǒng)可以支持額外的負(fù)載和選擇輕量級(jí)事件，你需要計(jì)劃基礎(chǔ)設(shè)施可以支持負(fù)載。它并不是小事：在我們的項(xiàng)目中,生成的票務(wù)系統(tǒng)每天超過(guò)500 k的事件,這是一個(gè)大量的額外負(fù)載!

工作流程和手工監(jiān)聽(tīng)

大多數(shù)esb提供工作流的概念，一個(gè)工作流當(dāng)接受到一個(gè)事件然后執(zhí)行可配置的動(dòng)作。如圖4所示：

結(jié)合面向服務(wù)的體系結(jié)構(gòu)與ESB工作流將會(huì)很強(qiáng)大，工作流可以處理事件，執(zhí)行轉(zhuǎn)換并調(diào)用服務(wù)。它使事件處理可配置而不是編碼。

使用ESB工作流的好處是：ESB在其內(nèi)部進(jìn)行事件處理，因此它通常執(zhí)行性能的比自己編寫監(jiān)聽(tīng)器要好。這需要權(quán)衡，如果你使用ESB這種方式，你會(huì)失去可移植性；因?yàn)閼?yīng)用程序業(yè)務(wù)邏輯被包含在ESB中，所以如果你需要將應(yīng)用程序移動(dòng)到另一個(gè)環(huán)境中，需要將ESB一起移動(dòng)。如果另一個(gè)網(wǎng)站是使用不同的ESB，或者他們不想采用ESB，那么所有的業(yè)務(wù)邏輯需要重寫。

另一種選擇是在代碼中手工編寫監(jiān)聽(tīng)器。這些偵聽(tīng)器訂閱適當(dāng)?shù)闹黝}和獨(dú)立于ESB執(zhí)行業(yè)務(wù)邏輯。在這種情況下，您可能不需要一個(gè)完整的ESB，只要message broker即可，通常更便宜。但這種可移植性會(huì)以犧牲性能為代價(jià)。

作為DevOps工程師，您需要知道開(kāi)發(fā)人員是選擇自己手工編寫函數(shù)，如果他們使用工作流，那么你要為ESB需要添加額外的處理能力。如果他們要手工編寫監(jiān)聽(tīng)器，那么你需要考慮esb和聽(tīng)眾之間的額外網(wǎng)絡(luò)帶寬，你需要添加足夠的處理能力來(lái)實(shí)現(xiàn)偵聽(tīng)器。

分割

這取決于你有多少系統(tǒng)集成，您的ESB可能會(huì)從分割中受益性能提高。分割基本上意味著你分配資源單獨(dú)給特定應(yīng)用程序組件，這樣一個(gè)系統(tǒng)的負(fù)載不影響另一個(gè)系統(tǒng)的性能。在我們的大型項(xiàng)目中我們開(kāi)始沒(méi)有分割，但負(fù)載非常高，我們最終創(chuàng)建了8段不同系統(tǒng)，并且分離不同系統(tǒng)之間的事件。設(shè)定應(yīng)用程序擁有自己的消息資源這樣有助于負(fù)載隔離。

ESB替換

雖然esb是實(shí)現(xiàn)EDA主要機(jī)制，但它們不是城里唯一的游戲。正如您可能想到的,：esb有復(fù)雜的配置和管理，每天傳遞數(shù)十萬(wàn)甚至數(shù)百萬(wàn)消息。還有一種方法，我們使用一個(gè)Atom Feed。Atom Syndication Format,下一代的RSS(Really Simple Syndication),是一個(gè)標(biāo)準(zhǔn)的格式發(fā)布web提要和遵循一個(gè)非常HTTP-centric的方法。SOR通過(guò)Atom Feed發(fā)布事件，消費(fèi)者訂閱接收事件。這種模型非常簡(jiǎn)單，會(huì)不再需要ESB，但就像所有技術(shù)一樣都有一個(gè)權(quán)衡：延遲。EDA應(yīng)用程序會(huì)有一個(gè)隱式的延遲。也就是在SOR記錄改變和其他系統(tǒng)變化之間有延遲，但延遲會(huì)很小，當(dāng)使用拉取Polling機(jī)制時(shí)，延遲取決于拉取的間隙時(shí)間。

還有其他系統(tǒng)支持處理事件，如Akka和Apache Storm。