如何成為架構師？_ZenDei技術網路在線

作者總結這些年在支付寶做架構的經驗，把自己摸索成長的內容寫下來，從對架構師的認知到業務能力和架構能力多方面總結了案例經驗，希望可以幫助到大家。 ...

作者總結這些年在支付寶做架構的經驗，把自己摸索成長的內容寫下來，從對架構師的認知到業務能力和架構能力多方面總結了案例經驗，希望可以幫助到大家。

在內網上有太多的架構相關的文章了(比如大名鼎鼎的自頂向下)，我之前也寫過應用架構設計的經驗。但是總有種霧裡看花的感覺，好像有很多相關的知識，soa、分散式事務、DDD、複雜系統重構、領域建模、業務架構、等等等，這些複雜的名詞和知識感覺學了一堆仍然不得其法。

所以我準備把我這些年在支付寶做架構，自己摸索成長的內容寫下來，看能否幫助到大家。

成長，是認知的升級

我們經常說，要有架構師的能力，或者說需要成長為一個架構師。但是我們需要怎麼成長？或者說什麼才是“能力”？架構師的能力包含了什麼內容？在我看來，能力的本質就是認知。所以，所謂架構師就是有著架構師的認知，和一些通用技術能力。

為什麼

在我的認知里（哈哈，這句話也說明瞭這個標題的重要性），所謂能力，就是不同的認知能力。所謂成長，就是認知升級的一個過程。我想先用一個例子，來說明這個事情。我在面試中經常被問到一個問題，我也喜歡問別人：java當中如何處理多線程，如何處理併發。

高級工程師的回答：

使用Thread對象的方式來開啟線程，傳遞Runnable，在多線程裡面處理業務代碼，這樣就是並行處理了。此外在jdk1.5裡面，增加了Executors類，可以方便的使用一些ThreadPool來處理多線程的線層復用部分。併發安全部分，如果多線程訪問共用資源，那麼就會有線程安全問題。我們可以使用sync關鍵字來同步代碼。jdk1.5之後是Lock可以處理。這裡可以擴展出很多的問題，比如Lock的實現原理，sync基於對象頭，局部變數沒有線程安全問題（線程棧）等等的擴展問題。

但是這樣回答有問題嗎？沒有問題，不過沒回答完。

我的回答：

不用多線程。這是我真實的回答，同時我99%以上的場景都拿到了正反饋。即：面試官非常認可我的回答。具體這個問題我怎麼回答，我接來下講，什麼是架構師的認知就會說到。

這裡，我想通過這個例子說明的就是：能力的不同，對於這個問題的認識就不同。反過來說也一樣，對這個問題的認識的不同，也代表的能力的不同。而這，就是為什麼我覺得成長，是認知的升級。所謂認：就是我們對事務的認識，理解，歸因和定義。所謂知：就是我們要做的事情的方法，方案，選擇和決策。

是什麼

那麼架構師，需要的認知是什麼呢？我從阿裡的job model裡面抽離出來關鍵字：系統性&體系化思考，知其然知其所以然。仍然用上面的問題：java當中如何使用多線程？如何處理線程安全問題？

我的回答：不用多線程。

為什麼？

從一些危害講，業務系統處理業務請求，如果使用多線程模型並且使用了sync，非常容易導致請求hang死，並且不利於我們的併發。
從線程技術上來說，預設是unbound。這會導致很多的記憶體溢出，並且使用多線程，伺服器重啟會導致業務處於不可知的狀態。
從使用原因來說：業務中使用多線程（有別於Tomcat這種容器中間件）是為了提高併發能力，或者是非同步化業務能力。而這兩種都有其他的方案來替代。比如高併發，我們可能會進行一些拆分操作，比如非同步化，會使用消息隊列等。
怎麼做呢，比如非同步化，我們用消息隊列。如果是資源共用，那麼儘量做到讀，而不是寫。如果是共用寫，那麼根據業務場景儘量拆分，然後歸攏業務職責。這也是架構設計中聚合的重要性。很多框架比如netty，都有無鎖設計。

