什麼是架構師？

隨便打開某招聘網站：系統架構師、搜索架構師、前端架構師、iOS/Android架構師、平臺架構師、（大）數據架構師、JAVA/PHP/.NET架構師、高級架構師、資深架構師、BI架構師，這些是大家常見的，君不見還有後臺架構師、MIS/ERP/OA系統架構師、金融系統架構師、搜索架構師、總線架構師、運維架構師，安全架構師......林林總總，不一而足。

僅僅是上面這些崗位名稱，就能看到架構師崗位的差異之大，方向不同、技術棧不同、行業不同，即便同一個崗位，水平差距也是天壤之別，如果僅以架構師一個稱謂來描述，顯然是不合適的，所以我覺得今天在行業內這個稱謂還有點”虛”。

為什麼是架構師？

首先我認為是因為程序員需要。小的時候，記得當地的所有理髮店，無論哪個理髮師來剪頭髮，都是一個價格，雖然也是從1毛漲到了5塊，但價格都是一樣，但選擇去哪家店或哪個理髮師的權利在消費者身上。長大工作之後，住地樓下有一家理髮店，為了貪圖方便，我經常去那裡剪，清楚的記得其中一個名叫王子的小夥子在給我理髮，第一次去剪的時候是20元，然後每隔幾個月就會漲一次價，從最初的20元漲到38元、58元、68元、88元、98元，最後到了108元。

每次付款的時候，熱情的小夥子都特別不好意思地對我說：“哥，我又升職了，價格漲了！”， 人還是那個人，理髮水平對於男性而言大體也看不出多大差異，但頭銜從理髮師變成髮型設計師、高級髮型設計師、設計總監、高級設計總監、首席設計師、沙宣首席設計師，當價格一路漲到和天罡北斗一個級別的時候，我終於忍無可忍的換到離住地2公里多遠的小閆理髮店，10元搞定。 PS：想想當時真的是懶啊，可能跟當時頭髮的髮量也有關係。

這樣舉例似乎有點貶低程序員的意思，但是大家不要忘了看上面價格的走勢，漲到98元的時候我還堅持在那裡剪頭髮，這說明我也已經是走在初級程序員、中級程序員、高級程序員、架構師/開發經理、總監的路上了。王子同學在那幾年的時間，除了價格提升了，但技能方面似乎沒有特別大的進步，但這不能說明那幾年我的能力沒有進步，確確實實是積累了一些經驗，也有了點提升，自然薪水也漲了上去。

大部分職業都是需要有成長體系，才能讓人有奮發向上的追求，而架構師就是程序員這個群體成長道路上往往會出現的一個重要節點，他描述了一個程序員在某個領域、行業在知識、技能的廣度或深度已經積累到一定程度，需要社會對這個群體有一個較清晰的定位和價值判定，是開發領域社會分工精細化的一個產物，

因為項目開發需要。一個開發項目從立項到結束需要做許多事情，需求分析、梳理抽象、系統/模塊劃分、服務化、數據結構設計、前後端架構、技術架構、運維、監控等等，它涉及抽象、架構、設計、評估、攻關、調優、團隊培訓等等，他需要有一個角色負責整體，很顯然項目經理、產品經理、BA做不好這樣的事情，往往需要由團隊的主要負責人來做這樣的事情，我猜即便在開發比較精細化分工的今天，大部分的創業公司找的應該就是這類人：他們具備CTO、VP、TD（簡稱CVT）中的某一個頭銜，這些人大部分的時間其實都花在這些事情上面了。

但是隨著業務的發展，CVT們就會發現自已變成了瓶頸，除了前面提的這些技術工作外，還要求CVT們要花費大量時間不停學習新知識，實踐，總結，還需要和公司業務部門討論需求，和外部機構對接，組建團隊，項目管理等，於是就需要有分工，要有項目經理、HRBP、BA/SA、架構師等來支持其工作，需要有更專注、專業的人員來幫助，於是就出現了架構師這樣的崗位。

所以，這樣的需要和分工就決定了在每個領域、行業對知識、技能、經驗的要求層次各有不同，都被統稱為架構師，因此就會出現上述所講的“虛”的感覺。很多時候大家在討論架構師的時候會出現牛頭不對馬嘴，甚至出現上下左右互相鄙視的場景。當然，說到這裡，很多架構師可能會嗤之以鼻，沒有負責過一個開源項目、做過分佈式框架、經歷過上億級併發的系統架構師，怎麼能稱之為架構師呢，我想說的是基本上你是對的，但如果你還有3分鐘休息時間，不妨再往下看看。

領域專家（技術領域、行業領域）

承上所述，如果限定在一個特定場景，比如億級以上併發的分佈式服務系統中從事架構的崗位，稱之為架構師，那麼大家可能就會覺得比較容易接受了。但是我更願意將參與構架系統的開發人員，稱之為領域專家，它裡面其實有許多技術棧不是一個人就能夠完成，比如在硬件、數據存儲、網絡層、操作系統、服務框架、安全、算法、大數據等都有相應領域專家參與完成，並不只是在最上層搭框架畫藍圖才是架構師，每個領域都需要有專業的人員負責架構、研究、開發。

