#分佈式系統架構之# 事件驅動模式以及與之匹配的長時間處理過程討論

      在分佈式系統下，能夠不少種架構從事設計，或者分佈式系統對技術架構自己沒有作嚴格的限制。可是結合本身的實踐以及基於《領域驅動設計》的推薦， 採用 【事件驅動模式】是比較好的一種分佈式系統架構方式。該模式充分實現了 不一樣系統之間的代碼解耦，全部的業務流轉是經過事件廣播進行驅動的。全部業務都是在針對 名爲【事件總線】的組件在編程，也無需知道事件的生產者，每一個業務只監聽本身感興趣的事件，而後根據事件觸發不一樣的業務代碼 以及 本身在處理完某種業務後，也對外廣播發出事件，則標誌着當前業務的完成。

      基於【事件驅動模式】是一種比較接近人類天然行爲的一種模式，該模式給系統的解耦以及重構帶來了先天優點。相對比與傳統的業務模式，大量的業務流程都是基於代碼或者是某種規則引擎加以實現，而 事件驅動模式 則是針對事件總線註冊監聽， 【事件總線】老是可以忠實的把消息投遞給感興趣的監聽者，而且保證其對應業務邏輯的天然觸發。一旦有業務變更，咱們僅僅是在【事件總線】上增長 或者 移除對應的事件消費者，或者註冊新的事件發佈者，這種行爲並無影響到當前的業務代碼變更。 用平常通俗講法：更加接近於  小學老師講課，老師經常會不自覺的吼一聲：「小朋友們，記住了嗎？」這時，這要是聽到該諮詢的小朋友 都會迴應道：「聽懂了」，在此過程當中 ，聲音做爲事件、空氣做爲事件總線（忠實的傳遞事件到達監聽者），若是這個時候，小學的校長在教師邊走過，那麼老師的諮詢一樣也被校長聽到，可是校長對此不做任何反應，應爲該事件對於校長而言，是不關心的事件，因此直接忽略。仍是忙他本身的事情。

      引入事件驅動，讓複雜的系統變得很容易，由於軟件就是一直在模仿人類的神經傳輸，事件驅動是一種比較好的模仿行爲。這個時候，你們會問，事件驅動，關鍵是事件的定義，以及在什麼狀況下發布事件呢？這個時候 就須要討論的深刻一點，事件是對一種業務行爲完成的標識，只有當某一獨立的原子業務執行完畢，就要對外發布事件。事件更多的需求術語爲：當。。。。。。就該。。。。。。，相似的語境，剛好就是事件驅動完美的體現。  在方法的設計上，咱們能夠把方法拆分爲 讀方法 與 寫方法，所謂的 讀方法就是 該方法內部不對任何數據進行家修改，而是經過一個簡單的疊加，組裝，把數據有效的輸出，而寫方法剛好相反，寫方法體如今對對象的修改上（並實現最終的持久化操做），全部的事件 是在 寫方法中產生。這個之後做爲單獨的文章描述，爲什麼如此設計呢？爲了保證分佈式下，數據的一致性等。

    一旦引入事件驅動，則事件發佈者永遠不知道到底有多少消費者在監聽該事件，並且當消費者收到事件後，是否正確的處理完其對應的業務，仍是中途發生異常呢？事件的驅動是 採用同步方式仍是異步方式呢？這就是引入【事件驅動】後，先天不足的一面，因此咱們須要在架構上考慮這種不足，經過其餘的技術手段來消除這種不足，從而變得穩定可靠。 這樣就引出了本文另一個 所要講述的話題：長時間過程處理過程的方案，該方案的提出，就是爲了解決事件驅動模式下，事件生產者與消費者 在互相不知道對方存在的狀況下，而有效的協調完成一個更加的業務呢？

    長時間過程處理（業務有專門的術語 稱之爲 Saga），經過我的的整理以及本身的理解，針對長時間過程處理 通常分爲三種解決方案，經過技術手段使得【事件驅動模式】可以更好的爲咱們服務，三種方案分別以下：

   一、把處理過程設計成爲一個組合任務，使用一個執行組件對任務進行跟蹤，而且對每個步驟和任務的完成狀況進行存儲（持久化），而後再根據執行的結果決定是否啓動下一個業務環節。該方案更像是責任鏈模式的靈活應用，缺點是 一開始就須要把該事件 可能觸發的子任務進行備案，並對其執行結果進行登記註冊，顯然，這種方式適合於業務場景比較固定的狀況。

二、同第一種方案相似，一樣把處理過程設計爲一個聚合，聚合成爲活動協做的中心，一個或者多個聚合的實例充當之心任務的組件並維護過程當中產生的異常等

三、第三種是設計一種 無狀態的事件跟蹤器，該跟蹤器每個事件的消費者的事件獲取與執行狀況，而且把執行結果反饋給跟蹤器，該跟蹤器獲取結果後對其進行存儲，這樣不斷的累加事件在消費過程當中不斷增長的處理結果，這樣能夠跟蹤到事件流轉的所有狀態，而且按照存儲的事件結果，決定是否正常執行完其一個完整的業務，該方案適合於消費者動態的場合，每一次事件的發佈，均可以保證到期監聽者對事件的消費以及結果的持有，只有當全部事件的狀態是正常的，才能肯定這個業務是完整的。

     三種方案，第二種對代碼的耦合度比較大，不建議使用，可是第二種方案是傳統編程下最常採用的一種模式。  本人比較傾向於使用 第三種方案， 該方案如同人類神經網絡同樣，複雜而各司其職。

     若是你們要體驗這種機制，單機模式 推薦採用 guava 自帶的 eventbus做爲模擬的事件總線

    若是是分佈式模式 可考慮引入MQ 中間件做爲消息總線。（事件更多的是應用爲 P/S) 模式。

   另外須要提出的一點是：事件內容能的設計，出了基本類型 就是基本類型，全部的業務事件數據都應當爲 某種字符串的展示，如XML、JSON等。。。。。。   另外，事件的發出是有順序的，這一點也須要引發注意。。。。。

      2016年 開年過的有點 綱目不清，仍是須要本身多檢討，借用王守仁的 心學 「須要在事上下功夫，遇事多磨練本身的心裏」。。。。。。