一位支付寶架構(gòu)師自述從工程師到架構(gòu)師的成長(zhǎng)之路

架構(gòu)師是一個(gè)沒有被嚴(yán)格定義的角色。

在寫這篇文章之前，我特意把這幾年看過的關(guān)于架構(gòu)和架構(gòu)師的書重新翻了一遍，結(jié)果發(fā)現(xiàn)它們的定義或多或少有一些不一樣，而經(jīng)過了這幾年，一些之前同意的觀點(diǎn)，現(xiàn)在的我也不敢茍同了。另一方面，業(yè)界對(duì)于架構(gòu)師這個(gè)崗位，其實(shí)也沒有統(tǒng)一的角色定位。

在阿里巴巴，前幾年是有專職的“架構(gòu)師”職位的，現(xiàn)在已經(jīng)回歸到“工程師”、“專家”、“研究員”這樣的純技術(shù)職位。而我面試過的人中，也有各種各樣的“架構(gòu)師”，很多小團(tuán)隊(duì)里，項(xiàng)目經(jīng)理就經(jīng)常自認(rèn)為架構(gòu)師。大概架構(gòu)師目前還不至于稱為一個(gè)職業(yè)，更多的是在項(xiàng)目中的一個(gè)角色，而其角色定位也是模糊的，因此，這個(gè)文章里，我主要還是從自己的理解出發(fā)，闡述一下這個(gè)角色的定位和個(gè)人發(fā)展的建議。

1、架構(gòu)師的定義

架構(gòu)師：任何復(fù)雜結(jié)構(gòu)的設(shè)計(jì)人員。

架構(gòu)師的名字來自于建筑業(yè)，Software Architect直譯應(yīng)該叫“軟件建筑師”。從很多方面講，軟件架構(gòu)師的工作跟建筑師很像，為了尋根問祖，曾經(jīng)我也看了不少建筑設(shè)計(jì)的書（推薦一本《建筑的永恒之道》），最后我發(fā)現(xiàn)，兩者一脈相承，現(xiàn)階段分道揚(yáng)鑣，未來也許殊途同歸。

一脈相承——不管是建筑師還是軟件架構(gòu)師，都是為了“大圖”而存在，做好頂層設(shè)計(jì)，充當(dāng)需求方和實(shí)施者的橋梁，是其最重要的兩個(gè)職責(zé)。

分道揚(yáng)鑣——兩者的發(fā)展階段不同所致。建筑業(yè)實(shí)踐綿延數(shù)千年，理論根基有數(shù)百年，真正成為一門學(xué)科也有一百多年，而軟件架構(gòu)真正出現(xiàn)不過二十年。建筑業(yè)已經(jīng)在足夠高的層面上模式化，建筑師能夠真正去“設(shè)計(jì)”，也就是決定“做什么”。而軟件行業(yè)還在高速發(fā)展中，各個(gè)層面的技術(shù)還在百花齊放。技術(shù)的選擇意味著權(quán)衡，因此軟件架構(gòu)師更多還在關(guān)注“怎么做”——這也是建筑師可以稱設(shè)計(jì)師，而軟件架構(gòu)師只能算高階工程師的原因，設(shè)計(jì)師更關(guān)注美感，而美感在軟件架構(gòu)師的考慮優(yōu)先級(jí)里，排不上第一。

殊途同歸——計(jì)算機(jī)發(fā)展的幾十年，也是技術(shù)不斷往上抽象和模式化的幾十年。SOA、IoT、IFTTT等技術(shù)理念已經(jīng)接近于建筑行業(yè)的模塊化級(jí)別，各種“智慧城市”、“生態(tài)城市”已經(jīng)在架構(gòu)層面上考慮“做什么”。假以時(shí)日，架構(gòu)師也許能成為一個(gè)真正的純“設(shè)計(jì)”的職業(yè)，到時(shí)候大學(xué)里也可以開設(shè)“軟件架構(gòu)”的專業(yè)了，那一句“建筑設(shè)計(jì)師在成為建筑設(shè)計(jì)師之前，是不會(huì)成為建筑工人或工程師的“也能在軟件行業(yè)成為現(xiàn)實(shí)。