我上面簡單的說了一下。正常業務中是不會用線程池的。

這體現了哪些方面呢。

體系化

比如我在回答這個問題的時候，很隨意的拆分成了幾個維度來回答：壞處，技術難點，使用場景，最佳實踐。這就是當我們回答一個問題的時候，自然而然的按照一定的模型思考，然後進行回答。無論這個模型是什麼，他都是體系化的一種。

比如直接回答：1.為什麼要用多線程？2.不用多線程有沒有別的方案等等，這些都是思考的一個模型，按照這些維度進行拆分，這些維度進行彙總。就是體系化。

很有趣，讀到這裡又可以停下來了。我們可以回答：如何拿到架構師offer？

我們能否做到一個維度拆分？比如我這個文章，就是一個拆分的維度。而開始思考維度，就是架構師需要的一個認知，這也是體系化&系統化思考的表現。關鍵不在於結構是什麼，關鍵在於需要有結構。

知其然知其所以然

為什麼體現了這個呢，其實很簡單，就是一個能力：多問一個why。這個能力是極其重要的，往往我們對於問題的定義高度，就決定了我們的架構高度。比如剛纔的例子：如何處理線程安全問題？多問一個why：為什麼要處理線程安全問題？可能這個時候就發現：是因為多線程併發訪問共用資源問題。

那麼我們的方案是不是就可以變成：不訪問，主要是不寫入共用資源，是不是就沒有線程安全問題了？此外，也可以問：為什麼要用多線程？可能回答是：要處理多任務並行能力，或者任務非同步化能力降低請求耗時問題。那麼是不是有別的技術方案可以解決？消息隊列。可靠消息非同步化能力。這點非常非常非常重要，重要到應該形成我們的本能。甚至不僅僅是技術方面。比如我這個文章，就可以問，為什麼是兩部分。為什麼是架構師。等等。技術上，任何一個框架，都要問，這個框架解決了什麼問題。

怎麼做

可以從認知結構上和行為習慣上來說我們怎麼做到成長。也可以直接給出答案，我們應該做什麼具體的事情。我還是從這兩個維度來描述這個問題。有沒有發現，我說的內容都是總分結構？其實這是非常常用的一個方式。

認知結構

怎麼做很簡單，就是要多想一點，要知道用什麼方法多想一點，多思考一點。而這個方法就是怎麼做，思考出來的過程，就是認知結構，做到了這點，就會很快的成長。

我會簡單的解釋一些分析方法。

首先金字塔模型裡面說的一個：MECE原則

總結來說就是兩個維度：無重覆，無遺漏我們描述一個問題或者事情，應該做到不重覆。比如我們說什麼是人類，可以說兩個維度：生理性別男，生理性別女。這兩個維度是不重覆的（這裡不討論假定性別問題）。並且是不遺漏的。如果我們劃分是：少年，青年，老年，這就不是一個很好的維度，因為年齡可能存在交叉。

5w2h這個維度思考

5w其實就可以劃分成：

2w（分析維度）：why what。回答為什麼和是什麼這個問題。
3w（屬性維度）：when who where
1h ：how to do 核心本質怎麼做
1h ：how much 核心成本，也是ROI。決策的核心維度，投入產出比。（這個非常核心，沒有最好的架構，只有最合適的架構）

我講解5w2h的這個過程，就是自然而然的對5w2h進行維度拆分的過程：分析維度，屬性維度，關鍵方案，關鍵ROI。我不斷的重覆這個事情，就是想讓大家理解，這些維度都是一個個的方法。我們要形成自己拆維度的習慣。

3why方法

很簡單，對於任何問題，我們追問3個為什麼。這樣就能定義問題的本質，直面我們具體要解決什麼問題。比如：

我們為什麼要獲得架構師offer？可能是我們想獲得成長和一個好工資。（這裡就明白我們本質需要，我們是看重工資還是真的成長空間？如果是成長，可能是找到幾個良師益友，也不一定是換公司）

我們為什麼要獲得一個好工資？可能是想有更好的生活。（這裡就會發現，其實我們還是回到了生活本質，可能會引入wlb這個問題，可能架構師就不是這麼重要了）

