架構師應該具備哪些思維模型？

架構師一直是程式設計師「羨慕且追求」的高度，今天來說說我（奈學教育CEO：孫玄）眼裡優秀的架構師該如何定義。畢竟我也曾經是一名架構師：

在開始今天的話題之前我說一個和我前公司P9現在已經是P10的對話。

問題是這樣的他說公司中介軟體架構師不熟悉公司業務，很多事落地不了，非常的疑惑。他最近主要任務就是和這些架構師聊天解惑：）

接著他說了一個類比的故事大概是這樣的，

我們（架構師）要建設一條高速公路，來分別看看公路建造者（架構師）和司機（業務研發）的視角。

1，建造者 他們選用最好的沙子 水泥 更好的設計圖紙和操作流程保證質量和處理異常情況（比如出入口提示，超車，緊急停車帶）

2，司機同志 他們關心什麼？

司機關心路寬麼，有堵車可以提前告知麼。

司機關心路平整麼？當然關心，關心。

引出一個的問題：司機（業務研發）關心用最好的水泥麼 ？

想象你是司機（業務研發）你你關心嗎？

A，關心

B，不關心

歡迎留言留下你的思考。

我覺得一名優秀的架構師，在設計系統時需要有以下這四項關鍵能力：「平衡取捨、預判未來、抽象思維、容錯機制」。

1. 平衡取捨

一個架構本質上總會有優有劣，它不可能是完美的、普適的，也不存在一個架構在 A 場景能用，在 B 場景也最適用的情況，所以就需要我們準確判斷，作出取捨。

我們可以根據具體的業務需求來調整架構，也就是以當前的業務需求，選出最匹配的架構。另外，架構師還需要根據現狀衡量好需求和資源、效率和安全、時延和吞吐等等之間的關係，做出判斷。

比如對於線上交易系統，可能更重要的是保證它的低時延，因此就可以犧牲一定的吞吐量，而對於離線系統，吞吐量則更重要一些。

2. 預判未來

架構師需要具備一定的未來的預判能力，因為架構的調整週期通常比較長。這也是程式設計師和架構師之間一個很大的區別所在。

程式設計師負責一個專案，在當前的網際網路大背景下，專案的迭代週期非常快，基本以天或周為單位，最多一個月。如果發現不合適的程式碼，需要重構，程式設計師基本也能在幾天或幾周內就能完成重構。

而架構的調整是相對漫長的過程，可能需要數月，甚至要幾年。因此，在設計架構時就需要架構師具備預判意識，對很多不確定的事情做出預判和選擇，諸如未來訪問量會增長到什麼量級，會不會產生新的業務，這些會對系統產生什麼樣新的要求等等。

3. 抽象思維

除了懂得取捨和擁有預判意識，架構師在設計架構時還要掌握抽象的方法，不能鬍子眉毛一把抓，要做好分層和區隔。

因為架構師面對的是一個很龐大的系統，為了避免過早陷入細節，不要去看各個元件的細節，而是把它們的角色定義下來之後，再分塊來思考。而在看每個分塊時，其他分塊都可以視為一個抽象的概念，另外，也需要考慮複用的問題。

舉個例子，我之前在某送餐平臺做線上客服機器人，就運用了分層思想，並且高複用，一個對話機器人可以完成各種各樣的業務需求。這其實是一個非常複雜的系統，裡面有各種各樣的對話機器人的模組，有的特別適合去做檢索式的查詢，還有的適合做任務導向的、產品推薦導向的對話等等。

我們把對話機器人抽象成一個通用的介面，再將它分為一個個小機器人。這樣一來，每個小機器人只需要關注自己的業務模組就行了。然後，我們會在前端再引入一個路由機器人，由路由機器人根據當前對話管理的狀態，來判斷當前的對話應該交給哪個小機器人去完成。這就是典型的分層的思想。

4. 容錯機制

相比程式設計師，架構師面對的環境要惡劣的多，因為系統更復雜了，出錯的機率也增加了，每個節點、每個功能都有可能出錯，所以這就需要架構師為錯誤而設計（Design For Failure），事先提前做好解決方案。

除了應用出錯，還有可能產生資料丟失的情況，這個可以透過備份來預防。

另外，如果出現故障，該怎樣做到快速恢復呢？我們現在普遍的做法是不修只換，因為如果要修復一個異常狀態，可能修復後還會出現連帶問題，而如果能透過技術手段，刪除已出現的故障，換一個全新的系統，就能夠保證它迅速恢復到正常狀態。