當(dāng)然，這只是可能的未來，這需要我們這些前輩技術(shù)人員，能夠和建筑行業(yè)的前輩一樣，把技術(shù)規(guī)范化，設(shè)計(jì)模式化，還要有一套關(guān)于架構(gòu)美學(xué)和功能設(shè)計(jì)的完整統(tǒng)一的約束，任重而道遠(yuǎn)。

2、架構(gòu)的職責(zé)

在軟件技術(shù)發(fā)展的前幾十年，是沒有架構(gòu)師這個(gè)稱謂的。所有的人都是程序員，可能有個(gè)帶頭的人，叫主程序員。隨著計(jì)算機(jī)技術(shù)的發(fā)展，軟件覆蓋的領(lǐng)域越來越大，軟件本身也越來越復(fù)雜，現(xiàn)在，動(dòng)輒幾百萬行、幾千萬行代碼的軟件系統(tǒng)已經(jīng)非常普遍。軟件的復(fù)雜化，對(duì)于開發(fā)人員的腦力負(fù)擔(dān)也不斷增大，而人腦所能處理的信息量是有限的，于是，軟件開發(fā)工具、開發(fā)方法也在不斷發(fā)展，從匯編語言到高級(jí)語言，從函數(shù)到框架，從面向過程到面向?qū)ο?，從設(shè)計(jì)模式到架構(gòu)模式……

總體而言，人類在軟件開發(fā)工具的各個(gè)維度上都在做著“封裝”和“抽象”，架構(gòu)設(shè)計(jì)是這種抽象和封裝的最高層次。從架構(gòu)的維度上，已經(jīng)不需要考慮語言、函數(shù)、設(shè)計(jì)模式這一類的抽象，而是站在整體軟件系統(tǒng)的高度上，考慮系統(tǒng)設(shè)計(jì)的技術(shù)合理性，需求實(shí)現(xiàn)的完整性，商業(yè)訴求的匹配度（主要是成本和效率）——這是架構(gòu)的技術(shù)職責(zé)。

另一方面，隨著行業(yè)的發(fā)展，軟件項(xiàng)目的參與角色和人員也越來越多，從起初只有程序員和需求方，發(fā)展到技術(shù)、產(chǎn)品、設(shè)計(jì)、商務(wù)、項(xiàng)目管理多團(tuán)隊(duì)，技術(shù)團(tuán)隊(duì)內(nèi)部的分工也越來越細(xì)化，前端、后端、測(cè)試、運(yùn)維、售前售后技術(shù)、集成技術(shù)等應(yīng)運(yùn)而生。架構(gòu)師是技術(shù)團(tuán)隊(duì)面向產(chǎn)品設(shè)計(jì)等團(tuán)隊(duì)的接口人，承擔(dān)著彌合技術(shù)與非技術(shù)團(tuán)隊(duì)之間知識(shí)和語言體系差異的職責(zé)，同時(shí)作為技術(shù)團(tuán)隊(duì)的帶頭人，要負(fù)責(zé)勾勒藍(lán)圖，明確邊界，讓不同技能的團(tuán)隊(duì)通力協(xié)作，最終完成軟件系統(tǒng)的整體建設(shè)和發(fā)布——這是架構(gòu)的組織職責(zé)。

2.1、架構(gòu)的技術(shù)職責(zé)

首先，架構(gòu)師經(jīng)常被類比于建筑師，但是有兩個(gè)建筑領(lǐng)域的基礎(chǔ)理念，在軟件架構(gòu)領(lǐng)域是不成立的（至少現(xiàn)階段不成立）：

建筑設(shè)計(jì)師在成為建筑設(shè)計(jì)師之前，是不會(huì)成為建筑工人或工程師的?！F(xiàn)階段的軟件架構(gòu)師，一定是從軟件工程師成長(zhǎng)起來的。

建筑學(xué)和工程學(xué)之間的區(qū)別表現(xiàn)在“做什么”和“怎么做”：建筑師決定做什么，工程師想出怎么做。——現(xiàn)階段的軟件架構(gòu)師，除了決定做什么，也要決定關(guān)鍵部分怎么做。

架構(gòu)的技術(shù)職責(zé)分為三大塊：

抽象設(shè)計(jì)；

