你的SOA已經使用了EDA和CQRS嗎?

13-06-08 banq
                   

來自2013年4月底的 IDDD Tour 演講:你的SOA已經使用了EDA和CQRS嗎?(What SOA do you have (with extended EDA and CQRS material)),談論了DDD + CQRS +EventSourcing等面向領域的新思想和新技術如何對傳統架構發展。

下面我簡要對這篇長達274頁的PPT進行大概翻譯并闡述自己觀點如下:

現在SOA這么多年實踐下來,面臨的問題:

1.碎片化

2.開發和維護成本很高

3.服務無法被重用。

4.當你認為SOA是整合利器時,它自身成了問題根源。

5.沒有人再愿意開發和維護服務

6.系統性能相當差。

老體系的SOA風格如下:

當一個客戶希望買到一件裙子時,產生訂單的服務將涉及設計部門 客戶部門 財務部門和生產部門等,比如檢查生產部門是否有類似原料等,然后才能創建一個訂單。如下圖,注意圖中箭頭方向,訂單服務是主動地去和多個部門的服務交互,如果其中一個子服務沒有準備好,將導致業務堵塞等待。



                   

13
banq
2013-06-08 11:03

上圖中傳統的SOA還帶來可伸縮性Scalable的問題,難以水平擴展,如果是京東 蘇寧這種電商,面對尖峰時刻的巨量訂單創建,傳統SOA幾乎沒有解決方案。

而使用EDA事件驅動架構和本地緩存策略,如下圖,各個模塊子服務只要將自己的狀態主動提供給訂單服務,而不是訂單服務主動去調用這些子服務,順序倒過來,只能靠事件驅動了,就這么簡單。


banq
2013-06-08 11:14

這一切只是剛剛開始。

讓我們回顧過去40年計算機界做了些什么,我們花了很多努力將手工流程搬到了用軟件實現,因為信息化過程是逐步的,導致這些系統之間是隔離獨立的,很難整合在一起。

這時我們有在數據庫層面的整合方案,有在應用層面的整合EAI,使用WebService,使用ESB。但是這些方案都不便宜,不簡單。

現在我們有更簡單的解決方案。

重溫一下SOA四原則:

1.邊界是顯式的

2.服務分享的是Schema和合約Contract,不是類

3.服務基于策略兼容

4.服務是自治的。

對于一個業務領域,我們難道真的只需要一個領域模型就可以全部代表他們嗎?

下圖是零售領域的模塊圖:


banq
2013-06-08 11:21

對于上圖中零售領域,我們不能再用傳統領域建模方式或者ER建模方式,結果會得出一個蜘蛛網式的大領域模型,雖然有很多類在里面,但是因為類之間都存在關聯,實際還是一個大的領域模型。

對于零售領域,我們可以從不同利益相關者角度看待它,能夠得出不同人群眼中的模型。

下圖一表達不同人看待零售領域有自己的觀點,比如數據庫認為數據的生命周期很重要,圖二表達使用DDD提供解決方案,每個模塊其實是DDD中的有界上下文,模塊整合是上下文之間共享實體標識罷了。



banq
2013-06-08 11:27

由于服務分散在不同系統中,這種自治分離狀態為整合帶來問題,如果一個大服務需要調用分散在其他服務器上的幾個子服務,如何保證整個大服務的事務性?

采取分布式事務嗎?XA或兩段事務?

分布式事務的問題是性能慢,鎖的時間無法預計。鎖本身無法伸縮擴展。

那么使用同步通訊(如RMI)等方式?如下圖:


5Go 1 2 3 4 ... 5 下一頁
美女漫画大全