Scalers點評：成長會的小伙伴有從事架構師崗位的，最近問了我一些關于架構師成長方面的問題昼牛。專業(yè)的事情請專業(yè)的人來辦文狱，我想到有一個多年的好朋友Tomly在支付寶做架構師，有五年以上的從業(yè)經驗壮韭。于是請他出山寫了一篇從工程師到架構師的成長之路。文章很長纹因，但是內容卻很扎實喷屋，符合我對Tomly一直以來的認知。文章中給我很多啟發(fā)的地方瞭恰，其中一點就是把架構師和建筑師做了一個類比屯曹，一下就連通了IT和建筑兩個行業(yè)。Tomly是一位很有想法的朋友惊畏，每次和他交流恶耽，或者看到他的作品，我就會感到颜启，自己書讀的太少偷俭。所以這是一篇思想密度很高的文章，而且很長缰盏，但是對于IT從業(yè)者來說涌萤，卻很有價值。

0乳规、前言

架構師是一個沒有被嚴格定義的角色形葬。

在寫這篇文章之前，我特意把這幾年看過的關于架構和架構師的書重新翻了一遍暮的，結果發(fā)現(xiàn)它們的定義或多或少有一些不一樣笙以，而經過了這幾年，一些之前同意的觀點冻辩，現(xiàn)在的我也不敢茍同了猖腕。另一方面，業(yè)界對于架構師這個崗位恨闪，其實也沒有統(tǒng)一的角色定位倘感。在阿里巴巴，前幾年是有專職的“架構師”職位的咙咽，現(xiàn)在已經回歸到“工程師”老玛、“專家”、“研究員”這樣的純技術職位。而我面試過的人中蜡豹，也有各種各樣的“架構師”麸粮，很多小團隊里，項目經理就經常自認為架構師镜廉。大概架構師目前還不至于稱為一個職業(yè)弄诲，更多的是在項目中的一個角色，而其角色定位也是模糊的娇唯，因此齐遵，這個文章里，我主要還是從自己的理解出發(fā)塔插，闡述一下這個角色的定位和個人發(fā)展的建議梗摇。

1、架構師的定義

架構師：任何復雜結構的設計人員佑淀。

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

一脈相承——不管是建筑師還是軟件架構師亮蒋，都是為了“大圖”而存在扣典，做好頂層設計，充當需求方和實施者的橋梁慎玖，是其最重要的兩個職責贮尖。

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

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

當然，這只是可能的未來茵烈，這需要我們這些前輩技術人員百匆，能夠和建筑行業(yè)的前輩一樣，把技術規(guī)范化呜投，設計模式化加匈，還要有一套關于架構美學和功能設計的完整統(tǒng)一的約束，任重而道遠仑荐。

2雕拼、架構的職責

在軟件技術發(fā)展的前幾十年，是沒有架構師這個稱謂的粘招。所有的人都是程序員啥寇，可能有個帶頭的人，叫主程序員男图。隨著計算機技術的發(fā)展示姿，軟件覆蓋的領域越來越大，軟件本身也越來越復雜逊笆，現(xiàn)在栈戳，動輒幾百萬行、幾千萬行代碼的軟件系統(tǒng)已經非常普遍难裆。軟件的復雜化子檀，對于開發(fā)人員的腦力負擔也不斷增大镊掖，而人腦所能處理的信息量是有限的，于是褂痰，軟件開發(fā)工具亩进、開發(fā)方法也在不斷發(fā)展，從匯編語言到高級語言缩歪，從函數(shù)到框架归薛，從面向過程到面向對象，從設計模式到架構模式……

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

另一方面，隨著行業(yè)的發(fā)展氯葬，軟件項目的參與角色和人員也越來越多议纯，從起初只有程序員和需求方，發(fā)展到技術溢谤、產品、設計憨攒、商務世杀、項目管理多團隊，技術團隊內部的分工也越來越細化肝集，前端瞻坝、后端、測試杏瞻、運維所刀、售前售后技術、集成技術等應運而生捞挥。架構師是技術團隊面向產品設計等團隊的接口人浮创，承擔著彌合技術與非技術團隊之間知識和語言體系差異的職責，同時作為技術團隊的帶頭人砌函，要負責勾勒藍圖斩披，明確邊界溜族，讓不同技能的團隊通力協(xié)作，最終完成軟件系統(tǒng)的整體建設和發(fā)布——這是架構的組織職責垦沉。

2.1煌抒、架構的技術職責