非功能設(shè)計(jì)；

關(guān)鍵技術(shù)設(shè)計(jì)。

首先是抽象設(shè)計(jì)。架構(gòu)師需要能自由地在不同的抽象層次和視角上分析需求，不同的架構(gòu)層次/視角提供了不同的視圖，這些視圖互相驗(yàn)證，又能構(gòu)成整體的設(shè)計(jì)大圖。架構(gòu)的抽象層次分成兩個(gè)維度：

垂直維度

從上到下，分成企業(yè)架構(gòu)、解決方案架構(gòu)、應(yīng)用架構(gòu)、系統(tǒng)架構(gòu)等，這個(gè)分層的邏輯，是提供不同顆粒度的業(yè)務(wù)建模。CTO關(guān)注企業(yè)架構(gòu)，它提現(xiàn)了一個(gè)企業(yè)整體的IT技術(shù)建設(shè)的戰(zhàn)略選擇，典型的就是集中式和SOA、大型機(jī)和云計(jì)算的選擇等；產(chǎn)品經(jīng)理和運(yùn)維關(guān)注應(yīng)用架構(gòu)，這里映射了產(chǎn)品的業(yè)務(wù)流程和應(yīng)用的整體部署依賴；外部客戶關(guān)注解決方案架構(gòu)，它定義了如何通過產(chǎn)品的整合和協(xié)同，解決特定客戶的特定的技術(shù)方案需求；研發(fā)工程師關(guān)注系統(tǒng)架構(gòu)，這里定義了單個(gè)系統(tǒng)的領(lǐng)域建模和系統(tǒng)框架。

水平維度

具體到對(duì)某一個(gè)業(yè)務(wù)的架構(gòu)設(shè)計(jì)，又可以區(qū)分出業(yè)務(wù)架構(gòu)、數(shù)據(jù)架構(gòu)、技術(shù)架構(gòu)、應(yīng)用架構(gòu)幾個(gè)不同的視角。業(yè)務(wù)架構(gòu)是對(duì)業(yè)務(wù)領(lǐng)域和業(yè)務(wù)流程的分析抽象，需要提煉出業(yè)務(wù)的核心領(lǐng)域模型，業(yè)務(wù)的可變和不變部分，這是架構(gòu)師和產(chǎn)品經(jīng)理協(xié)同完成的；數(shù)據(jù)架構(gòu)基于業(yè)務(wù)架構(gòu)提煉的核心領(lǐng)域模型做數(shù)據(jù)模型和存儲(chǔ)模型的設(shè)計(jì)；技術(shù)架構(gòu)基于業(yè)務(wù)的性能，可用性，安全等非功能性指標(biāo)，確定語言、框架、中間件、部署等技術(shù)選型；應(yīng)用架構(gòu)基于業(yè)務(wù)抽象設(shè)計(jì)應(yīng)用系統(tǒng)的層次結(jié)構(gòu)、系統(tǒng)邊界等。

在這些架構(gòu)劃分中，企業(yè)架構(gòu)匹配商業(yè)模式，業(yè)務(wù)架構(gòu)匹配業(yè)務(wù)模式，其他幾個(gè)架構(gòu)的劃分，更多的是從技術(shù)的不同視角來看，他們提供了從不同的抽象層次，不同的切面對(duì)于功能需求的分析和建模。

同時(shí)需要說明的是，架構(gòu)的抽象是匹配于業(yè)務(wù)的，就像橋梁設(shè)計(jì)師不能直接轉(zhuǎn)做摩天大樓設(shè)計(jì)，架構(gòu)抽象也是區(qū)分領(lǐng)域的，每一個(gè)業(yè)務(wù)領(lǐng)域都有自己的獨(dú)特性，因此在架構(gòu)上也是千人千面的，好的架構(gòu)設(shè)計(jì)也是對(duì)于業(yè)務(wù)抽象得最好的設(shè)計(jì)。

