服務與資料之爭

banq發表於2018-08-22
SOA是面向服務的架構,大資料是處理大規模資料,這兩個門派其實還是有很大區別的。

服務是一種物件化概念,一個服務包含很多函式方法,基於服務的治理從服務註冊發現 整合 路由和流程; 資料處理從函數語言程式設計到資料流。

問題來了,服務跟著資料跑,還是資料跟著服務跑? 如果能夠發現業務邊界與上下文,把資料與服務就能自然聚合在一起,DDD是有關資料聚合發現的方法,找到聚合單元,服務跟著跑。然後基於這些服務設計流程,透過流程整合實現資料整合,問題是為什麼會有這些流程? 為什麼政府大企業流程多?部門多,人多,所以,是人的過多介入導致了偏重服務的設計,然後再透過流程整合在一起,這是一種初級資訊化。

如果業務無邊界,或者說我們不根據現實去設計我們的系統,而是真正研究資料自己跑的規律,這時候我們就先有資料了,這些資料雖然是人產生出來的,但是我們不從人那裡下手,而是直接面對資料,資料一直在產生,如同水流,就是資料流,透過資料流處理,實時分析結果,那麼計算功能可以用服務實現,直接用細粒度的函式實現更好,如果雲端計算提供基於函式的呼叫,函式代表一個服務。

至此,服務與函式以及資料流在雲原生架構下得到統一,你可以把資料抓到服務裡面計算,也可以把計算規則分配到資料所在地去計算,這兩種方式根據不同場景選擇,雖然只有兩個選項,但是經常在瘋狂編碼中忘記方向,只顧埋頭插秧,忘記直腰看方向,結果插歪了。

兩個方向不同還決定事務架構不同,服務第一公民的方向就要事務引入到服務中,什麼JTA XA,補償式事務 柔性事務,分散式情況下CAP定理又來束縛你,但是如果以資料流為主的架構,資料流過來是一個個進行處理,沒有多個服務爭改一個狀態資料情況出現,資料流處理具有天然事務性,資料庫裡面的事件日誌就是把SQL操作看成事件流進行實時流處理,資料表只不過是資料流的快取,一個檢視而已,一個靜態切片,時光生涯中一剎那,是照片和電影影像流的區別,說白了,維度空間不同。

相關文章