首先，架構師經常被類比于建筑師厕倍，但是有兩個建筑領域的基礎理念寡壮，在軟件架構領域是不成立的（至少現(xiàn)階段不成立）：

建筑設計師在成為建筑設計師之前，是不會成為建筑工人或工程師的讹弯】黾龋——現(xiàn)階段的軟件架構師，一定是從軟件工程師成長起來的闸婴。

建筑學和工程學之間的區(qū)別表現(xiàn)在“做什么”和“怎么做”：建筑師決定做什么坏挠，工程師想出怎么做⌒罢В——現(xiàn)階段的軟件架構師降狠，除了決定做什么，也要決定關鍵部分怎么做庇楞。

架構的技術職責分為三大塊：

抽象設計榜配；

非功能設計；

關鍵技術設計吕晌。

首先是抽象設計蛋褥。架構師需要能自由地在不同的抽象層次和視角上分析需求，不同的架構層次/視角提供了不同的視圖睛驳，這些視圖互相驗證烙心，又能構成整體的設計大圖。架構的抽象層次分成兩個維度：

垂直維度

從上到下乏沸，分成企業(yè)架構淫茵、解決方案架構、應用架構蹬跃、系統(tǒng)架構等匙瘪，這個分層的邏輯，是提供不同顆粒度的業(yè)務建模蝶缀。CTO關注企業(yè)架構丹喻，它提現(xiàn)了一個企業(yè)整體的IT技術建設的戰(zhàn)略選擇，典型的就是集中式和SOA翁都、大型機和云計算的選擇等碍论；產品經理和運維關注應用架構，這里映射了產品的業(yè)務流程和應用的整體部署依賴荐吵；外部客戶關注解決方案架構骑冗，它定義了如何通過產品的整合和協(xié)同赊瞬，解決特定客戶的特定的技術方案需求；研發(fā)工程師關注系統(tǒng)架構贼涩，這里定義了單個系統(tǒng)的領域建模和系統(tǒng)框架巧涧。

水平維度

具體到對某一個業(yè)務的架構設計，又可以區(qū)分出業(yè)務架構遥倦、數(shù)據(jù)架構谤绳、技術架構、應用架構幾個不同的視角袒哥。業(yè)務架構是對業(yè)務領域和業(yè)務流程的分析抽象缩筛，需要提煉出業(yè)務的核心領域模型，業(yè)務的可變和不變部分堡称，這是架構師和產品經理協(xié)同完成的瞎抛；數(shù)據(jù)架構基于業(yè)務架構提煉的核心領域模型做數(shù)據(jù)模型和存儲模型的設計；技術架構基于業(yè)務的性能却紧，可用性桐臊，安全等非功能性指標，確定語言晓殊、框架断凶、中間件、部署等技術選型巫俺；應用架構基于業(yè)務抽象設計應用系統(tǒng)的層次結構认烁、系統(tǒng)邊界等。

在這些架構劃分中介汹，企業(yè)架構匹配商業(yè)模式却嗡，業(yè)務架構匹配業(yè)務模式，其他幾個架構的劃分嘹承，更多的是從技術的不同視角來看稽穆，他們提供了從不同的抽象層次，不同的切面對于功能需求的分析和建模赶撰。

同時需要說明的是，架構的抽象是匹配于業(yè)務的柱彻，就像橋梁設計師不能直接轉做摩天大樓設計豪娜，架構抽象也是區(qū)分領域的，每一個業(yè)務領域都有自己的獨特性哟楷，因此在架構上也是千人千面的瘤载，好的架構設計也是對于業(yè)務抽象得最好的設計。

架構師的另一個技術職責卖擅，是對非功能需求的分析鸣奔。這也是“架構服務于功能墨技，高于功能”的含義。這里的非功能性需求包括了軟件系統(tǒng)的可靠性挎狸、擴展性扣汪、可測性、數(shù)據(jù)一致性锨匆、安全和性能等崭别。考慮到成本和運行環(huán)境等限制恐锣，這些非功能性需求很多時候是不能同時滿足的茅主。這個時候就需要“權衡”，空間換時間的算法層面的權衡土榴，性能和可測性诀姚、可靠性的權衡，一些權衡甚至上升到了學術層面玷禽，變成無完美架構的理論根基（如CAP理論）赫段。

架構師的最后一個技術職責是關鍵技術設計。建筑師不只是做整體外觀設計的论衍，建筑師也需要考慮關鍵部分的細節(jié)設計——曾經在巴塞羅那圣家堂瑞佩，我甚至看到高迪連教堂里一把椅子都留下了詳細的設計圖紙。同理坯台，架構師也需要對可能影響到軟件系統(tǒng)整體質量的關鍵部分炬丸，做更細節(jié)的詳細設計。