架構(gòu)師的另一個(gè)技術(shù)職責(zé)，是對(duì)非功能需求的分析。這也是“架構(gòu)服務(wù)于功能，高于功能”的含義。這里的非功能性需求包括了軟件系統(tǒng)的可靠性、擴(kuò)展性、可測(cè)性、數(shù)據(jù)一致性、安全和性能等。考慮到成本和運(yùn)行環(huán)境等限制，這些非功能性需求很多時(shí)候是不能同時(shí)滿足的。這個(gè)時(shí)候就需要“權(quán)衡”，空間換時(shí)間的算法層面的權(quán)衡，性能和可測(cè)性、可靠性的權(quán)衡，一些權(quán)衡甚至上升到了學(xué)術(shù)層面，變成無完美架構(gòu)的理論根基（如CAP理論）。

架構(gòu)師的最后一個(gè)技術(shù)職責(zé)是關(guān)鍵技術(shù)設(shè)計(jì)。建筑師不只是做整體外觀設(shè)計(jì)的，建筑師也需要考慮關(guān)鍵部分的細(xì)節(jié)設(shè)計(jì)——曾經(jīng)在巴塞羅那圣家堂，我甚至看到高迪連教堂里一把椅子都留下了詳細(xì)的設(shè)計(jì)圖紙。同理，架構(gòu)師也需要對(duì)可能影響到軟件系統(tǒng)整體質(zhì)量的關(guān)鍵部分，做更細(xì)節(jié)的詳細(xì)設(shè)計(jì)。

2.2、架構(gòu)的組織職責(zé)

架構(gòu)師是企業(yè)的一員，作為“邊界人”，承擔(dān)著在不同角色、團(tuán)隊(duì)之間溝通協(xié)調(diào)的作用。

和業(yè)務(wù)、產(chǎn)品團(tuán)隊(duì)的協(xié)作

軟件系統(tǒng)是解決現(xiàn)實(shí)世界的問題的，任何的軟件系統(tǒng)都是業(yè)務(wù)相關(guān)的，當(dāng)一個(gè)軟件系統(tǒng)的商業(yè)模式確定之后，架構(gòu)師就開始和業(yè)務(wù)、產(chǎn)品團(tuán)隊(duì)緊密合作，確定軟件系統(tǒng)的業(yè)務(wù)架構(gòu)和領(lǐng)域模型。業(yè)務(wù)和領(lǐng)域模型抽象的好壞，決定了軟件產(chǎn)品是一次性的解決方案，還是可以持續(xù)支撐業(yè)務(wù)成長(zhǎng)的真正的產(chǎn)品。

需要說明的是，業(yè)務(wù)、產(chǎn)品方和架構(gòu)師是需求方和實(shí)施方的關(guān)系，所以，雙方之間既是合作的關(guān)系，有時(shí)候也是談判雙方的關(guān)系，特別是對(duì)于外包型的軟件產(chǎn)品而言，這個(gè)時(shí)候，架構(gòu)師又承擔(dān)著在業(yè)務(wù)方和技術(shù)團(tuán)隊(duì)之間找到訴求契合點(diǎn)的重任。

和技術(shù)團(tuán)隊(duì)的協(xié)作

研發(fā)階段，有架構(gòu)師參與的項(xiàng)目，往往牽涉多個(gè)不同方向，不同業(yè)務(wù)領(lǐng)域的研發(fā)團(tuán)隊(duì)。架構(gòu)在其中的作用，是整體大圖的傳導(dǎo)，以及應(yīng)用和團(tuán)隊(duì)研發(fā)邊界的劃分，對(duì)于影響到整體的非功能需求的關(guān)鍵技術(shù)點(diǎn)，架構(gòu)師也要能親力親為完成設(shè)計(jì)。歸根結(jié)底，架構(gòu)師為軟件系統(tǒng)的整體質(zhì)量負(fù)責(zé)，也為研發(fā)團(tuán)隊(duì)的研發(fā)分工負(fù)責(zé)。

部署階段，架構(gòu)師需要和運(yùn)維團(tuán)隊(duì)一起評(píng)估滿足整體非功能需求的前提下，軟件系統(tǒng)部署的硬件成本和部署拓?fù)浣Y(jié)構(gòu)。例如對(duì)于互聯(lián)網(wǎng)應(yīng)用，針對(duì)性能要求，是否需要CDN，帶寬需求；針對(duì)可靠性，是否需要多機(jī)房部署；針對(duì)安全，是否部署相關(guān)的安全軟件。最終的部署策略，仍然是基于成本和需求的一個(gè)權(quán)衡。

