專注資料才能發現邏輯

banq發表於2014-09-26
英文有句話：Focus on the data, not on the logic. The logic will emerge when you understand the data( 專注於資料，而不是邏輯。當你理解了資料，邏輯將出現)。 從這裡看出資料和邏輯的顯隱關係，這大概也是50年的資料庫系統構建 版本控制系統和物件導向語言能夠告訴我們的。

隨著Docker與DevOps的興起，開發人員與運維人員正在融合，而業務日誌應該是研發人員與運維人員的橋樑，也是每個研發人員必須掌握的資料抽象。來自LinkedIn的Kreps釋出了其具有程式設計師史詩般的博文：日誌是每個軟體工程師關心的統一資料抽象

Kreps首先指出日誌以前都是用來記錄資料庫交易的記錄，以防止出現錯誤或應用崩潰後，能夠撤銷之前的更改操作，或者在磁碟等媒介出問題後重新執行這種更改操作，以及用來做簡單的審計和附加資訊的修訂。

他很有見地提出分散式狀態機對於分散式系統設計的重要性：

“你可以把用多臺機器一起執行同一件事情縮減為為這些程式輸入分散式一致性的日誌資料。這裡使用日誌的目的是把所有非確定性的東西排除在輸入流之外，這樣來確保每個複製都能夠同步地處理輸入。”

其中將非確定性排除出輸入流之外非常亮眼。因為這點非常容易被忽視。

Kreps在考量了各種各樣的歷史資訊系統的使用，提出如下觀點：

“這可能會引起你對原始碼版本管理的聯想。原始碼管理和資料庫之間有密切關係。版本管理解決了一個大家非常熟悉的問題，那也是分散式資料系統需要解決的--- 時時刻刻在變化著的分散式管理。版本管理系統通常以補丁的釋出為基礎，這實際上可能是一個日誌。您可以直接對當前原始碼 類似於表一樣做出一份"快照"。你會注意到， 與其他分散式狀態化系統類似，版本控制系統在 當你更新原始碼時會複製到日誌，當你提交新程式碼時，你只是將更新應用到你的當前快照中而已。 ”

這個觀點實際指出關於系統的歷史業務資料非常有價值的，我們只能在資料庫中獲得某個當前的狀態，而無法知道是透過如何操作得到當前的狀態。而業務日誌則儲存了系統的歷史運算元據。

一個日誌處理系統和版本控制系統之間是有差異的,日誌處理系統只記錄一個時間表，在版本控制系統允許您有多個行歷史。版本控制系統提供基本分支和合並功能，這使得它們比資料庫系統更復雜和更強大。

Kreps提出了資料表與事件是一對情侶，它們相互印證：

“這些日誌有點類似借貸清單和銀行的流程，資料庫表記錄的是當前的盈餘表。如果你有大量的操作日誌，你就可以使用這些操作從而建立可以捕獲當前狀態的表”

這個觀點和我們在領域事件/CQRS架構倡導的狀態和事件分離是一致的，從某種程度上將，我們使用EventSourcing來記錄領域事件然後播放，也是為了獲得系統某個時刻的狀態快照，這種原理與資料庫內部的日誌作用是同樣的，因此，可以看出我們使用DDD + CQRS + EventSourcing實際是將開啟資料庫這個盒子，直接用物件導向程式語言實現一個基於記憶體資料庫系統而已。

更重要的是，Kreps提出三種日誌的用途。
1.資料整合—能讓一個公司的所有資料容易整合儲存和處理。
2.實時流資料處理—以資料流方式計算
3.分散式系統設計—以日誌為中心的設計能簡化實踐中的分散式系統。

具有幾十年從業經驗的人說：我是從資料庫系統開始我的職業，我一直致力於傳統的日誌恢復工作中，還有設計實現類似的系統，然後將我的職業的三分子時間花在分散式系統上，花費了我大量時間在服務的複製上，使用非同步的日誌以確保資料的一致性。這意味著我過去三十年都是在和日誌打交道。

如果你是一個軟體工程師,你會在你的公司中聽到開發人員談論日誌、複製、日誌傳送等類似的話題,如果你想了解更多,你應該花一些更多時間閱讀Kreps這篇程式設計師史詩般的文章：

日誌是每個軟體工程師關心的統一資料抽象

相關文章