架構師一直是程序員「羨慕且追求」的高度，今天來說說我（奈學教育CEO：孫玄）眼裏優秀的架構師該如何定義。畢竟我也曾經是一名架構師：
在開始今天的話題之前我說一個和我前公司P9現在已經是P10的對話。
問題是這樣的他說公司中間件架構師不熟悉公司業務，很多事落地不了，非常的疑惑。他最近主要任務就是和這些架構師聊天解惑：）
接着他說了一個類比的故事大概是這樣的，
我們（架構師）要建設一條高速公路，來分別看看公路建造者（架構師）和司機（業務研發）的視角。
1，建造者 他們選用最好的沙子 水泥 更好的設計圖紙和操作流程保證質量和處理異常情況（比如出入口提示，超車，緊急停車帶）
2，司機同志 他們關心什麼？
司機關心路寬麼，有堵車可以提前告知麼。
司機關心路平整麼？當然關心，關心。
引出一個的問題：司機（業務研發）關心用最好的水泥麼 ？
想象你是司機（業務研發）你你關心嗎？
A，關心
B，不關心
歡迎留言留下你的思考。
我覺得一名優秀的架構師，在設計系統時需要有以下這四項關鍵能力：「平衡取捨、預判未來、抽象思維、容錯機制」。
- 平衡取捨
一個架構本質上總會有優有劣，它不可能是完美的、普適的，也不存在一個架構在 A 場景能用，在 B 場景也最適用的情況，所以就需要我們準確判斷，作出取捨。
我們可以根據具體的業務需求來調整架構，也就是以當前的業務需求，選出最匹配的架構。另外，架構師還需要根據現狀衡量好需求和資源、效率和安全、時延和吞吐等等之間的關係，做出判斷。
比如對於在線交易系統，可能更重要的是保證它的低時延，因此就可以犧牲一定的吞吐量，而對於離線系統，吞吐量則更重要一些。
- 預判未來
架構師需要具備一定的未來的預判能力，因爲架構的調整週期通常比較長。這也是程序員和架構師之間一個很大的區別所在。
程序員負責一個項目，在當前的互聯網大背景下，項目的迭代週期非常快，基本以天或周爲單位，最多一個月。如果發現不合適的代碼，需要重構，程序員基本也能在幾天或幾周內就能完成重構。
而架構的調整是相對漫長的過程，可能需要數月，甚至要幾年。因此，在設計架構時就需要架構師具備預判意識，對很多不確定的事情做出預判和選擇，諸如未來訪問量會增長到什麼量級，會不會產生新的業務，這些會對系統產生什麼樣新的要求等等。
- 抽象思維
除了懂得取捨和擁有預判意識，架構師在設計架構時還要掌握抽象的方法，不能鬍子眉毛一把抓，要做好分層和區隔。
因爲架構師面對的是一個很龐大的系統，爲了避免過早陷入細節，不要去看各個組件的細節，而是把它們的角色定義下來之後，再分塊來思考。而在看每個分塊時，其他分塊都可以視爲一個抽象的概念，另外，也需要考慮複用的問題。
舉個例子，我之前在某送餐平臺做在線客服機器人，就運用了分層思想，並且高複用，一個對話機器人可以完成各種各樣的業務需求。這其實是一個非常複雜的系統，裏面有各種各樣的對話機器人的模塊，有的特別適合去做檢索式的查詢，還有的適合做任務導向的、產品推薦導向的對話等等。
我們把對話機器人抽象成一個通用的接口，再將它分爲一個個小機器人。這樣一來，每個小機器人只需要關注自己的業務模塊就行了。然後，我們會在前端再引入一個路由機器人，由路由機器人根據當前對話管理的狀態，來判斷當前的對話應該交給哪個小機器人去完成。這就是典型的分層的思想。
- 容錯機制
相比程序員，架構師面對的環境要惡劣的多，因爲系統更復雜了，出錯的概率也增加了，每個節點、每個功能都有可能出錯，所以這就需要架構師爲錯誤而設計（Design For Failure），事先提前做好解決方案。
除了應用出錯，還有可能產生數據丟失的情況，這個可以通過備份來預防。
另外，如果出現故障，該怎樣做到快速恢復呢？我們現在普遍的做法是不修只換，因爲如果要修復一個異常狀態，可能修復後還會出現連帶問題，而如果能通過技術手段，刪除已出現的故障，換一個全新的系統，就能夠保證它迅速恢復到正常狀態。