什麼是更好的生活？可能是自我價值的體現。（這裡可能就會更好的認識自己，所以認知的升級，也是不斷加深自我認知的一個過程）

還有很多很多，比如swot，四象限等等。關鍵是幫助大家打開一個門。這個門就是：我們要多想想，並且我們是要按照一定的方法多想想。

具體的事情

這裡我都會在後面詳細的解釋。對於我們技術人員來說。在日常工作和學習中，可以做下麵幾個事情。

1.抽象

我感覺這也是架構的基礎，哪怕從架構的第一階段：框架，開始，都是解決某一類的特定問題。比如ORM框架解決db和java代碼之間的映射關係等問題。

在我們的實際業務代碼中，我們儘量能對我們要實現的功能，多問一個why，也就是多抽象一點。比如一個活動參與次數的功能，我們抽象定義成一個通用的計次服務。這樣可以多業務場景復用。比如我們處理業務報錯之後的特殊邏輯，可以用AOP+異常處理流程。來做一個通用的框架，可以解決所有分支鏈路和主業務鏈路的解耦問題。

2.分層定義

按照清晰的維度，進行明顯的層次劃分。不同的層次有不同的特性和符合這一層次的關鍵職責。

在具體的工作中，有個習慣大家可以試試：我們總歸有一層設計，是沒有業務語義概念的。比如完整的一個insert操作。這個insert sql肯定沒有業務語義，完全不理解這是一個什麼場景需要insert。它只專註於實現insert功能。按照這種方法。我們就可以不斷的抽象出不同的功能。在具體的架構方法裡面我會介紹的詳細一些。

3.思考業務問題，業務本質與業務價值

要思考我們為什麼寫代碼，是實現某個功能，這個功能最終怎麼產生的業務價值，那麼對我們的功能就有什麼要求？對我們代碼的抽象，是架構，對業務本質的抽象，也是架構。業務價值最終決定著我們的架構價值。

業務能力

從我們技術角度，業務就是我們要解決的”問題“。因為對於業務的定義，公司層面上就是要做”賺錢的事情“。而技術同學，代碼怎麼產生價值，就是代碼怎麼賺錢，所以描述業務能力，就是描述我們的定義問題能力。

業務=賺錢的問題

代碼=怎麼賺錢的問題

業務就等於，代碼上要解決的問題。

必須說明，在公司內部晉升和外部面試，最大的不同就在於”業務“描述上。因為公司更考察業務洞察能力和業務本質定義的專業能力。而外部公司，往往不會直接做相關的業務，只會做相關內容，所以考察的往往是”通用的“，並且是”成熟的“特定內容解決方案。比如資金類業務，電商類業務，創新類業務，toC個人類業務這些業務場景中遇到的技術問題。要想說清楚技術方案，就必須介紹業務背景。而這就是體現技術專業度的地方。還有一部分是為了引出架構問題，描述我們的架構解決了什麼業務問題，就需要對業務背景，業務本質，業務問題進行高度抽象的總結。這也是業務能力。

業務背景

是對我們系統的高度總結，在後續的面試準備裡面我會好好的描述如何結構化的講述我們的業務背景問題。

這裡的業務背景是從我們系統要處理的核心功能角度出發來描述的。比如：一個電商公司，一定會分交易領域，匯金領域，商家領域，商品領域。每部分就是核心對要做的內容來描述。比如交易領域是圍繞一筆電商交易單據的狀態流轉的串聯。支付領域是面向用戶支付資產轉移等等。這些簡單的解釋一下核心職責。核心職責也一定會和架構核心定位相關。

業務問題

我一直覺得，架構最終目標還是解決問題的。否則沒有”架構“這個概念的。如果只寫一個hello word那不會有這些問題。所以要正確的認識和描述，我們的業務具體發生了什麼變化，我們的業務邊界是否發生了擴展，我們是否增加了一些業務場景。而這些變化，對我們的系統造成了什麼問題，我們怎麼進行解決的。就體現了我們的架構能力。

業務發展判斷(前瞻性)