技術(shù)團(tuán)隊(duì)是架構(gòu)師的大本營。根據(jù)不同公司的職能定位不同，有的架構(gòu)師立足于技術(shù)團(tuán)隊(duì)，有的游離于技術(shù)團(tuán)隊(duì)。立足技術(shù)團(tuán)隊(duì)使架構(gòu)師能更深入了解團(tuán)隊(duì)所負(fù)責(zé)的產(chǎn)品，因此能對(duì)業(yè)務(wù)做更合理的建模，也有利于架構(gòu)師對(duì)關(guān)鍵技術(shù)方案做針對(duì)性設(shè)計(jì)，但是可能會(huì)限制了架構(gòu)師擁有更加全局的視角。游離于技術(shù)團(tuán)隊(duì)的架構(gòu)師能夠從全局看待軟件設(shè)計(jì)而不受制于屁股，因此更能從客觀合理的角度規(guī)劃整體設(shè)計(jì)，但是由于對(duì)技術(shù)團(tuán)隊(duì)沒有管理職能，對(duì)于方案的落地只能依靠個(gè)人的技術(shù)號(hào)召力，而且，游離意味著疏遠(yuǎn)，如果架構(gòu)師不能自覺地去跟進(jìn)軟件產(chǎn)品的實(shí)際落地，可能慢慢就會(huì)架空，變成PPT架構(gòu)師。

簡(jiǎn)言之，架構(gòu)師既不能完全負(fù)責(zé)某個(gè)技術(shù)團(tuán)隊(duì)，也不能完全游離在技術(shù)團(tuán)隊(duì)之外，這個(gè)，又是一個(gè)職能定位的權(quán)衡了。

同時(shí)，架構(gòu)師和技術(shù)團(tuán)隊(duì)的協(xié)作，還有一個(gè)很重要的組織職能。如前述，架構(gòu)師既決定了整體的架構(gòu)選型，也決定了關(guān)鍵的技術(shù)方案的設(shè)計(jì)，而什么是需要架構(gòu)師親力親為的關(guān)鍵技術(shù)方案，是架構(gòu)師來確定的。因此，這就引申出架構(gòu)師的另一個(gè)重要的組織職能——團(tuán)隊(duì)培養(yǎng)。如果架構(gòu)師完成所有的技術(shù)方案設(shè)計(jì)，研發(fā)團(tuán)隊(duì)只管寫代碼，架構(gòu)師會(huì)累死，研發(fā)團(tuán)隊(duì)也不會(huì)成長(zhǎng)，這就要求架構(gòu)師給予研發(fā)團(tuán)隊(duì)足夠的成長(zhǎng)空間和信任，并因此承擔(dān)一定的風(fēng)險(xiǎn)和責(zé)任，這是這個(gè)角色必須承擔(dān)的。

和其他角色的協(xié)作

除了產(chǎn)品和技術(shù)團(tuán)隊(duì)，架構(gòu)師需要協(xié)作的還有項(xiàng)目經(jīng)理，外部客戶，甚至是公司財(cái)務(wù)……一句話，架構(gòu)師作為技術(shù)方案的總負(fù)責(zé)人，對(duì)接所有對(duì)技術(shù)方案有關(guān)聯(lián)關(guān)系的合作方。

如何溝通

協(xié)作就需要溝通，架構(gòu)需要掌握多門溝通語言，而最好的語言是圖表。對(duì)于產(chǎn)品來說，架構(gòu)師溝通的工具是業(yè)務(wù)架構(gòu)，用例和領(lǐng)域模型；對(duì)于研發(fā)團(tuán)隊(duì)來說，架構(gòu)師溝通的工具是應(yīng)用架構(gòu)，組件和時(shí)序圖；對(duì)于運(yùn)維團(tuán)隊(duì)來說，溝通的語言又成了部署架構(gòu)。圖表的作用是維護(hù)共同的語言，同時(shí)也是讓設(shè)計(jì)文檔化以便于傳承。

3、架構(gòu)師的成長(zhǎng)

