《發佈！》做者Michael Nygard：質疑軟件開發最基本的假設

非商業轉載請註明做譯者、出處，並保留本文的原始連接：http://www.ituring.com.cn/article/195743

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，這個工具均可以幫助人們完成仿真測試。

---

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