這些領域還能再細分，對特定領域的存儲系統、特定的網絡協議、特定領域的業務場景等有較深研究，這並不是說一個領域專家對其它方面就不熟悉了，而是說他在某些領域特別有研究，遠遠超出行業平均水平，踩過許多個坑，有足夠經驗，同時在技術領域的知識廣度上比較好，那麼這樣的開發人員常常會被定義成架構師，但我還是更願意稱其為領域專家。這也是計算機和互聯網發展到今天，必然會出現的一種情況，回顧整個IT行業發展軌跡，許多崗位都是這麼出現的，如Web前端架構師、產品經理就是典型例子。

僅僅把領域專家限定在技術層面，對於許多開發人員來說大致比較容易接受，但如果把它擴展到業務領域（有些時候稱應用架構師？），就很有爭議了，甚至我見過有一部分架構師是一直鄙視並唾棄這種所謂業務架構師：業務架構有什麼好談？只有技術做不好的人，才會談業務架構！我們還是來談談拜占庭將軍、區塊鏈、機器學習、大數據…

我不完全反對這種觀點，首先這種情況的出現，是因為很多開發人員覺得業務架構不如技術架構有深度，如果讓一個分佈式領域的專家來談談分佈式服務框架的治理、RPC協議、長短連接、路由設計、容錯、流控、灰度、降級、一致性、可靠性之類的內容，他可能會滔滔不絕講上幾個小時，聞者如痴似醉。

但如果你讓一個電信領域的技術專家來談業務架構，我相信許多開發人員會昏昏欲睡，一個是有行業特性因素，再一個就是沒有一個可量化標準來評判好壞，於是就導致這樣的局面。

但是在非開發人員的群體眼裡，業務架構又是如此重要，重要到他們根本不關心你的技術架構是什麼樣，除了系統不要出故障、不能太慢之外，他們關心的是需要有什麼樣的系統/模塊/服務來更有效率支撐業務？系統/模塊/服務流程是否順暢？能否適應業務的快速變化？新的活動/規則出現是否儘量少開發，甚至不用開發？

諸如此類，大部分都是需要有業務領域的專家或者架構師來完成，但在實際工作中我見到過不少比較精通某些技術領域的架構師，比如網絡、數據庫、分佈式服務框架、安全、算法甚至工作流引擎等，但開發人員中具備較高視野，能夠快速梳理、分解、抽象業務需求，並真正能實踐落地的卻是極為稀少，而這個領域也是行業內一直被忽視的，因為沒有評判標準，不像技術框架那樣可以被量化（可支持多少QPS、多少吞吐量、併發處理多少訂單等），大部分時候技術都是被業務在拖著走。於是，技術永遠是瓶頸！

當然上面我是舉了一種比較極端情況，更多時候架構師們都同意架構必須瞭解業務，但開發人員內心真正把這個事情放在重要地位的其實並不多，工程技術是願意花時間學習，並進行實踐，就能快速進步的，但業務抽象卻需要多年一線經驗積累和總結，需要時間沉澱。

給一個開發人員時間讓他研究一個流行的新技術或是重寫一個已經不太適合當前業務的技術框架，他肯定如餓了幾天的飢漢見到一塊大肥肉，摩拳擦掌，躍躍欲試，十八般武藝全上了；但如果你讓他完成某個業務需求的抽象分解、流程梳理，並實現開發，我相信他也能做，但願意花很大精力，認真去做的、並且做好的其實不多，因為結果不好評估，成就感不強，所以大部分時候做這樣的事情會感覺比較痛苦。對比一下兩種場景的做事心態，結果不言而喻。

所以，我認為大部分時候架構師用領域專家來描述可能更為準確一些，當然，這不僅限於精通技術領域的專業人士。

架構師的能力

當然，無論是架構師或是領域專家，我認為大體上它定位的是一個開發人員在某個領域、行業在知識、技能的廣度或深度已經積累到一定程度，那麼這樣的人一般都是什麼樣的人呢？

基礎：邏輯、抽象、想象

優秀的邏輯思維能力是成為架構師的基本要求之一，這對於大部分開發人員而言一般問題都不大，都是從小受過這方面的大量訓練，又選擇了程序員這個職業，總體都是不錯的。但出色的抽象能力，卻決定許多開發人員未來的上升空間，無論他是從事技術或是業務領域的系統架構，都是需要非常出色的抽象能力，能夠把不同的事物從不同維度分析，抽象成合適的模型，並能真正在實踐中落地，這是一個非常重要能力。除此之外，我認為還需要一點想象力，也可以認為是對業務的發展有一些前瞻性，這個能力更加不好評估，且尺度的把握也比較難，但以個人的經驗來看，這是一個非常重要能力，否則技術被業務拖著跑的情況會更加嚴重，開發永遠是瓶頸，越往上走對其要求就越高。

