支付寶架構師：從工程師到架構師的成長之路

0、前言

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

在寫這篇文章以前，我特地把這幾年看過的關於架構和架構師的 書從新翻了一遍，結果發現它們的定義或多或少有一些不同，而通過了這幾年，一些以前贊成的觀點，如今的我也不敢苟同了。另外一方面，業界對於架構師這個崗 位，其實也沒有統一的角色定位。在阿里巴巴，前幾年是有專職的「架構師」職位的，如今已經迴歸到「工程師」、「專家」、「研究員」這樣的純技術職位。而我 面試過的人中，也有各類各樣的「架構師」，不少小團隊裏，項目經理就常常自認爲架構師。大概架構師目前還不至於稱爲一個職業，更多的是在項目中的一個角 色，而其角色定位也是模糊的，所以，這個文章裏，我主要仍是從本身的理解出發，闡述一下這個角色的定位和我的發展的建議。
一、架構師的定義

架構師：任何複雜結構的設計人員。

架構師的名字來自於建築業，Software Architect直譯應該叫「軟件建築師」。從不少方面講，軟件架構師的工做跟建築師很像，爲了尋根問祖，曾經我也看了很多建築設計的書（推薦一本《建築的永恆之道》），最後我發現，二者一脈相承，現階段分道揚鑣，將來也許異曲同工。

一脈相承——不論是建築師仍是軟件架構師，都是爲了「大圖」而存在，作好頂層設計，充當需求方和實施者的橋樑，是其最重要的兩個職責。

分道揚鑣——二者的發展 階段不一樣所致。建築業實踐綿延數千年，理論根基有數百年，真正成爲一門學科也有一百多年，而軟件架構真正出現不過二十年。建築業已經在足夠高的層面上模式 化，建築師可以真正去「設計」，也就是決定「作什麼」。而軟件行業還在高速發展中，各個層面的技術還在百花齊放。技術的選擇意味着權衡，所以軟件架構師更 多還在關注「怎麼作」——這也是建築師能夠稱設計師，而軟件架構師只能算高階工程師的緣由，設計師更關注美感，而美感在軟件架構師的考慮優先級裏，排不上 第一。

異曲同工——計算機發展 的幾十年，也是技術不斷往上抽象和模式化的幾十年。SOA、IoT、IFTTT等技術理念已經接近於建築行業的模塊化級別，各類「智慧城市」、「生態城 市」已經在架構層面上考慮「作什麼」。假以時日，架構師也許能成爲一個真正的純「設計」的職業，到時候大學裏也能夠開設「軟件架構」的專業了，那一句「建 築設計師在成爲建築設計師以前，是不會成爲建築工人或工程師的「也能在軟件行業成爲現實。

固然，這只是可能的將來，這須要咱們這些前輩技術人員，可以和建築行業的前輩同樣，把技術規範化，設計模式化，還要有一套關於架構美學和功能設計的完整統一的約束，任重而道遠。
二、架構的職責

在軟件技術發展的前幾十年，是沒有架構師這個稱謂的。全部的 人都是程序員，可能有個帶頭的人，叫主程序員。隨着計算機技術的發展，軟件覆蓋的領域愈來愈大，軟件自己也愈來愈複雜，如今，動輒幾百萬行、幾千萬行代碼 的軟件系統已經很是廣泛。軟件的複雜化，對於開發人員的腦力負擔也不斷增大，而人腦所能處理的信息量是有限的，因而，軟件開發工具、開發方法也在不斷髮 展，從彙編語言到高級語言，從函數到框架，從面向過程到面向對象，從設計模式到架構模式……

整體而言，人類在軟件開發工具的各個維度上都在作着「封裝」 和「抽象」，架構設計是這種抽象和封裝的最高層次。從架構的維度上，已經不須要考慮語言、函數、設計模式這一類的抽象，而是站在總體軟件系統的高度上，考 慮系統設計的技術合理性，需求實現的完整性，商業訴求的匹配度（主要是成本和效率）——這是架構的技術職責。

另外一方面，隨着行業的發展，軟件項目的參與角色和人員也越來 越多，從起初只有程序員和需求方，發展到技術、產品、設計、商務、項目管理多團隊，技術團隊內部的分工也愈來愈細化，前端、後端、測試、運維、售前售後技 術、集成技術等應運而生。架構師是技術團隊面向產品設計等團隊的接口人，承擔着彌合技術與非技術團隊之間知識和語言體系差別的職責，同時做爲技術團隊的帶 頭人，要負責勾勒藍圖，明確邊界，讓不一樣技能的團隊通力協做，最終完成軟件系統的總體建設和發佈——這是架構的組織職責。
2.一、架構的技術職責

首先，架構師常常被類比於建築師，可是有兩個建築領域的基礎理念，在軟件架構領域是不成立的（至少現階段不成立）：

建築設計師在成爲建築設計師以前，是不會成爲建築工人或工程師的。——現階段的軟件架構師，必定是從軟件工程師成長起來的。

建築學和工程學之間的區別表如今「作什麼」和「怎麼作」：建築師決定作什麼，工程師想出怎麼作。——現階段的軟件架構師，除了決定作什麼，也要決定關鍵部分怎麼作。

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

    抽象設計；
    非功能設計；
    關鍵技術設計。

首先是抽象設計。架構師須要能自由地在不一樣的抽象層次和視角上分析需求，不一樣的架構層次/視角提供了不一樣的視圖，這些視圖互相驗證，又能構成總體的設計大圖。架構的抽象層次分紅兩個維度：

    垂直維度

從上到下，分紅企業架構、解決方案架構、應用架構、系統架構 等，這個分層的邏輯，是提供不一樣顆粒度的業務建模。CTO關注企業架構，它提現了一個企業總體的IT技術建設的戰略選擇，典型的就是集中式和SOA、大型 機和雲計算的選擇等；產品經理和運維關注應用架構，這裏映射了產品的業務流程和應用的總體部署依賴；外部客戶關注解決方案架構，它定義瞭如何經過產品的整 合和協同，解決特定客戶的特定的技術方案需求；研發工程師關注系統架構，這裏定義了單個系統的領域建模和系統框架。

    水平維度

具體到對某一個業務的架構設計，又能夠區分出業務架構、數據 架構、技術架構、應用架構幾個不一樣的視角。業務架構是對業務領域和業務流程的分析抽象，須要提煉出業務的核心領域模型，業務的可變和不變部分，這是架構師 和產品經理協同完成的；數據架構基於業務架構提煉的核心領域模型作數據模型和存儲模型的設計；技術架構基於業務的性能，可用性，安全等非功能性指標，肯定 語言、框架、中間件、部署等技術選型；應用架構基於業務抽象設計應用系統的層次結構、系統邊界等。

在這些架構劃分中，企業架構匹配商業模式，業務架構匹配業務模式，其餘幾個架構的劃分，更多的是從技術的不一樣視角來看，他們提供了從不一樣的抽象層次，不一樣的切面對於功能需求的分析和建模。

同時須要說明的是，架構的抽象是匹配於業務的，就像橋樑設計師不能直接轉作摩天大樓設計，架構抽象也是區分領域的，每個業務領域都有本身的獨特性，所以在架構上也是千人千面的，好的架構設計也是對於業務抽象得最好的設計。

架構師的另外一個技術職責，是對非功能需求的分析。這 也是「架構服務於功能，高於功能」的含義。這裏的非功能性需求包括了軟件系統的可靠性、擴展性、可測性、數據一致性、安全和性能等。考慮到成本和運行環境 等限制，這些非功能性需求不少時候是不能同時知足的。這個時候就須要「權衡」