首先，前瞻性以及基於前瞻性判斷的架構設計，一定是可考察的。可考察就意味著一定是有方法的。是有“套路的”。否則根本沒辦法做出一個面向未來的架構，只能憑運氣或者架構演進&維持。另外，需要大家明白一個事情：業務sense，業務前瞻性，最終還是要為架構服務的（或許後面的戰略思維是不一樣的）。我從下到上分幾個方面來說：

架構演進，擴展性

這是框架和架構設計部分。這麼多年了spring的IOC本質發生變化了嗎？沒有。為什麼？

因為是基於我們核心架構定位（DI，控制翻轉等）出發來定義的。這樣本質不變，主體結構就不變，發展就是橫向以及縱向發展的。

橫向：會有更多的平臺產品，業務場景出現，但是關聯關係不變。

縱向：會有更多的前後功能延伸出現，但是本質不變（比如spring做了很多的cloud）

網狀：關係變化，所以我們建議把“獨立”作為核心架構原子概念，這樣關係就是另外的一個概念（半文鏈接理論）。

這樣整體框架和核心架構定位上，是不會發生變化的。

業務演進

業務演進，一定還是符合互聯網擴展形式的。如果我們不是做商業模式的擴展。那麼一定是原有商業模式的商業效率擴展。比如，淘寶並沒有更改交易的本質，營銷也是類似於傳統的吆喝。場地費其實就是地皮尋租的概念。

架構師往往沒有到戰略視角和洞察的階段，我們需要的是在特定的業務領域下，判斷未來的發展方式。所以就擴展就行，抽象定義好業務的本質，然後結合業務發展階段進行擴展。比如我之前做的結算架構，就可以按照橫向擴展演進的方式來進行。

為什麼？

因為“結算”的概念和商業資金鏈路，很早就有了。支付寶也只是把這些內容搬到線上，然後搬到我們的收單支付配套上。所以圍繞商家，供應鏈，供貨商，資金分賬，資金鏈路管理關係，就一定是未來的架構演進方向。因為現實社會中，別的企業用OA或者ERP這樣的系統就在做這個事情。那麼沒道理支付寶內部的結算域會有根本的變化。

這裡其實有個抽象，類比的一個方法，依賴我們的視野。比如我們做一個社區架構或者業務方向判斷。

整個互聯網社區，從最早的BBS-天涯-貼吧-校內-微博-知乎-抖音-小紅書。等等。可以抽象定義出來不同的模式和不同的內容載體（視頻，文字，圖片）。然後傳播從以前的單點-廣播-網狀-核心KOL。但是想想，和最早以前人們下班了之後，搬起來小板凳村口嘮嗑。沒什麼本質的區別。業務演進部分，最終就是回歸到:架構延續這個命題上的。

基於上面我的解釋，其實就有很好的一個方法來做：架構定位（隱喻）或者說明燈這個方法。因為業務本質是不會發生變化的，所以我們圍繞架構定位設定的核心領域模型，就不會發生根本的變化。除非我們的領域發生變化了

架構能力（設計）

這裡主要講在設計部分體現的能力，如果一個架構師在面試過程中最重要的地方，我覺得就是技術性。而這個技術性，就是我們用技術方案來解決架構問題的一種描述。

架構能力，展開說我可以說幾十篇文章。所以我直接給一個設計方法論。相信通過我上面對於認知的描述，大家也理解什麼叫方法論。

下麵是我之前做的一個架構方案的目錄。我覺得目錄就很好的體現了方法這個詞，因為無論什麼架構方案。都可以按照一定的目錄結構來寫。

方法論

我這裡說的方法論，就是我們做一個系統的架構方案需要經過的一些步驟，我們具體的產出物。無論是什麼架構，都可以按照一定的結構和維度進行分析和拆分，這種通用的方法，就是方法論部分。

方法論+業務能力，就是某個領域，某個功能架構能力的體現。

我這裡介紹我的常用方法：架構定位（隱喻），業務架構，應用架構。