這三個能力，我認為是一個優秀的開發人員要成長為架構師、CVT都要具備的基本素質，剩下的就是要有好的心態和大量實戰了。

心態：空杯、好奇、實踐

IT行業是我認知裡產生新名詞最多的行業之一，一個簡單的AJAX技術都能被行業媒體熱炒兩三年（當然也因為它才真正衍生出今天的前後端分離的開發模式），每年都有許多新名詞，新技術，新的開源框架出現，一種開源框架可以在一夜之間全行業都使用，這即說明行業的浮躁，但也說明行業更新變化之快，只要你不跟上學習，往往就會被拖下很遠一段距離，當然很多原理和方法都是通用的，但有許多很好的實踐在每個階段都不斷在行業內傳播，也許已經是人所皆知的東西，但是隻要你不跟上就很容易被拋棄。

舉個自身特別挫的例子，讓大家來鄙視一下：2007年開始大概有三年多的時間，我負責一個移動應用部門的產品及研發工作，大部分時間都在忙著項目的事情（當時的手機大部分還是功能機的時代）， 當有一天我和行業內朋友交流客戶端集群方案時，連一致性HASH這種半小時就能搞懂的HASH算法，我居然完全沒聽過，被鄙視是活在古代，知識結構陳舊。很顯然我已經被拉下很遠了，回家一查居然是1997年就出來的論文，只是一開始在P2P領域應用比較多，傳播較少。

所以，我想說的是在工程領域，一個優秀的開發人員，不能抱殘守缺，只有謙遜的，保持空杯的心態，不斷的向別人學習，才能前進。無論今天你身處什麼位置，一定有許多知識片段是你所不瞭解的，只有在某些特定的領域可能你是專家， 理論上用C語言、最基本的文件系統或者數據庫可以解決大部分的系統問題。但為什麼每年會有許多新的語言、框架、數據庫、協議、原則、模式等出現，只有保持好奇心，多問為什麼，為什麼會有這樣的東西出現？它解決什麼問題？怎麼解決？它的缺點是什麼？它帶來什麼新的問題？追根溯源，深入理解，方能有所吸收和成長。

基本素質好，心態也對，剩下的就是紮紮實實的大量實踐，在工程領域沒有什麼比大量實戰更能提高開發人員的水平了，哪怕心態再好，再聰明，如果缺乏多年大量一線的實戰經驗，還是如空中樓閣，談起理論技術頭頭是道，但落地上就容易出問題。許多剛工作幾年，本身素質也非常好的程序員就栽在這上面，因為確實素質不錯，所以很快就轉到了管理崗位，朝夕論道，也逐漸遠離代碼，走到一定階段，還是容易被人詬病，實在是很可惜。空杯、好奇、實踐，這樣的心態應該是成為一個優秀工程人員所要具備的了。

技術的架構

技術的架構領域比較多，無論是較宏觀的整體系統架構，還是再細分到某個領域，比如硬件、分佈式服務框架、存儲、監控平臺、甚至算法、引擎等，各類分享的文章也比較多。架構師不是科學家，更多工作只是在工程領域的實踐經驗的積累和總結，一個優秀的開發人員，有好的素質，好的心態，再碰到一些好的項目，積累了大量的實戰經驗，就有機會成為一名不錯的架構師。

業務的架構

對業務進行架構雖然比較難以準確描述，因為它沒有標準評判，邊界並不足夠清晰。但要成為這類型的專家，豐富的系統實戰經驗必不可少，踩過許多坑，經歷許多不同的業務場景，讓架構人員擁有足夠廣的視野，許多事物具備共通性，往往是可以相互借鑑和參考，也便於分析梳理業務需求，抽象業務場景，框定系統/模塊/服務的邊界。除此之外，還要有深厚的技術廣度和深度，脫離技術討論業務架構，就是紙上談兵，落不了地。

組織的架構

最後聊一下關於技術的組織架構，這並不是討論架構師崗位的範疇，但架構師和CVT之間就是一線之隔，隨時可以轉身，所以順便提一下了。許多時候，CVT往往都是架構師轉過來，因為帶起技術團隊比較輕鬆，和開發人員討論問題時不會被翻白眼：）。但隨著業務發展，除了交流能力、協調等能力之外，組織的架構能力尤其重要，組織的劃分會決定整個團隊的效率，如什麼時候組建架構師團隊？架構師跟項目還是獨立成部？不同職能是否垂直管理還是按功能團隊組織？是否需要成立技術支持部門來應對干擾和收集問題？是否需要PMO？業務高速發展，大量進人時，組織架構上怎麼快速消化？跟技術架構一樣，沒有標準範式，只有根據不同業務場景而變，在不同公司、行業、特別是不同的發展階段，對組織方式的要求也不一樣，有些甚至是反模式的，但是如果有效，也是需要階段性執行。

後序

以上內容僅出筆者個人的經歷體會而成，偏頗極大，如果您不認同部分或全部看法，全當是笑話。。

閱讀更多 程序猿的內心獨白 的文章

關鍵字: 讀讀 架構師 設計