2.2蜒蕾、架構的組織職責

架構師是企業(yè)的一員稠炬，作為“邊界人”，承擔著在不同角色咪啡、團隊之間溝通協(xié)調的作用首启。

和業(yè)務、產品團隊的協(xié)作

軟件系統(tǒng)是解決現(xiàn)實世界的問題的撤摸，任何的軟件系統(tǒng)都是業(yè)務相關的毅桃，當一個軟件系統(tǒng)的商業(yè)模式確定之后，架構師就開始和業(yè)務准夷、產品團隊緊密合作钥飞，確定軟件系統(tǒng)的業(yè)務架構和領域模型。業(yè)務和領域模型抽象的好壞衫嵌，決定了軟件產品是一次性的解決方案读宙，還是可以持續(xù)支撐業(yè)務成長的真正的產品。

需要說明的是楔绞，業(yè)務结闸、產品方和架構師是需求方和實施方的關系唇兑，所以，雙方之間既是合作的關系桦锄，有時候也是談判雙方的關系扎附，特別是對于外包型的軟件產品而言，這個時候察纯，架構師又承擔著在業(yè)務方和技術團隊之間找到訴求契合點的重任帕棉。

和技術團隊的協(xié)作

研發(fā)階段，有架構師參與的項目饼记，往往牽涉多個不同方向香伴，不同業(yè)務領域的研發(fā)團隊。架構在其中的作用具则，是整體大圖的傳導即纲，以及應用和團隊研發(fā)邊界的劃分，對于影響到整體的非功能需求的關鍵技術點博肋，架構師也要能親力親為完成設計低斋。歸根結底，架構師為軟件系統(tǒng)的整體質量負責匪凡，也為研發(fā)團隊的研發(fā)分工負責膊畴。

部署階段，架構師需要和運維團隊一起評估滿足整體非功能需求的前提下病游，軟件系統(tǒng)部署的硬件成本和部署拓撲結構唇跨。例如對于互聯(lián)網(wǎng)應用，針對性能要求衬衬，是否需要CDN买猖，帶寬需求；針對可靠性滋尉，是否需要多機房部署玉控；針對安全，是否部署相關的安全軟件狮惜。最終的部署策略高诺，仍然是基于成本和需求的一個權衡。

技術團隊是架構師的大本營碾篡。根據(jù)不同公司的職能定位不同懒叛，有的架構師立足于技術團隊，有的游離于技術團隊耽梅。立足技術團隊使架構師能更深入了解團隊所負責的產品，因此能對業(yè)務做更合理的建模胖烛，也有利于架構師對關鍵技術方案做針對性設計眼姐，但是可能會限制了架構師擁有更加全局的視角诅迷。游離于技術團隊的架構師能夠從全局看待軟件設計而不受制于屁股，因此更能從客觀合理的角度規(guī)劃整體設計众旗，但是由于對技術團隊沒有管理職能罢杉，對于方案的落地只能依靠個人的技術號召力，而且贡歧，游離意味著疏遠滩租，如果架構師不能自覺地去跟進軟件產品的實際落地，可能慢慢就會架空利朵，變成PPT架構師律想。

簡言之，架構師既不能完全負責某個技術團隊绍弟，也不能完全游離在技術團隊之外技即，這個，又是一個職能定位的權衡了樟遣。

同時而叼，架構師和技術團隊的協(xié)作，還有一個很重要的組織職能豹悬。如前述葵陵，架構師既決定了整體的架構選型，也決定了關鍵的技術方案的設計瞻佛，而什么是需要架構師親力親為的關鍵技術方案脱篙，是架構師來確定的。因此涤久，這就引申出架構師的另一個重要的組織職能——團隊培養(yǎng)涡尘。如果架構師完成所有的技術方案設計，研發(fā)團隊只管寫代碼响迂，架構師會累死考抄，研發(fā)團隊也不會成長，這就要求架構師給予研發(fā)團隊足夠的成長空間和信任蔗彤，并因此承擔一定的風險和責任川梅，這是這個角色必須承擔的。

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

除了產品和技術團隊然遏，架構師需要協(xié)作的還有項目經理贫途，外部客戶，甚至是公司財務……一句話待侵，架構師作為技術方案的總負責人丢早，對接所有對技術方案有關聯(lián)關系的合作方。

如何溝通

