摘要：問你為什么要為仿真測試編寫工具這個項目的進展如何雖然我經(jīng)常會提到，但是這個工具是在的架構(gòu)基礎(chǔ)上寫的。現(xiàn)在，我在忙一個叫做解決方案藍圖的項目，無論是否用到，這個工具都可以幫助人們完成仿真測試。

  
非商業(yè)轉(zhuǎn)載請注明作譯者、出處，并保留本文的原始鏈接：http://www.ituring.com.cn/article/195743

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

問：您曾經(jīng)在博客中說過可能會寫幾本新書（Three Book Ideas），有最新的進展嗎？

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

問：《發(fā)布！》中提到的一些模式現(xiàn)在已經(jīng)被廣泛采用，如 Circuit Breaker，已經(jīng)有了 Netflix 的 Hystrix 這樣漂亮的實現(xiàn)，考慮到《發(fā)布！》是一本2007年出版的書，如今8年已經(jīng)過去，你是否看到了一些新的穩(wěn)定性/容量模式？

有一種重要的模式，它通過兩種方式顯示出來：異步式和反應(yīng)式。我把它們看做一個硬幣的兩面。因為很多穩(wěn)定性模式都要依靠阻塞線程才能起作用，所以這兩種方式都有用。

問：有時候簡單的錯誤就會造成整個系統(tǒng)宕機，這難道僅僅是程序員的一行代碼造成的嗎？可以引入什么機制來保證復(fù)雜系統(tǒng)的穩(wěn)定性呢？

很多問題事實上就是一行代碼引起的，但是總是有其他因素來放大這個問題。外部環(huán)境的變化可能會導(dǎo)致一個潛在的錯誤顯現(xiàn)出來。或者一位操作員的活動可能會觸發(fā)平時不會執(zhí)行的代碼，從而導(dǎo)致問題出現(xiàn)。

有一些問題則是因為系統(tǒng)的大規(guī)模結(jié)構(gòu)而產(chǎn)生的。比如，我并不喜歡SOA中的“實體服務(wù)”模型。原因是每個應(yīng)用都需要很多實體。概率的規(guī)則告訴我們當所有實體服務(wù)都不工作的時候，擴展的系統(tǒng)很可能會出現(xiàn)故障。

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

問：復(fù)雜的業(yè)務(wù)會導(dǎo)致復(fù)雜的系統(tǒng)嗎？作為一位架構(gòu)師，如何做到不傷害正常業(yè)務(wù)處理流程的同時又保持架構(gòu)簡單？

到目前為止，我沒有發(fā)現(xiàn)復(fù)雜業(yè)務(wù)和復(fù)雜系統(tǒng)之間的關(guān)聯(lián)性。我知道的系統(tǒng)復(fù)雜度的最強的預(yù)示變量就是規(guī)定。

問：DevOps和傳統(tǒng)運營工程師有什么區(qū)別？

DevOps強調(diào)同感。在DevOps的文化中，開發(fā)者關(guān)心他們的應(yīng)用如何影響運營者們的生活。我的應(yīng)用要求管理員必須在半夜保持清醒來做部署嗎？我怎么改變我的應(yīng)用才能讓她能少花時間在終端上，從而擁有更多的時間和家人在一起？運營作為報答：我們?nèi)绾尾拍軇?chuàng)造一個更好的環(huán)境，讓開發(fā)者帶著勇氣創(chuàng)造并傳遞價值？

問：從2007年的C/S和B/S到現(xiàn)在的App和NoSQL，互聯(lián)網(wǎng)行業(yè)已經(jīng)經(jīng)歷了重大變革。很多敏捷方法都已經(jīng)有所進化。這些年軟件發(fā)布都發(fā)生了哪些變化？還有什么是不變的？

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

首先是Sun和微軟兩家公司統(tǒng)治的覆滅。在以前，幾乎所有公司的軟件開發(fā)都要用Java或 .Net，輔以當時發(fā)展迅速的Ruby on Rails社區(qū)。今天，經(jīng)常可以見到使用不同語言和運行時環(huán)境的系統(tǒng)。

第二，云部署環(huán)境已經(jīng)戲劇性地改變了經(jīng)濟。

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

問：隨著移動互聯(lián)網(wǎng)的興起，云服務(wù)的成熟，IT行業(yè)在發(fā)生天翻地覆的變化。作為一名架構(gòu)師，應(yīng)該重點關(guān)注哪些技術(shù)理念？

企業(yè)架構(gòu)師之前關(guān)注的是圖表中“方盒內(nèi)”的技術(shù)。也就是說，他們的目標是執(zhí)行細節(jié)完備的標準化技術(shù)。

在現(xiàn)在的世界里，我認為架構(gòu)師應(yīng)該更加關(guān)心數(shù)據(jù)格式和數(shù)據(jù)表示法。也就是說，他們應(yīng)該關(guān)心的是箭頭，而不是方盒。

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

我并不適合回答這一問題。我只能說我看到很多開發(fā)者都在朝著函數(shù)式編程轉(zhuǎn)型。

問：在Cognitect，每周五開發(fā)者都會花時間在業(yè)余項目和開源軟件上。20%的總體工作時間是一個很大的比例。你們在這個每周都舉辦的活動中得到了什么收獲？這些收獲是否彌補了時間上的損失？

我們利用20%的時間創(chuàng)造了一些很多人都認可的項目，其中包括web框架Pedestal，以及最初的ClojureScript實現(xiàn)。今天，我們20%時間仍然用來開發(fā)Clojure，ClojureScript，Pedestal，以及其他一些新玩意兒，我們不久之后就會揭曉。

很長時間以來，我們一直都有一個習慣，就是質(zhì)疑我們對軟件開發(fā)最基本的假設(shè)，我們通過檢驗自己的工作來找到構(gòu)造軟件更好的方法。在20%時間里我們也是這么做的。所以這項活動并不是我們一直在做的一個愛好或日常工作。我們經(jīng)常要評估這樣做是否值得。

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

問：你為什么要為仿真測試編寫工具Simulant？這個項目的進展如何？

雖然我經(jīng)常會提到Simulant，但是這個工具是Stuart Halloway在Rich Hickey的架構(gòu)基礎(chǔ)上寫的。

Simulant程序庫現(xiàn)在處于穩(wěn)定狀態(tài)。我的目標在于幫助人們成功地應(yīng)用這個工具。為此，我去年開了一個關(guān)于Simulant的網(wǎng)絡(luò)研討會。同時我也做了一個樣本項目，你可以在GitHub上找到。（https://github.com/mtnygard/simulant-example）

現(xiàn)在，我在忙一個叫做“解決方案藍圖（solution blueprint）”的項目，無論是否用到Simulant，這個工具都可以幫助人們完成仿真測試。