“軟件教父”又開始整理模式了！
Martin Fowler是誰?
我在之前的文章中寫過，他是《重構》、《分析模式》、《企業應用架構模式》、《領域特定語言》等一系列知名書籍的作者，他很少談論操作系統，數據庫，網絡這些底層的東西，也很少聽他談什么高并發，海量用戶， 他也沒有開發過什么知名軟件，但是卻被奉為軟件開發的“教父”。
如果把軟件分層的話，他其實生活在最上層：
這一層擠著很多程序員，因為越往下層，路越難走。必須得能耐得住寂寞，經得起誘惑，對某個領域有著極為精深的研究才可以。
但是Martin Fowler在應用層卻能呼風喚雨，因為他具備一個特殊的能力：擅長把一些軟件開發實踐總結成“概念”。
很明顯，這需要極強的抽象能力。
Martin Fowler最為知名的作品可能就是《重構》，他把軟件編程中各種修改代碼的方法抽象、總結、命名，影響了全世界每一個開發人員。
他還有一本書叫《企業應用架構模式》， Martin Fowler把企業應用開發中的一些最佳實踐分門別類地總結了出來。
比如講領域邏輯模式的“事務腳本”，“表模塊”，“領域模型”，“Service Layer” 等。
講ORM的“單表繼承”，“類表繼承”，“活動記錄”等。
Martin Fowler 絕對是在應用層開發的程序員的榜樣!
前天在瀏覽Martin Fowler的個人網站(https://martinfowler.com/)時，發現了這么一個寶貝：“分布式系統模式”(Patterns of Distributed Systems)。
我不由得心頭一喜：看來Martin Fowler沒閑著，又開始整理模式了，這一次更加宏觀，直接進入了分布式系統!
但仔細一看，略有失望，不是Martin Fowler親自操刀的!是一位叫做Unmesh Joshi 的ThoughtWorks顧問寫的，Martin Fowler給了一些模式方面的指導和幫助。
這兩天看了一下，我覺得質量還是挺高的，比如開篇先講了分布式系統的幾個通用問題：
- 進程崩潰
- 網絡延遲
- 進程暫停
- 非同步的時鐘
進而引出分布式系統的模式是如何解決這些問題的 。
比如非常經典的Write-Ahead Log 模式，可以用來解決進程崩潰時數據的持久化問題：
先把數據當作Command放入持久化的日志文件中，這樣即使KVStore進程崩潰，在重啟以后依然可以從日志中恢復數據。
人家很清楚程序員的交流語言是代碼， 所以馬上給出了簡單的代碼片段來幫助理解細節，真是很貼心。
- class KVStore…
- public KVStore(Config config) {
- this.config = config;
- this.wal = WriteAheadLog.openWAL(config);
- this.applyLog();
- }
- public void applyLog() {
- List<WALEntry> walEntries = wal.readAll();
- applyEntries(walEntries);
- }
- private void applyEntries(List<WALEntry> walEntries) {
- for (WALEntry walEntry : walEntries) {
- Command command = deserialize(walEntry);
- if (command instanceof SetValueCommand) {
- SetValueCommand setValueCommand = (SetValueCommand)command;
- kv.put(setValueCommand.key, setValueCommand.value);
- }
- }
- }
- public void initialiseFromSnapshot(SnapShot snapShot) {
- kv.putAll(snapShot.deserializeState());
- }
現在已經整理出來的分布式系統模式有這些：
為什么向大家推薦這個資料呢?是因為網上有很多分布式理論的文章，干巴巴的，看不了一頁就想放棄。
網上也有很多源碼分析的文章，專注于貼代碼，糾纏于細節，讓人云里霧里。
Unmesh Joshi的分布式系統模式則是個很好的平衡：既有理論，又有代碼細節。
如果你是一個剛入行的新手，看這些東西可能有些吃力，因為需要有分布式系統的基礎，不妨先收藏，等待以后再看。
如果是一個經驗豐富的老手，我強烈推薦你去看一看，觀摩下這些大牛們是怎么從各種復雜的場景中抽取出通用的模式的，絕對受益非淺， 你可能有這樣的感覺：這種工作我怎么就沒想到呢?
當然，這是英文的材料， 會有一定的障礙，不過你看了就知道，并沒有用什么高級的詞匯，我列幾句大家感受感受：
Processes can crash at any time. Either due to hardware faults or software faults. There are numerous ways in which a process can crash.
It can be taken down for routine maintenance by system administrators.
It can be killed doing some file IO because the disk is full and the exception is not properly handled.
并不難，對吧?嘗試看一下吧，閱讀英文資料也是一項重要的技能。
鏈接在此：https://martinfowler.com/articles/patterns-of-distributed-systems/
【本文為51CTO專欄作者“劉欣”的原創稿件，轉載請通過作者微信公眾號coderising獲取授權】