協(xié)作就需要溝通，架構需要掌握多門溝通語言怨酝，而最好的語言是圖表傀缩。對于產品來說，架構師溝通的工具是業(yè)務架構农猬，用例和領域模型赡艰；對于研發(fā)團隊來說，架構師溝通的工具是應用架構斤葱，組件和時序圖慷垮；對于運維團隊來說，溝通的語言又成了部署架構揍堕。圖表的作用是維護共同的語言料身，同時也是讓設計文檔化以便于傳承。

3鹤啡、架構師的成長

上面講了架構師的職責惯驼，職責既是能力的要求〉莨澹可以看到祟牲，架構師既是一個全方位的技術專家，也是一個溝通協(xié)作的專家抖部。因此说贝，總結一下，架構師的成長慎颗，也是兩條線：

技術上

架構師的首要工作是抽象建模乡恕，而首要的首要是要了解自己所處的業(yè)務領域，只有對業(yè)務足夠了解俯萎，才能更好地抽象和建模傲宜，也更能沉淀通用的設計方法論。幾年前夫啊，我曾經看過我司首席架構師的書單函卒，其中有銀行卡組織的介紹的，有零售銀行的業(yè)務分析的撇眯，而那個時候报嵌，我司還只是金融業(yè)邊上的支付公司而已。

另一方面熊榛，架構師需要在業(yè)務領域所涉及到的技術領域中锚国，都要了解甚至精通，譬如對于互聯(lián)網(wǎng)行業(yè)的架構師玄坦，小到語言血筑、算法、數(shù)據(jù)庫，大到網(wǎng)絡協(xié)議豺总，分布式系統(tǒng)梆砸，服務器，中間件园欣，IDC等等都需要涉獵。一句話休蟹，架構師是技術團隊的對外接口人沸枯，也應該是外部團隊技術問題的終結者。廣度之外也要深度赂弓，對于關鍵的技術模塊的設計绑榴，架構師需要有技術的權威性。

組織和個人成長上

架構師要作為業(yè)務和技術的橋梁盈魁，因此需要精通業(yè)務和技術的語言翔怎，要鍛煉溝通能力，不只是口頭的溝通能力杨耙，也包括用標準化的圖表表達設計思路的能力赤套。

架構師需要一種“中庸之道”。不管是技術的選型珊膜，團隊的協(xié)作、培養(yǎng)和分工，商業(yè)訴求和成本喷市、產品需求和技術訴求的匹配骡尽，很多時候都是一種權衡≈竦唬可以說谈跛，架構的工作主題就是權衡，這可能也是工程師成長為架構師最大的挑戰(zhàn)塑陵。工程師經常是完美主義的感憾，程序也總是精準精確的，但是架構師要習慣于不完美和一定條件下的不精確猿妈。

4吹菱、補充說明

上面寫了這么多，其實針對的是大型的彭则，有明確需求的鳍刷，多團隊參與的項目或者產品的架構師。現(xiàn)實世界中并不都是這樣的項目俯抖，所以也并不都是這樣的角色分工输瓜。例如，對于創(chuàng)業(yè)團隊來說，活下來是最重要的尤揣，所以創(chuàng)業(yè)團隊崇尚的是敏捷開發(fā)搔啊，快速構建，靈活試錯北戏，37signals的《Getting Real》是這種思想的最好詮釋负芋。這樣的研發(fā)體系特別適用于不需要太復雜的底層設計，功能扁平化的嗜愈，可以快速開發(fā)原型旧蛾，小迭代不斷擴展的應用，特別是web應用和APP蠕嫁。

另外锨天，架構師也不是技術人員唯一的方向，甚至不是大多數(shù)技術人員的職業(yè)方向剃毒。在技術上病袄，架構師是廣度優(yōu)先兼具深度，同時在技術之外附帶了許多的業(yè)務性和組織職能赘阀，而很多的技術人員會更傾向于在技術的深度上不斷挖掘益缠，也不愿意投入太多的精力在業(yè)務和溝通上，這樣的技術人員其實更適合的是技術專家的路線纤壁。技術專家研究的是純粹的技術左刽，這里面可能有算法、有編程語言酌媒、有運行容器（虛擬機欠痴、操作系統(tǒng)、應用服務器秒咨、中間件）喇辽、有通訊機制，這些都有足夠的源源不斷的問題等著技術人員去解決雨席，而他們解決的問題菩咨，也成為軟件技術不斷向上抽象，不斷模式化的基礎陡厘，所以抽米，技術專家的路線也是同樣重要的。