我所做的所有架構工作，基本都是上面的三個事情。每一部分都有具體的產出，結合不同的業務場景我們都要運用不同的方法。但是就像我在認知裡面說的一樣，架構的工作也應該是分維度和步驟的。

下麵我詳細的介紹每一部分。

架構定位

架構定位是核心架構職責，架構上下邊界的高度抽象定義。用一種大家都覺得”理應如此“的方式來提出。和業務概念高度相似。不同的是架構定位還包括功能部分。比如：

交易系統：圍繞一筆商品交易的單據，進行不同狀態的流轉和業務參與者關係的流程組裝與驅動。

支付系統：基於用戶有價資產償付。

商品系統：圍繞商業活動中，對於物的屬性定義與管控。

賬務核心：圍繞資產管理與資產流轉驅動。

等等，我舉的例子不一定對，但是大家都會覺得有一點道理，有一點抽象，描述了是什麼和做什麼。如果感覺對，又不對，那麼我們的架構定位可能就設定對了。

此外，我還想介紹一下我的一個理論：架構隱喻

我把這種方法叫做明燈。明燈不是方向，不是目標，不是我們的實施路徑。但是就像黑暗之中的瑩瑩燈火，指明瞭我們的方向，照亮了我們的目標，牽引著我們的道路。這種”牽引“就是明燈所帶來的核心結果，他解決了我們的架構分層問題，平臺產品問題，架構延續問題。而xp：極限編程，這本書裡面的：架構隱喻。我感覺就是明燈的一種具象化。用一種具象的概念讓大家理解我們架構的”感覺“。比如：我們都知道什麼是電商裡面的交易。那麼架構隱喻就可以是：一手交錢，一手交貨。

架構定位的作用是巨大的。它指引著我們進行架構方案的設計，也幫助我們做架構協同，架構宣講，架構延續等等內容。同時在一些具象化的內容也直接幫助著我們，比如核心平臺產品是不可能超過架構定位的。在很多非常複雜的架構方案裡面，對架構定位可能就討論一個多月。同時，如果沒有進行這一步，架構方案在進行到某個程度的時候也一定會失敗。比如有的域進行架構升級，上來就分析業務場景，從來沒說要升級什麼。然後直到最新方案。才隱約提出一個架構定位。而從這個時候開始，架構升級才艱難的進行了下去，但是圍繞分層，又出現了很多問題，比如分了7層，仍然在業務推演上有問題。

業務架構

這裡的業務架構，主要是描述我們怎麼設計業務功能的。因為只有劃分好了功能，我們才能達到代碼復用。才能隔離風險，提高研發效能，解決複雜業務場景落地等等等的問題。

業務架構，就是描述系統的業務功能與職責。舉例來說，業務架構就是描述我們具有哪些職責和功能，我們怎麼和上下游分割劃分（L0）。比如交易系統劃分業務架構：

對上：提供下單，支付，確認收貨，評論等業務階段暴露

核心：交易單據，狀態流程，業務組件串聯

對下業務功能：創建交易，支付交易，庫存扣減，安全校驗等等

標準的方法中我採用的是三層架構。註意這個可是和Controller，Service，Dao完全不同的概念。這三層是指：業務場景定義，平臺產品定義，平臺服務能力定義。

寫到這裡，我發現一個問題，我主要圍繞一個非常複雜的背景：平臺架構，在描述我的方法。也有可能有的同學沒有處理過這樣複雜的問題，或者沒有這部分的經驗。首先，方法一定是相通的，能理解複雜的系統，沒道理做不好trade off，沒道理做不好簡單系統的業務劃分。此外，這是不是說明，我們做更多的事情，也更好的幫助我們自己成長。所以這並不是PUA的一種。

業務場景是描述整個業務身份，我們的系統要處理哪些”業務“。然後這些業務是按照什麼維度進行劃分的。業務場景定義最難的地方在於”垂直拆分“的問題。即：為什麼業務A和業務B是兩個業務。為什麼不是一個業務。什麼時候新增業務場景，如果一個業務A和業務B只有100行左右的代碼不同，怎麼辦。等等這些問題。

