《釋出！》作者Michael Nygard：質疑軟體開發最基本的假設（圖靈訪談）

Michael T. Nygard是一位從業二十餘年的資深程式設計師，現任Cognitect首席架構師，他被譽為線上業務的“流動解決問題專家”。Nygard曾先後為美國政府、軍隊、銀行、金融、農業和零售等多個行業交付過運營系統，這種實際運營的經歷改變了他對軟體架構的看法，也讓他對在相當不友好的環境下構建高效能、高可靠性的軟體有了獨特的見解。他寫過多篇文章和社論，是軟體架構經典著作《架構之美》和《軟體架構師需要知道的97件事》的作者之一。Nygard最新出版的著作《釋出！軟體的設計與部署》詳細展示了軟體釋出前可能出現的種種問題以及相應的解決之道，書中所有主題都是通過作者自己研究過的真實案例來闡述的。

問：您曾經在部落格中說過可能會寫幾本新書（Three Book Ideas），有最新的進展嗎？

任何時候，如果你問一位作者這個問題都會得到很有趣的回應。他會看起來很緊張，開始出汗，然後含糊地說一些並不連貫的話，同時他還會急迫地尋找最近的出口。我要說的是，現在這個階段我還沒有什麼好宣佈的。

問：《釋出！》中提到的一些模式現在已經被廣泛採用，如 Circuit Breaker，已經有了 Netflix 的 Hystrix 這樣漂亮的實現，考慮到《釋出！》是一本2007年出版的書，如今8年已經過去，你是否看到了一些新的穩定性/容量模式？

有一種重要的模式，它通過兩種方式顯示出來：非同步式和反應式。我把它們看做一個硬幣的兩面。因為很多穩定性模式都要依靠阻塞執行緒才能起作用，所以這兩種方式都有用。

問：有時候簡單的錯誤就會造成整個系統當機，這難道僅僅是程式設計師的一行程式碼造成的嗎？可以引入什麼機制來保證複雜系統的穩定性呢？

很多問題事實上就是一行程式碼引起的，但是總是有其他因素來放大這個問題。外部環境的變化可能會導致一個潛在的錯誤顯現出來。或者一位操作員的活動可能會觸發平時不會執行的程式碼，從而導致問題出現。

有一些問題則是因為系統的大規模結構而產生的。比如，我並不喜歡SOA中的“實體服務”模型。原因是每個應用都需要很多實體。概率的規則告訴我們當所有實體服務都不工作的時候，擴充套件的系統很可能會出現故障。

所以，我會努力在微觀和巨集觀範圍內都讓系統具有更大的恢復力（甚至是穩健性）。在微觀層面上，我使用書中提到的設計模式。在巨集觀層面上，我分析系統的“故障域”。也就是說，當一個部件（硬體或軟體）壞掉的時候，受影響的應用和功能的範圍有多大？通過在應用間重新分配功能和把實體拆分成小平面，總有辦法把系統分割成獨立的故障域。

問：複雜的業務會導致複雜的系統嗎？作為一位架構師，如何做到不傷害正常業務處理流程的同時又保持架構簡單？

到目前為止，我沒有發現複雜業務和複雜系統之間的關聯性。我知道的系統複雜度的最強的預示變數就是規定。

問：DevOps和傳統運營工程師有什麼區別？

DevOps強調同感。在DevOps的文化中，開發者關心他們的應用如何影響運營者們的生活。我的應用要求管理員必須在半夜保持清醒來做部署嗎？我怎麼改變我的應用才能讓她能少花時間在終端上，從而擁有更多的時間和家人在一起？運營作為報答：我們如何才能創造一個更好的環境，讓開發者帶著勇氣創造並傳遞價值？

問：從2007年的C/S和B/S到現在的App和NoSQL，網際網路行業已經經歷了重大變革。很多敏捷方法都已經有所進化。這些年軟體釋出都發生了哪些變化？還有什麼是不變的？

我認為有三件事變化最大：

首先是Sun和微軟兩家公司統治的覆滅。在以前，幾乎所有公司的軟體開發都要用Java或 .Net，輔以當時發展迅速的Ruby on Rails社群。今天，經常可以見到使用不同語言和執行時環境的系統。

第二，雲部署環境已經戲劇性地改變了經濟。

第三點同時很大程度上也是前兩點造成的結果，開源操作工具已經使高可靠性的運營變得大眾化。在2007年的時候，需要花費上百萬美元才能做好資料中心自動化，集中管理，以及監控。如今，你可以下載所有這些。

問：隨著移動網際網路的興起，雲服務的成熟，IT行業在發生天翻地覆的變化。作為一名架構師，應該重點關注哪些技術理念？

企業架構師之前關注的是圖表中“方盒內”的技術。也就是說，他們的目標是執行細節完備的標準化技術。

在現在的世界裡，我認為架構師應該更加關心資料格式和資料表示法。也就是說，他們應該關心的是箭頭，而不是方盒。

問：Cognitect使用的程式語言主要是Clojure，這和大部分公司使用的主流語言（C / Java / C#）不同。你認為未來的程式語言會變成什麼樣？

我並不適合回答這一問題。我只能說我看到很多開發者都在朝著函數語言程式設計轉型。

問：在Cognitect，每週五開發者都會花時間在業餘專案和開源軟體上。20%的總體工作時間是一個很大的比例。你們在這個每週都舉辦的活動中得到了什麼收穫？這些收穫是否彌補了時間上的損失？

我們利用20%的時間創造了一些很多人都認可的專案，其中包括web框架Pedestal，以及最初的ClojureScript實現。今天，我們20%時間仍然用來開發Clojure，ClojureScript，Pedestal，以及其他一些新玩意兒，我們不久之後就會揭曉。

很長時間以來，我們一直都有一個習慣，就是質疑我們對軟體開發最基本的假設，我們通過檢驗自己的工作來找到構造軟體更好的方法。在20%時間裡我們也是這麼做的。所以這項活動並不是我們一直在做的一個愛好或日常工作。我們經常要評估這樣做是否值得。

到目前為止我們覺得這項活動是很有價值的。當我們說，我們想讓軟體開發對於每個人來說都變得更好時，我們是認真的。我們的開源工具就是其中的一部分。

問：你為什麼要為模擬測試編寫工具Simulant？這個專案的進展如何？

雖然我經常會提到Simulant，但是這個工具是Stuart Halloway在Rich Hickey的架構基礎上寫的。

Simulant程式庫現在處於穩定狀態。我的目標在於幫助人們成功地應用這個工具。為此，我去年開了一個關於Simulant的網路研討會。同時我也做了一個樣本專案，你可以在GitHub上找到。（https://github.com/mtnygard/simulant-example）

現在，我在忙一個叫做“解決方案藍圖（solution blueprint）”的專案，無論是否用到Simulant，這個工具都可以幫助人們完成模擬測試。

---

更多精彩，加入圖靈訪談微信！