服務與資料之爭

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

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

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

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

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

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

相關文章