在內(nèi)網(wǎng)上有太多的架構(gòu)相關(guān)的文章了(比如大名鼎鼎的自頂向下)，我之前也寫過應(yīng)用架構(gòu)設(shè)計(jì)的經(jīng)驗(yàn)。但是總有種霧里看花的感覺，好像有很多相關(guān)的知識(shí)，soa、分布式事務(wù)、DDD、復(fù)雜系統(tǒng)重構(gòu)、領(lǐng)域建模、業(yè)務(wù)架構(gòu)、等等等，這些復(fù)雜的名詞和知識(shí)感覺學(xué)了一堆仍然不得其法。
所以我準(zhǔn)備把我這些年在支付寶做架構(gòu)，自己摸索成長的內(nèi)容寫下來，看能否幫助到大家。
我們經(jīng)常說，要有架構(gòu)師的能力，或者說需要成長為一個(gè)架構(gòu)師。但是我們需要怎么成長？或者說什么才是“能力”？架構(gòu)師的能力包含了什么內(nèi)容？在我看來，能力的本質(zhì)就是認(rèn)知。所以，所謂架構(gòu)師就是有著架構(gòu)師的認(rèn)知，和一些通用技術(shù)能力。
在我的認(rèn)知里（哈哈，這句話也說明了這個(gè)標(biāo)題的重要性），所謂能力，就是不同的認(rèn)知能力。所謂成長，就是認(rèn)知升級(jí)的一個(gè)過程。我想先用一個(gè)例子，來說明這個(gè)事情。我在面試中經(jīng)常被問到一個(gè)問題，我也喜歡問別人：java當(dāng)中如何處理多線程，如何處理并發(fā)。使用Thread對(duì)象的方式來開啟線程，傳遞Runnable，在多線程里面處理業(yè)務(wù)代碼，這樣就是并行處理了。此外在jdk1.5里面，增加了Executors類，可以方便的使用一些ThreadPool來處理多線程的線層復(fù)用部分。并發(fā)安全部分，如果多線程訪問共享資源，那么就會(huì)有線程安全問題。我們可以使用sync關(guān)鍵字來同步代碼。jdk1.5之后是Lock可以處理。這里可以擴(kuò)展出很多的問題，比如Lock的實(shí)現(xiàn)原理，sync基于對(duì)象頭，局部變量沒有線程安全問題（線程棧）等等的擴(kuò)展問題。不用多線程。這是我真實(shí)的回答，同時(shí)我99%以上的場景都拿到了正反饋。即：面試官非常認(rèn)可我的回答。具體這個(gè)問題我怎么回答，我接來下講，什么是架構(gòu)師的認(rèn)知就會(huì)說到。這里，我想通過這個(gè)例子說明的就是：能力的不同，對(duì)于這個(gè)問題的認(rèn)識(shí)就不同。反過來說也一樣，對(duì)這個(gè)問題的認(rèn)識(shí)的不同，也代表的能力的不同。而這，就是為什么我覺得成長，是認(rèn)知的升級(jí)。所謂認(rèn)：就是我們對(duì)事務(wù)的認(rèn)識(shí)，理解，歸因和定義。所謂知：就是我們要做的事情的方法，方案，選擇和決策。
那么架構(gòu)師，需要的認(rèn)知是什么呢？我從阿里的job model里面抽離出來關(guān)鍵字：系統(tǒng)性&體系化思考，知其然知其所以然。仍然用上面的問題：java當(dāng)中如何使用多線程？如何處理線程安全問題？從一些危害講，業(yè)務(wù)系統(tǒng)處理業(yè)務(wù)請(qǐng)求，如果使用多線程模型并且使用了sync，非常容易導(dǎo)致請(qǐng)求hang死，并且不利于我們的并發(fā)。
從線程技術(shù)上來說，默認(rèn)是unbound。這會(huì)導(dǎo)致很多的內(nèi)存溢出，并且使用多線程，服務(wù)器重啟會(huì)導(dǎo)致業(yè)務(wù)處于不可知的狀態(tài)。
從使用原因來說：業(yè)務(wù)中使用多線程（有別于Tomcat這種容器中間件）是為了提高并發(fā)能力，或者是異步化業(yè)務(wù)能力。而這兩種都有其他的方案來替代。比如高并發(fā)，我們可能會(huì)進(jìn)行一些拆分操作，比如異步化，會(huì)使用消息隊(duì)列等。
怎么做呢，比如異步化，我們用消息隊(duì)列。如果是資源共享，那么盡量做到讀，而不是寫。如果是共享寫，那么根據(jù)業(yè)務(wù)場景盡量拆分，然后歸攏業(yè)務(wù)職責(zé)。這也是架構(gòu)設(shè)計(jì)中聚合的重要性。很多框架比如netty，都有無鎖設(shè)計(jì)。
我上面簡單的說了一下。正常業(yè)務(wù)中是不會(huì)用線程池的。比如我在回答這個(gè)問題的時(shí)候，很隨意的拆分成了幾個(gè)維度來回答：壞處，技術(shù)難點(diǎn)，使用場景，最佳實(shí)踐。這就是當(dāng)我們回答一個(gè)問題的時(shí)候，自然而然的按照一定的模型思考，然后進(jìn)行回答。無論這個(gè)模型是什么，他都是體系化的一種。比如直接回答：1.為什么要用多線程？2.不用多線程有沒有別的方案等等，這些都是思考的一個(gè)模型，按照這些維度進(jìn)行拆分，這些維度進(jìn)行匯總。就是體系化。很有趣，讀到這里又可以停下來了。我們可以回答：如何拿到架構(gòu)師offer？我們能否做到一個(gè)維度拆分？比如我這個(gè)文章，就是一個(gè)拆分的維度。而開始思考維度，就是架構(gòu)師需要的一個(gè)認(rèn)知，這也是體系化&系統(tǒng)化思考的表現(xiàn)。關(guān)鍵不在于結(jié)構(gòu)是什么，關(guān)鍵在于需要有結(jié)構(gòu)。為什么體現(xiàn)了這個(gè)呢，其實(shí)很簡單，就是一個(gè)能力：多問一個(gè)why。這個(gè)能力是極其重要的，往往我們對(duì)于問題的定義高度，就決定了我們的架構(gòu)高度。比如剛才的例子：如何處理線程安全問題？多問一個(gè)why：為什么要處理線程安全問題？可能這個(gè)時(shí)候就發(fā)現(xiàn)：是因?yàn)槎嗑€程并發(fā)訪問共享資源問題。那么我們的方案是不是就可以變成：不訪問，主要是不寫入共享資源，是不是就沒有線程安全問題了？此外，也可以問：為什么要用多線程？可能回答是：要處理多任務(wù)并行能力，或者任務(wù)異步化能力降低請(qǐng)求耗時(shí)問題。那么是不是有別的技術(shù)方案可以解決？消息隊(duì)列。可靠消息異步化能力。這點(diǎn)非常非常非常重要，重要到應(yīng)該形成我們的本能。甚至不僅僅是技術(shù)方面。比如我這個(gè)文章，就可以問，為什么是兩部分。為什么是架構(gòu)師。等等。技術(shù)上，任何一個(gè)框架，都要問，這個(gè)框架解決了什么問題。
可以從認(rèn)知結(jié)構(gòu)上和行為習(xí)慣上來說我們怎么做到成長。也可以直接給出答案，我們應(yīng)該做什么具體的事情。我還是從這兩個(gè)維度來描述這個(gè)問題。有沒有發(fā)現(xiàn)，我說的內(nèi)容都是總分結(jié)構(gòu)？其實(shí)這是非常常用的一個(gè)方式。怎么做很簡單，就是要多想一點(diǎn)，要知道用什么方法多想一點(diǎn)，多思考一點(diǎn)。而這個(gè)方法就是怎么做，思考出來的過程，就是認(rèn)知結(jié)構(gòu)，做到了這點(diǎn)，就會(huì)很快的成長。總結(jié)來說就是兩個(gè)維度：無重復(fù)，無遺漏我們描述一個(gè)問題或者事情，應(yīng)該做到不重復(fù)。比如我們說什么是人類，可以說兩個(gè)維度：生理性別男，生理性別女。這兩個(gè)維度是不重復(fù)的（這里不討論假定性別問題）。并且是不遺漏的。如果我們劃分是：少年，青年，老年，這就不是一個(gè)很好的維度，因?yàn)槟挲g可能存在交叉。2w（分析維度）：why what。回答 為什么 和 是什么這個(gè)問題。
3w（屬性維度）：when who where?
1h ：how to do 核心本質(zhì)怎么做
1h ：how much 核心成本，也是ROI。決策的核心維度，投入產(chǎn)出比。（這個(gè)非常核心，沒有最好的架構(gòu)，只有最合適的架構(gòu)）
我講解5w2h的這個(gè)過程，就是自然而然的對(duì)5w2h進(jìn)行維度拆分的過程：分析維度，屬性維度，關(guān)鍵方案，關(guān)鍵ROI。我不斷的重復(fù)這個(gè)事情，就是想讓大家理解，這些維度都是一個(gè)個(gè)的方法。我們要形成自己拆維度的習(xí)慣。很簡單，對(duì)于任何問題，我們追問3個(gè)為什么。這樣就能定義問題的本質(zhì)，直面我們具體要解決什么問題。比如：我們?yōu)槭裁匆@得架構(gòu)師offer？可能是我們想獲得成長和一個(gè)好工資。（這里就明白我們本質(zhì)需要，我們是看重工資還是真的成長空間？如果是成長，可能是找到幾個(gè)良師益友，也不一定是換公司）我們?yōu)槭裁匆@得一個(gè)好工資？可能是想有更好的生活。（這里就會(huì)發(fā)現(xiàn)，其實(shí)我們還是回到了生活本質(zhì)，可能會(huì)引入wlb這個(gè)問題，可能架構(gòu)師就不是這么重要了）什么是更好的生活？可能是自我價(jià)值的體現(xiàn)。（這里可能就會(huì)更好的認(rèn)識(shí)自己，所以認(rèn)知的升級(jí)，也是不斷加深自我認(rèn)知的一個(gè)過程）還有很多很多，比如swot，四象限等等。關(guān)鍵是幫助大家打開一個(gè)門。這個(gè)門就是：我們要多想想，并且我們是要按照一定的方法多想想。這里我都會(huì)在后面詳細(xì)的解釋。對(duì)于我們技術(shù)人員來說。在日常工作和學(xué)習(xí)中，可以做下面幾個(gè)事情。我感覺這也是架構(gòu)的基礎(chǔ)，哪怕從架構(gòu)的第一階段：框架，開始，都是解決某一類的特定問題。比如ORM框架解決db和java代碼之間的映射關(guān)系等問題。在我們的實(shí)際業(yè)務(wù)代碼中，我們盡量能對(duì)我們要實(shí)現(xiàn)的功能，多問一個(gè)why，也就是多抽象一點(diǎn)。比如一個(gè)活動(dòng)參與次數(shù)的功能，我們抽象定義成一個(gè)通用的計(jì)次服務(wù)。這樣可以多業(yè)務(wù)場景復(fù)用。比如我們處理業(yè)務(wù)報(bào)錯(cuò)之后的特殊邏輯，可以用AOP+異常處理流程。來做一個(gè)通用的框架，可以解決所有分支鏈路和主業(yè)務(wù)鏈路的解耦問題。按照清晰的維度，進(jìn)行明顯的層次劃分。不同的層次有不同的特性和符合這一層次的關(guān)鍵職責(zé)。在具體的工作中，有個(gè)習(xí)慣大家可以試試：我們總歸有一層設(shè)計(jì)，是沒有業(yè)務(wù)語義概念的。比如完整的一個(gè)insert操作。這個(gè)insert sql肯定沒有業(yè)務(wù)語義，完全不理解這是一個(gè)什么場景需要insert。它只專注于實(shí)現(xiàn)insert功能。按照這種方法。我們就可以不斷的抽象出不同的功能。在具體的架構(gòu)方法里面我會(huì)介紹的詳細(xì)一些。3.思考業(yè)務(wù)問題，業(yè)務(wù)本質(zhì)與業(yè)務(wù)價(jià)值要思考我們?yōu)槭裁磳懘a，是實(shí)現(xiàn)某個(gè)功能，這個(gè)功能最終怎么產(chǎn)生的業(yè)務(wù)價(jià)值，那么對(duì)我們的功能就有什么要求？對(duì)我們代碼的抽象，是架構(gòu)，對(duì)業(yè)務(wù)本質(zhì)的抽象，也是架構(gòu)。業(yè)務(wù)價(jià)值最終決定著我們的架構(gòu)價(jià)值。從我們技術(shù)角度，業(yè)務(wù)就是我們要解決的”問題“。因?yàn)閷?duì)于業(yè)務(wù)的定義，公司層面上就是要做”賺錢的事情“。而技術(shù)同學(xué)，代碼怎么產(chǎn)生價(jià)值，就是代碼怎么賺錢，所以描述業(yè)務(wù)能力，就是描述我們的定義問題能力。必須說明，在公司內(nèi)部晉升和外部面試，最大的不同就在于”業(yè)務(wù)“描述上。因?yàn)楣靖疾鞓I(yè)務(wù)洞察能力和業(yè)務(wù)本質(zhì)定義的專業(yè)能力。而外部公司，往往不會(huì)直接做相關(guān)的業(yè)務(wù)，只會(huì)做相關(guān)內(nèi)容，所以考察的往往是”通用的“，并且是”成熟的“特定內(nèi)容解決方案。比如資金類業(yè)務(wù)，電商類業(yè)務(wù)，創(chuàng)新類業(yè)務(wù)，toC個(gè)人類業(yè)務(wù)這些業(yè)務(wù)場景中遇到的技術(shù)問題。要想說清楚技術(shù)方案，就必須介紹業(yè)務(wù)背景。而這就是體現(xiàn)技術(shù)專業(yè)度的地方。還有一部分是為了引出架構(gòu)問題，描述我們的架構(gòu)解決了什么業(yè)務(wù)問題，就需要對(duì)業(yè)務(wù)背景，業(yè)務(wù)本質(zhì)，業(yè)務(wù)問題進(jìn)行高度抽象的總結(jié)。這也是業(yè)務(wù)能力。
是對(duì)我們系統(tǒng)的高度總結(jié)，在后續(xù)的面試準(zhǔn)備里面我會(huì)好好的描述如何結(jié)構(gòu)化的講述我們的業(yè)務(wù)背景問題。這里的業(yè)務(wù)背景是從我們系統(tǒng)要處理的核心功能角度出發(fā)來描述的。比如：一個(gè)電商公司，一定會(huì)分交易領(lǐng)域，匯金領(lǐng)域，商家領(lǐng)域，商品領(lǐng)域。每部分就是核心對(duì)要做的內(nèi)容來描述。比如交易領(lǐng)域是圍繞一筆電商交易單據(jù)的狀態(tài)流轉(zhuǎn)的串聯(lián)。支付領(lǐng)域是面向用戶支付資產(chǎn)轉(zhuǎn)移等等。這些簡單的解釋一下核心職責(zé)。核心職責(zé)也一定會(huì)和架構(gòu)核心定位相關(guān)。
我一直覺得，架構(gòu)最終目標(biāo)還是解決問題的。否則沒有”架構(gòu)“這個(gè)概念的。如果只寫一個(gè)hello word那不會(huì)有這些問題。所以要正確的認(rèn)識(shí)和描述，我們的業(yè)務(wù)具體發(fā)生了什么變化，我們的業(yè)務(wù)邊界是否發(fā)生了擴(kuò)展，我們是否增加了一些業(yè)務(wù)場景。而這些變化，對(duì)我們的系統(tǒng)造成了什么問題，我們怎么進(jìn)行解決的。就體現(xiàn)了我們的架構(gòu)能力。
首先，前瞻性以及基于前瞻性判斷的架構(gòu)設(shè)計(jì)，一定是可考察的。可考察就意味著一定是有方法的。是有“套路的”。否則根本沒辦法做出一個(gè)面向未來的架構(gòu)，只能憑運(yùn)氣或者架構(gòu)演進(jìn)&維持。另外，需要大家明白一個(gè)事情：業(yè)務(wù)sense，業(yè)務(wù)前瞻性，最終還是要為架構(gòu)服務(wù)的（或許后面的戰(zhàn)略思維是不一樣的）。我從下到上分幾個(gè)方面來說：這是框架和架構(gòu)設(shè)計(jì)部分。這么多年了spring的IOC本質(zhì)發(fā)生變化了嗎？沒有。為什么？因?yàn)槭腔谖覀兒诵募軜?gòu)定位（DI，控制翻轉(zhuǎn)等）出發(fā)來定義的。這樣本質(zhì)不變，主體結(jié)構(gòu)就不變，發(fā)展就是橫向以及縱向發(fā)展的。橫向：會(huì)有更多的平臺(tái)產(chǎn)品，業(yè)務(wù)場景出現(xiàn)，但是關(guān)聯(lián)關(guān)系不變。
縱向：會(huì)有更多的前后功能延伸出現(xiàn)，但是本質(zhì)不變（比如spring做了很多的cloud）
網(wǎng)狀：關(guān)系變化，所以我們建議把“獨(dú)立”作為核心架構(gòu)原子概念，這樣關(guān)系就是另外的一個(gè)概念（半文鏈接理論）。這樣整體框架和核心架構(gòu)定位上，是不會(huì)發(fā)生變化的。業(yè)務(wù)演進(jìn)，一定還是符合互聯(lián)網(wǎng)擴(kuò)展形式的。如果我們不是做商業(yè)模式的擴(kuò)展。那么一定是原有商業(yè)模式的商業(yè)效率擴(kuò)展。比如，淘寶并沒有更改交易的本質(zhì)，營銷也是類似于傳統(tǒng)的吆喝。場地費(fèi)其實(shí)就是地皮尋租的概念。架構(gòu)師往往沒有到戰(zhàn)略視角和洞察的階段，我們需要的是在特定的業(yè)務(wù)領(lǐng)域下，判斷未來的發(fā)展方式。所以就擴(kuò)展就行，抽象定義好業(yè)務(wù)的本質(zhì)，然后結(jié)合業(yè)務(wù)發(fā)展階段進(jìn)行擴(kuò)展。比如我之前做的結(jié)算架構(gòu)，就可以按照橫向擴(kuò)展演進(jìn)的方式來進(jìn)行。因?yàn)椤敖Y(jié)算”的概念和商業(yè)資金鏈路，很早就有了。支付寶也只是把這些內(nèi)容搬到線上，然后搬到我們的收單支付配套上。所以圍繞商家，供應(yīng)鏈，供貨商，資金分賬，資金鏈路管理關(guān)系，就一定是未來的架構(gòu)演進(jìn)方向。因?yàn)楝F(xiàn)實(shí)社會(huì)中，別的企業(yè)用OA或者ERP這樣的系統(tǒng)就在做這個(gè)事情。那么沒道理支付寶內(nèi)部的結(jié)算域會(huì)有根本的變化。這里其實(shí)有個(gè)抽象，類比的一個(gè)方法，依賴我們的視野。比如我們做一個(gè)社區(qū)架構(gòu)或者業(yè)務(wù)方向判斷。整個(gè)互聯(lián)網(wǎng)社區(qū)，從最早的BBS-天涯-貼吧-校內(nèi)-微博-知乎-抖音-小紅書。等等。可以抽象定義出來不同的模式和不同的內(nèi)容載體（視頻，文字，圖片）。然后傳播從以前的單點(diǎn)-廣播-網(wǎng)狀-核心KOL。但是想想，和最早以前人們下班了之后，搬起來小板凳村口嘮嗑。沒什么本質(zhì)的區(qū)別。業(yè)務(wù)演進(jìn)部分，最終就是回歸到:架構(gòu)延續(xù)這個(gè)命題上的。基于上面我的解釋，其實(shí)就有很好的一個(gè)方法來做：架構(gòu)定位（隱喻）或者說明燈這個(gè)方法。因?yàn)闃I(yè)務(wù)本質(zhì)是不會(huì)發(fā)生變化的，所以我們圍繞架構(gòu)定位設(shè)定的核心領(lǐng)域模型，就不會(huì)發(fā)生根本的變化。除非我們的領(lǐng)域發(fā)生變化了這里主要講在設(shè)計(jì)部分體現(xiàn)的能力，如果一個(gè)架構(gòu)師在面試過程中最重要的地方，我覺得就是技術(shù)性。而這個(gè)技術(shù)性，就是我們用技術(shù)方案來解決架構(gòu)問題的一種描述。架構(gòu)能力，展開說我可以說幾十篇文章。所以我直接給一個(gè)設(shè)計(jì)方法論。相信通過我上面對(duì)于認(rèn)知的描述，大家也理解什么叫方法論。下面是我之前做的一個(gè)架構(gòu)方案的目錄。我覺得目錄就很好的體現(xiàn)了方法這個(gè)詞，因?yàn)闊o論什么架構(gòu)方案。都可以按照一定的目錄結(jié)構(gòu)來寫。
我這里說的方法論，就是我們做一個(gè)系統(tǒng)的架構(gòu)方案需要經(jīng)過的一些步驟，我們具體的產(chǎn)出物。無論是什么架構(gòu)，都可以按照一定的結(jié)構(gòu)和維度進(jìn)行分析和拆分，這種通用的方法，就是方法論部分。方法論+業(yè)務(wù)能力，就是某個(gè)領(lǐng)域，某個(gè)功能架構(gòu)能力的體現(xiàn)。我這里介紹我的常用方法：架構(gòu)定位（隱喻），業(yè)務(wù)架構(gòu)，應(yīng)用架構(gòu)。我所做的所有架構(gòu)工作，基本都是上面的三個(gè)事情。每一部分都有具體的產(chǎn)出，結(jié)合不同的業(yè)務(wù)場景我們都要運(yùn)用不同的方法。但是就像我在認(rèn)知里面說的一樣，架構(gòu)的工作也應(yīng)該是分維度和步驟的。
架構(gòu)定位是核心架構(gòu)職責(zé)，架構(gòu)上下邊界的高度抽象定義。用一種大家都覺得”理應(yīng)如此“的方式來提出。和業(yè)務(wù)概念高度相似。不同的是架構(gòu)定位還包括功能部分。比如：交易系統(tǒng)：圍繞一筆商品交易的單據(jù)，進(jìn)行不同狀態(tài)的流轉(zhuǎn)和業(yè)務(wù)參與者關(guān)系的流程組裝與驅(qū)動(dòng)。
支付系統(tǒng)：基于用戶有價(jià)資產(chǎn)償付。
商品系統(tǒng)：圍繞商業(yè)活動(dòng)中，對(duì)于物的屬性定義與管控。
賬務(wù)核心：圍繞資產(chǎn)管理與資產(chǎn)流轉(zhuǎn)驅(qū)動(dòng)。等等，我舉的例子不一定對(duì)，但是大家都會(huì)覺得有一點(diǎn)道理，有一點(diǎn)抽象，描述了是什么和做什么。如果感覺對(duì)，又不對(duì)，那么我們的架構(gòu)定位可能就設(shè)定對(duì)了。此外，我還想介紹一下我的一個(gè)理論：架構(gòu)隱喻我把這種方法叫做明燈。明燈不是方向，不是目標(biāo)，不是我們的實(shí)施路徑。但是就像黑暗之中的瑩瑩燈火，指明了我們的方向，照亮了我們的目標(biāo)，牽引著我們的道路。這種”牽引“就是明燈所帶來的核心結(jié)果，他解決了我們的架構(gòu)分層問題，平臺(tái)產(chǎn)品問題，架構(gòu)延續(xù)問題。而xp：極限編程，這本書里面的：架構(gòu)隱喻。我感覺就是明燈的一種具象化。用一種具象的概念讓大家理解我們架構(gòu)的”感覺“。比如：我們都知道什么是電商里面的交易。那么架構(gòu)隱喻就可以是：一手交錢，一手交貨。架構(gòu)定位的作用是巨大的。它指引著我們進(jìn)行架構(gòu)方案的設(shè)計(jì)，也幫助我們做架構(gòu)協(xié)同，架構(gòu)宣講，架構(gòu)延續(xù)等等內(nèi)容。同時(shí)在一些具象化的內(nèi)容也直接幫助著我們，比如核心平臺(tái)產(chǎn)品是不可能超過架構(gòu)定位的。在很多非常復(fù)雜的架構(gòu)方案里面，對(duì)架構(gòu)定位可能就討論一個(gè)多月。同時(shí)，如果沒有進(jìn)行這一步，架構(gòu)方案在進(jìn)行到某個(gè)程度的時(shí)候也一定會(huì)失敗。比如有的域進(jìn)行架構(gòu)升級(jí)，上來就分析業(yè)務(wù)場景，從來沒說要升級(jí)什么。然后直到最新方案。才隱約提出一個(gè)架構(gòu)定位。而從這個(gè)時(shí)候開始，架構(gòu)升級(jí)才艱難的進(jìn)行了下去，但是圍繞分層，又出現(xiàn)了很多問題，比如分了7層，仍然在業(yè)務(wù)推演上有問題。
這里的業(yè)務(wù)架構(gòu)，主要是描述我們怎么設(shè)計(jì)業(yè)務(wù)功能的。因?yàn)橹挥袆澐趾昧斯δ埽覀儾拍苓_(dá)到代碼復(fù)用。才能隔離風(fēng)險(xiǎn)，提高研發(fā)效能，解決復(fù)雜業(yè)務(wù)場景落地等等等的問題。業(yè)務(wù)架構(gòu)，就是描述系統(tǒng)的業(yè)務(wù)功能與職責(zé)。舉例來說，業(yè)務(wù)架構(gòu)就是描述我們具有哪些職責(zé)和功能，我們怎么和上下游分割劃分（L0）。比如交易系統(tǒng)劃分業(yè)務(wù)架構(gòu)：對(duì)上：提供下單，支付，確認(rèn)收貨，評(píng)論 等業(yè)務(wù)階段暴露
核心：交易單據(jù)，狀態(tài)流程，業(yè)務(wù)組件串聯(lián)
對(duì)下業(yè)務(wù)功能：創(chuàng)建交易，支付交易，庫存扣減，安全校驗(yàn)等等標(biāo)準(zhǔn)的方法中我采用的是三層架構(gòu)。注意這個(gè)可是和Controller，Service，Dao完全不同的概念。這三層是指：業(yè)務(wù)場景定義，平臺(tái)產(chǎn)品定義，平臺(tái)服務(wù)能力定義。寫到這里，我發(fā)現(xiàn)一個(gè)問題，我主要圍繞一個(gè)非常復(fù)雜的背景：平臺(tái)架構(gòu)，在描述我的方法。也有可能有的同學(xué)沒有處理過這樣復(fù)雜的問題，或者沒有這部分的經(jīng)驗(yàn)。首先，方法一定是相通的，能理解復(fù)雜的系統(tǒng)，沒道理做不好trade off，沒道理做不好簡單系統(tǒng)的業(yè)務(wù)劃分。此外，這是不是說明，我們做更多的事情，也更好的幫助我們自己成長。所以這并不是PUA的一種。業(yè)務(wù)場景是描述整個(gè)業(yè)務(wù)身份，我們的系統(tǒng)要處理哪些”業(yè)務(wù)“。然后這些業(yè)務(wù)是按照什么維度進(jìn)行劃分的。業(yè)務(wù)場景定義最難的地方在于”垂直拆分“的問題。即：為什么業(yè)務(wù)A和業(yè)務(wù)B是兩個(gè)業(yè)務(wù)。為什么不是一個(gè)業(yè)務(wù)。什么時(shí)候新增業(yè)務(wù)場景，如果一個(gè)業(yè)務(wù)A和業(yè)務(wù)B只有100行左右的代碼不同，怎么辦。等等這些問題。平臺(tái)產(chǎn)品是描述”非業(yè)務(wù)相關(guān)，業(yè)務(wù)通用“的。某個(gè)特定的平臺(tái)型功能聚合。提供標(biāo)準(zhǔn)的擴(kuò)展和標(biāo)準(zhǔn)的解決方案。比如”擔(dān)保交易“這是一個(gè)非常典型的平臺(tái)產(chǎn)品，淘寶，天貓都是基于這個(gè)交易鏈路來做的。平臺(tái)產(chǎn)品最難解決的是”橫向拆分“問題。比如某個(gè)功能是不是平臺(tái)產(chǎn)品功能，還是只屬于某幾個(gè)業(yè)務(wù)的功能。平臺(tái)服務(wù)能力是描述完全隔離的，獨(dú)立提供功能的代碼。注意一定是隔離的，并且獨(dú)立的。這是平臺(tái)服務(wù)的基本特性。比如一個(gè)資金轉(zhuǎn)移服務(wù)，安全校驗(yàn)服務(wù)等等。平臺(tái)服務(wù)能力最難解決的也是垂直問題。就是什么是獨(dú)立服務(wù)，什么是服務(wù)配套。這里可以展開說很多內(nèi)容，比如按照接口集成維度劃分場景，然后我們圍繞領(lǐng)域模型定義產(chǎn)品流程，這樣可以跨接口場景復(fù)用。然后我們的流程是基于領(lǐng)域模型DDD的。下游核心服務(wù)，就是我們的DB（這也是洋蔥圈架構(gòu)標(biāo)準(zhǔn)定義）。所以我們把DB的操作定義成原子服務(wù)。這是一個(gè)非常簡單場景。但是如果我們是這樣思考和設(shè)計(jì)的。那么我相信這就是一個(gè)架構(gòu)師的能力標(biāo)準(zhǔn)。業(yè)務(wù)架構(gòu)還包括一些核心內(nèi)容，比如：核心領(lǐng)域模型，核心業(yè)務(wù)流程等內(nèi)容。這些都是在具體實(shí)踐中。我們進(jìn)行一些關(guān)鍵設(shè)計(jì)。
應(yīng)用架構(gòu)，就是解決我們業(yè)務(wù)架構(gòu)然后代碼落地的問題。就是如何用代碼實(shí)現(xiàn)我們的業(yè)務(wù)架構(gòu)中的業(yè)務(wù)功能，如何組織我們的代碼，如何按照模塊進(jìn)行劃分。比如我理解的典型洋蔥圈架構(gòu)，就是一種應(yīng)用架構(gòu)方法論。因?yàn)檫@里涉及到了DB。DB是具體技術(shù)的概念。在業(yè)務(wù)架構(gòu)中是不會(huì)出現(xiàn)具體技術(shù)的。比如”支付“是業(yè)務(wù)功能。這個(gè)功能甚至都不會(huì)是java來實(shí)現(xiàn)的。下游可能是一個(gè)系統(tǒng)。這里就是區(qū)分。應(yīng)用架構(gòu)是包含關(guān)鍵技術(shù)架構(gòu)的。因?yàn)閼?yīng)用架構(gòu)關(guān)注與“實(shí)現(xiàn)”層面的事情。我的架構(gòu)經(jīng)驗(yàn)比較復(fù)雜，這里不詳細(xì)展開了。主要是兩個(gè)框架：DSL框架和擴(kuò)展引擎框架。我這里就介紹一種方案：基于不同業(yè)務(wù)場景擴(kuò)展參數(shù)組合+workflow復(fù)用的架構(gòu)。這是一種非常簡單的代碼組織方式，大部分系統(tǒng)都是用這種架構(gòu)方式的。核心就是基于功能action。然后業(yè)務(wù)中用到五個(gè)功能，就把五個(gè)action串聯(lián)起來就行了。
在業(yè)務(wù)發(fā)展判斷（前瞻性）里面，我描述了我們的業(yè)務(wù)能力，業(yè)務(wù)sense怎么提升。但是，我想說明的是，作為架構(gòu)師，我們的業(yè)務(wù)能力，最終還是為架構(gòu)服務(wù)的。當(dāng)然了，繼續(xù)往下個(gè)階段，就不一定了，因?yàn)榻鉀Q問題的手段不僅僅是“架構(gòu)”這一個(gè)手段了。基于我們對(duì)業(yè)務(wù)發(fā)展的判斷，我們框架部分的靈活擴(kuò)展設(shè)計(jì)。是否就能保證我們的架構(gòu)核心延續(xù)下去呢？其實(shí)我覺得還不夠。因?yàn)榧軜?gòu)延續(xù)，不僅僅是能完成業(yè)務(wù)功能。同時(shí)還需要保證我們的核心領(lǐng)域模型，架構(gòu)分層，核心架構(gòu)概念，技術(shù)風(fēng)險(xiǎn)，研發(fā)效能。這些部分能夠持續(xù)不斷的演進(jìn)，不說變好，至少?zèng)]有那么快的變壞。相信這個(gè)問題都有感覺，因?yàn)橐粋€(gè)5年左右的系統(tǒng)，代碼經(jīng)常被稱之為“屎山”。我們經(jīng)常戲稱我們的工作就是屎上雕花。那么怎么能夠做到架構(gòu)延續(xù)呢？我從一個(gè)比較感性的角度來說明這個(gè)問題：架構(gòu)隱喻這是我在XP極限編程里面學(xué)習(xí)到的一個(gè)概念，里面很多內(nèi)容我并不能贊同。但是這個(gè)核心方法我還是保留了下來，然后結(jié)合我的工作進(jìn)一步的解釋和落地。另外，我是一個(gè)絕對(duì)的“英雄主義史觀“。在我看來，所有的制度，流程，業(yè)務(wù)設(shè)計(jì)，架構(gòu)設(shè)計(jì)。最終都取決于人這個(gè)因素。我們沒辦法很好的限制人，我們只能按照”感性“的維度，去引導(dǎo)大家。架構(gòu)隱喻，就是一種具象化的，感性化的。讓相關(guān)同學(xué)都能理解和明白相關(guān)架構(gòu)定位和發(fā)展方向的”感覺“。依托這種感覺，我會(huì)不斷的進(jìn)行我們的架構(gòu)迭代。朝著我們的目標(biāo)方向發(fā)展。好的架構(gòu)一定是延續(xù)的。下面我還會(huì)講一些具體的方法和拆分的維度，但是這個(gè)是屬于頂層概念。一定是基于”架構(gòu)隱喻“才能讓大家保證執(zhí)行不出差的。否則無論是什么方法，只要提出了，都還需要解答另外一個(gè)問題：如何保證別人落地的過程中和你想的不出現(xiàn)gap？在具體的架構(gòu)延續(xù)方法上，還會(huì)分幾個(gè)部分（上面也說了）。我們的架構(gòu)設(shè)計(jì)，一定是圍繞核心領(lǐng)域模型來的，基于我們的判斷設(shè)定的。如果核心領(lǐng)域模型需要發(fā)生變化。那么就是另外的一次架構(gòu)升級(jí)，這個(gè)時(shí)候往往是翻天覆地。所以盡量保證核心領(lǐng)域模型不變，即地基不變。明白核心領(lǐng)域模型之后，思考我們的架構(gòu)分層，在分層上可以做到內(nèi)容的橫向擴(kuò)展，而不是分層擴(kuò)展。比如我們設(shè)計(jì)了平臺(tái)產(chǎn)品，盡量進(jìn)行平臺(tái)產(chǎn)品的多樣性，可以自由組合設(shè)定，而不要再把平臺(tái)產(chǎn)品抽象成一些所謂的前臺(tái)產(chǎn)品，后臺(tái)產(chǎn)品。因?yàn)橥谩倍嗉右粚印暗氖侄危ソ鉀Q業(yè)務(wù)問題的時(shí)候。是得不償失的。我們往往可以通過多加一層的手段去解決技術(shù)問題。比如ACL，這種防腐層的設(shè)計(jì)，在業(yè)務(wù)語義上面沒有任何的變化，這種就是純技術(shù)適配，還有比如各種場景識(shí)別，不同的API（http，RPC，消息）的接入層。如果是加分層的手段是解決業(yè)務(wù)問題，往往不行，比如業(yè)務(wù)層這個(gè)概念。我們很容易拆分出 業(yè)務(wù)場景層，業(yè)務(wù)流程層。但是這又有什么意義呢。還是要增加很多很多的概念去解釋怎么劃分這兩層。（半文鏈接理論）所以?架構(gòu)敏捷度=處理問題個(gè)數(shù)/架構(gòu)概念個(gè)數(shù)。我們盡量保證的是概念更少，而不是更多。這個(gè)會(huì)和trade off來說明。我一直認(rèn)為，架構(gòu)是一定一定不能解決所有問題的。所以不要反人性的去阻止大家寫特殊的if。而是能夠讓大家不寫if（更簡單），獨(dú)立寫if。這個(gè)就是擴(kuò)展引擎部分。如果業(yè)務(wù)不發(fā)展，那么根本不用架構(gòu)。當(dāng)下的代碼就可以用，為什么要設(shè)計(jì)架構(gòu)呢？所以架構(gòu)一定要解決未來的問題，那么架構(gòu)就不能全解決當(dāng)下的問題。那么當(dāng)下的問題全解決是否可以呢？也不行，因?yàn)橛械臉I(yè)務(wù)不發(fā)展了，那就也不用解決。有的問題還在發(fā)展，首先要解決的是發(fā)展，有的ROI很低等等。上面說明了。架構(gòu)一定是要trade off的。沒有銀彈，需要面向未來。就一定容忍我們當(dāng)下的一些妥協(xié)。這也是我一直說的：做不做架構(gòu)升級(jí)需要很保守，架構(gòu)升級(jí)方案需要很積極。在實(shí)踐過程中，上面兩個(gè)事情最終決策的人往往是同一個(gè)，所以架構(gòu)升級(jí)往往不如人意。（不能又保守，又激進(jìn)）在接受了架構(gòu)需要trade off之后，其實(shí)我們面對(duì)的大部分是”多少“的問題。比如有100個(gè)問題。我們能容忍21個(gè)？還是22個(gè)。這也是我在架構(gòu)發(fā)展階段里面說的”“共識(shí)”問題。這就需要結(jié)合不同的業(yè)務(wù)場景和當(dāng)前業(yè)務(wù)階段來定義了。我能給出的方法是：基于架構(gòu)定位，設(shè)定架構(gòu)目標(biāo)。設(shè)定核心問題，核心問題必須解決。其他的其實(shí)都不影響主體架構(gòu)。這也是一個(gè)完整的架構(gòu)方案里面，需要體現(xiàn)架構(gòu)目標(biāo)的原因。需求迭代流程，代碼研發(fā)流程，系分流程，穩(wěn)定性保證機(jī)制等等。通用技術(shù)方案（包含設(shè)計(jì)）
這里就是通用的技術(shù)方案，這個(gè)和業(yè)務(wù)無關(guān)，但是又有別于標(biāo)準(zhǔn)的框架知識(shí)。是一些常見下的標(biāo)準(zhǔn)技術(shù)解決方案，比如分布式事務(wù)，多活等。這些特定問題的解決方案。我這里羅列一下，大家可以去了解一下
這里是純技術(shù)，需要每個(gè)都非常了解：
ldc
分庫分表
高并發(fā)拆分
集群
多活&熱備
分布式鎖
唯一性管控
這里講的是類似設(shè)計(jì)模式，用一些通用設(shè)計(jì)方案，解決我們遇到的問題acl
執(zhí)行模板
流程式
多策略
流程化
AOP
設(shè)計(jì)模式
為什么在能力里面沒有介紹純技術(shù),技術(shù)框架呢?因?yàn)楦呒?jí)開發(fā)就應(yīng)該達(dá)到了。如果這個(gè)文章對(duì)你有幫助，不要忘記?「在看」?「點(diǎn)贊」?「收藏」?三連啊喂！