平臺產品是描述”非業務相關，業務通用“的。某個特定的平臺型功能聚合。提供標準的擴展和標準的解決方案。比如”擔保交易“這是一個非常典型的平臺產品，淘寶，天貓都是基於這個交易鏈路來做的。

平臺產品最難解決的是”橫向拆分“問題。比如某個功能是不是平臺產品功能，還是只屬於某幾個業務的功能。

平臺服務能力是描述完全隔離的，獨立提供功能的代碼。註意一定是隔離的，並且獨立的。這是平臺服務的基本特性。比如一個資金轉移服務，安全校驗服務等等。平臺服務能力最難解決的也是垂直問題。就是什麼是獨立服務，什麼是服務配套。

這裡可以展開說很多內容，比如按照介面集成維度劃分場景，然後我們圍繞領域模型定義產品流程，這樣可以跨介面場景復用。然後我們的流程是基於領域模型DDD的。

下游核心服務，就是我們的DB（這也是洋蔥圈架構標准定義）。所以我們把DB的操作定義成原子服務。這是一個非常簡單場景。但是如果我們是這樣思考和設計的。那麼我相信這就是一個架構師的能力標準。

業務架構還包括一些核心內容，比如：核心領域模型，核心業務流程等內容。這些都是在具體實踐中。我們進行一些關鍵設計。

應用架構

應用架構，就是解決我們業務架構然後代碼落地的問題。就是如何用代碼實現我們的業務架構中的業務功能，如何組織我們的代碼，如何按照模塊進行劃分。

比如我理解的典型洋蔥圈架構，就是一種應用架構方法論。因為這裡涉及到了DB。DB是具體技術的概念。在業務架構中是不會出現具體技術的。比如”支付“是業務功能。這個功能甚至都不會是java來實現的。下游可能是一個系統。這裡就是區分。

應用架構是包含關鍵技術架構的。因為應用架構關註與“實現”層面的事情。

我的架構經驗比較複雜，這裡不詳細展開了。主要是兩個框架：DSL框架和擴展引擎框架。我這裡就介紹一種方案：基於不同業務場景擴展參數組合+workflow復用的架構。

這是一種非常簡單的代碼組織方式，大部分系統都是用這種架構方式的。核心就是基於功能action。然後業務中用到五個功能，就把五個action串聯起來就行了。

架構延續

在業務發展判斷（前瞻性）裡面，我描述了我們的業務能力，業務sense怎麼提升。但是，我想說明的是，作為架構師，我們的業務能力，最終還是為架構服務的。當然了，繼續往下個階段，就不一定了，因為解決問題的手段不僅僅是“架構”這一個手段了。

基於我們對業務發展的判斷，我們框架部分的靈活擴展設計。是否就能保證我們的架構核心延續下去呢？其實我覺得還不夠。

因為架構延續，不僅僅是能完成業務功能。同時還需要保證我們的核心領域模型，架構分層，核心架構概念，技術風險，研發效能。這些部分能夠持續不斷的演進，不說變好，至少沒有那麼快的變壞。相信這個問題都有感覺，因為一個5年左右的系統，代碼經常被稱之為“屎山”。我們經常戲稱我們的工作就是屎上雕花。那麼怎麼能夠做到架構延續呢？

我從一個比較感性的角度來說明這個問題：架構隱喻

這是我在XP極限編程裡面學習到的一個概念，裡面很多內容我並不能贊同。但是這個核心方法我還是保留了下來，然後結合我的工作進一步的解釋和落地。

另外，我是一個絕對的“英雄主義史觀“。在我看來，所有的制度，流程，業務設計，架構設計。最終都取決於人這個因素。我們沒辦法很好的限制人，我們只能按照”感性“的維度，去引導大家。架構隱喻，就是一種具象化的，感性化的。讓相關同學都能理解和明白相關架構定位和發展方向的”感覺“。依托這種感覺，我會不斷的進行我們的架構迭代。朝著我們的目標方向發展。好的架構一定是延續的。