上面講了架構(gòu)師的職責(zé)，職責(zé)既是能力的要求?？梢钥吹?，架構(gòu)師既是一個(gè)全方位的技術(shù)專家，也是一個(gè)溝通協(xié)作的專家。因此，總結(jié)一下，架構(gòu)師的成長(zhǎng)，也是兩條線：

技術(shù)上

架構(gòu)師的首要工作是抽象建模，而首要的首要是要了解自己所處的業(yè)務(wù)領(lǐng)域，只有對(duì)業(yè)務(wù)足夠了解，才能更好地抽象和建模，也更能沉淀通用的設(shè)計(jì)方法論。幾年前，我曾經(jīng)看過我司首席架構(gòu)師的書單，其中有銀行卡組織的介紹的，有零售銀行的業(yè)務(wù)分析的，而那個(gè)時(shí)候，我司還只是金融業(yè)邊上的支付公司而已。

另一方面，架構(gòu)師需要在業(yè)務(wù)領(lǐng)域所涉及到的技術(shù)領(lǐng)域中，都要了解甚至精通，譬如對(duì)于互聯(lián)網(wǎng)行業(yè)的架構(gòu)師，小到語言、算法、數(shù)據(jù)庫，大到網(wǎng)絡(luò)協(xié)議，分布式系統(tǒng)，服務(wù)器，中間件，IDC等等都需要涉獵。一句話，架構(gòu)師是技術(shù)團(tuán)隊(duì)的對(duì)外接口人，也應(yīng)該是外部團(tuán)隊(duì)技術(shù)問題的終結(jié)者。廣度之外也要深度，對(duì)于關(guān)鍵的技術(shù)模塊的設(shè)計(jì)，架構(gòu)師需要有技術(shù)的權(quán)威性。

組織和個(gè)人成長(zhǎng)上

架構(gòu)師要作為業(yè)務(wù)和技術(shù)的橋梁，因此需要精通業(yè)務(wù)和技術(shù)的語言，要鍛煉溝通能力，不只是口頭的溝通能力，也包括用標(biāo)準(zhǔn)化的圖表表達(dá)設(shè)計(jì)思路的能力。

架構(gòu)師需要一種“中庸之道”。不管是技術(shù)的選型，團(tuán)隊(duì)的協(xié)作、培養(yǎng)和分工，商業(yè)訴求和成本、產(chǎn)品需求和技術(shù)訴求的匹配，很多時(shí)候都是一種權(quán)衡?？梢哉f，架構(gòu)的工作主題就是權(quán)衡，這可能也是工程師成長(zhǎng)為架構(gòu)師最大的挑戰(zhàn)。工程師經(jīng)常是完美主義的，程序也總是精準(zhǔn)精確的，但是架構(gòu)師要習(xí)慣于不完美和一定條件下的不精確。

4、補(bǔ)充說明

上面寫了這么多，其實(shí)針對(duì)的是大型的，有明確需求的，多團(tuán)隊(duì)參與的項(xiàng)目或者產(chǎn)品的架構(gòu)師。現(xiàn)實(shí)世界中并不都是這樣的項(xiàng)目，所以也并不都是這樣的角色分工。

另外，架構(gòu)師也不是技術(shù)人員唯一的方向，甚至不是大多數(shù)技術(shù)人員的職業(yè)方向。在技術(shù)上，架構(gòu)師是廣度優(yōu)先兼具深度，同時(shí)在技術(shù)之外附帶了許多的業(yè)務(wù)性和組織職能，而很多的技術(shù)人員會(huì)更傾向于在技術(shù)的深度上不斷挖掘，也不愿意投入太多的精力在業(yè)務(wù)和溝通上，這樣的技術(shù)人員其實(shí)更適合的是技術(shù)專家的路線。技術(shù)專家研究的是純粹的技術(shù)，這里面可能有算法、有編程語言、有運(yùn)行容器（虛擬機(jī)、操作系統(tǒng)、應(yīng)用服務(wù)器、中間件）、有通訊機(jī)制，這些都有足夠的源源不斷的問題等著技術(shù)人員去解決，而他們解決的問題，也成為軟件技術(shù)不斷向上抽象，不斷模式化的基礎(chǔ)，所以，技術(shù)專家的路線也是同樣重要的。