下麵我還會講一些具體的方法和拆分的維度，但是這個是屬於頂層概念。一定是基於”架構隱喻“才能讓大家保證執行不出差的。否則無論是什麼方法，只要提出了，都還需要解答另外一個問題：如何保證別人落地的過程中和你想的不出現gap？

在具體的架構延續方法上，還會分幾個部分（上面也說了）。

核心領域模型

我們的架構設計，一定是圍繞核心領域模型來的，基於我們的判斷設定的。如果核心領域模型需要發生變化。那麼就是另外的一次架構升級，這個時候往往是翻天覆地。所以儘量保證核心領域模型不變，即地基不變。

架構分層

明白核心領域模型之後，思考我們的架構分層，在分層上可以做到內容的橫向擴展，而不是分層擴展。比如我們設計了平臺產品，儘量進行平臺產品的多樣性，可以自由組合設定，而不要再把平臺產品抽象成一些所謂的前臺產品，後臺產品。因為往往用”多加一層“的手段，去解決業務問題的時候。是得不償失的。我們往往可以通過多加一層的手段去解決技術問題。比如ACL，這種防腐層的設計，在業務語義上面沒有任何的變化，這種就是純技術適配，還有比如各種場景識別，不同的API（http，RPC，消息）的接入層。如果是加分層的手段是解決業務問題，往往不行，比如業務層這個概念。我們很容易拆分出業務場景層，業務流程層。但是這又有什麼意義呢。還是要增加很多很多的概念去解釋怎麼劃分這兩層。（半文鏈接理論）所以架構敏捷度=處理問題個數/架構概念個數。我們儘量保證的是概念更少，而不是更多。

擴展引擎技術

這個會和trade off來說明。我一直認為，架構是一定一定不能解決所有問題的。所以不要反人性的去阻止大家寫特殊的if。而是能夠讓大家不寫if（更簡單），獨立寫if。這個就是擴展引擎部分。

架構trade off

如果業務不發展，那麼根本不用架構。當下的代碼就可以用，為什麼要設計架構呢？所以架構一定要解決未來的問題，那麼架構就不能全解決當下的問題。那麼當下的問題全解決是否可以呢？也不行，因為有的業務不發展了，那就也不用解決。有的問題還在發展，首先要解決的是發展，有的ROI很低等等。

上面說明瞭。架構一定是要trade off的。沒有銀彈，需要面向未來。就一定容忍我們當下的一些妥協。這也是我一直說的：做不做架構升級需要很保守，架構升級方案需要很積極。

在實踐過程中，上面兩個事情最終決策的人往往是同一個，所以架構升級往往不如人意。（不能又保守，又激進）在接受了架構需要trade off之後，其實我們面對的大部分是”多少“的問題。比如有100個問題。我們能容忍21個？還是22個。這也是我在架構發展階段裡面說的”“共識”問題。這就需要結合不同的業務場景和當前業務階段來定義了。

我能給出的方法是：基於架構定位，設定架構目標。設定核心問題，核心問題必須解決。其他的其實都不影響主體架構。這也是一個完整的架構方案裡面，需要體現架構目標的原因。

流程與機制

需求迭代流程，代碼研發流程，系分流程，穩定性保證機制等等。

通用技術方案（包含設計）

這裡就是通用的技術方案，這個和業務無關，但是又有別於標準的框架知識。是一些常見下的標準技術解決方案，比如分散式事務，多活等。這些特定問題的解決方案。我這裡羅列一下，大家可以去瞭解一下

技術方案部分

這裡是純技術，需要每個都非常瞭解：

tcc
jta/xa
saga
最終一致性
冪等

典型技術方案

ldc
分庫分表
高併發拆分
集群
多活&熱備
分散式鎖
唯一性管控

設計方案部分

這裡講的是類似設計模式，用一些通用設計方案，解決我們遇到的問題

acl
執行模板
流程式
多策略
流程化
AOP
設計模式

為什麼在能力裡面沒有介紹純技術,技術框架呢?因為高級開發就應該達到了。

作者|半文

本文來自博客園，作者：古道輕風，轉載請註明原文鏈接：https://www.cnblogs.com/88223100/p/How-to-become-an-architect.html