????本文分享阿里資深技術(shù)專家六銖的架構(gòu)方法論，這套方法論中包含了詳細(xì)的架構(gòu)推導(dǎo)邏輯，希望能夠幫助大家在工作中從各個(gè)粒度、各個(gè)層次來(lái)做好架構(gòu)工作。較長(zhǎng)，同學(xué)們可先收藏再看。

一、背景

1.1 架構(gòu)中的問(wèn)題識(shí)別

需求分析，架構(gòu)實(shí)現(xiàn)，(新需求，架構(gòu)改動(dòng))* n = 推倒重來(lái)。

這個(gè)過(guò)程是一個(gè)循環(huán)往復(fù)的過(guò)程，有的產(chǎn)品每年都會(huì)推倒重來(lái)一次。

而這個(gè)過(guò)程是如何造成的呢?原因之一是每次迭代過(guò)程中都沒(méi)有用正確的架構(gòu)方法來(lái)進(jìn)行迭代造成的，就像在歪樓上繼續(xù)加蓋樓層一樣，最終還是會(huì)倒塌(不過(guò)這個(gè)原因并不是唯一的原因，其他原因留到后續(xù)文章中闡述)。

這真是一個(gè)悲傷的故事，但是又是一個(gè)時(shí)常發(fā)生的故事。或者說(shuō)我們大多數(shù)人都經(jīng)歷過(guò)的場(chǎng)景。

要解決這個(gè)問(wèn)題，那就需要在每次迭代中，都需要用正確的姿勢(shì)對(duì)不對(duì)?要用對(duì)姿勢(shì)其中有一個(gè)重要的原因是架構(gòu)。就像一幢大樓，架構(gòu)設(shè)計(jì)得越有問(wèn)題，這幢大樓被重造的可能性就越大。

這里正確的姿勢(shì)到底是什么姿勢(shì)?接下來(lái)本文會(huì)闡述一整套架構(gòu)方法論，該方法論中包含了詳細(xì)的架構(gòu)推導(dǎo)邏輯，幫助我們?cè)诠ぷ髦性诟鱾€(gè)粒度，各個(gè)層次做好架構(gòu)工作。

我們后續(xù)的文章中將會(huì)著重闡述如何通過(guò)自底向上以及自頂向下的兩種架構(gòu)思考方式來(lái)解決這些問(wèn)題，但是在那之前，我們還是先來(lái)聊聊什么叫“架構(gòu)”。

1.2 什么是架構(gòu)?

大概是在 11 年前左右，在土豆網(wǎng)做廣告平臺(tái)，同時(shí)也做視頻 CDN 的相關(guān)事情，當(dāng)時(shí)做一個(gè)服務(wù)，基礎(chǔ)架構(gòu)是 lighttpd + squid + tomcat，將靜態(tài)資源分離到 httpd，get 請(qǐng)求使用 squid 緩存，智能路由使用 HTTP post 請(qǐng)求，并讓 tomcat 提供服務(wù)，當(dāng)時(shí)就覺(jué)得這就是架構(gòu)。再后來(lái)，做了視頻 CDN 相關(guān)的基礎(chǔ)建設(shè)的工作，就覺(jué)得這就是做架構(gòu)，關(guān)鍵那個(gè)時(shí)候也沒(méi)有人告訴我們什么架構(gòu)，自己不知道自己不知道。

再后來(lái)慢慢成長(zhǎng)，又去做了幾年中間件(包括高性能 RPC 和 JSR-170)，然后就覺(jué)得這也是做架構(gòu)。當(dāng)時(shí)也沒(méi)有前輩跟我講什么是架構(gòu)，那個(gè)時(shí)候的我對(duì)架構(gòu)是沒(méi)有體系化認(rèn)知的，都是憑著感覺(jué)做的，是不知道自己不知道。

再后來(lái)，來(lái)到了阿里做應(yīng)用研發(fā)和架構(gòu)了，發(fā)現(xiàn)業(yè)務(wù)開(kāi)發(fā)中也包含了各種方法論，而以前看過(guò)的建模相關(guān)的資料，在中間件等基礎(chǔ)設(shè)施上也沒(méi)有太大的感覺(jué)，反而在業(yè)務(wù)技術(shù)領(lǐng)域發(fā)揮出了巨大的光芒。也發(fā)現(xiàn)越靠近用戶的架構(gòu)，隨著企業(yè)的慢慢壯大會(huì)變得越來(lái)越重要。這個(gè)時(shí)候的我對(duì)架構(gòu)認(rèn)知是知道自己不知道了。

既然知道自己不知道了，那么就是要追尋它，曾經(jīng)我和不少業(yè)務(wù)的研發(fā)同學(xué)討論過(guò)架構(gòu)是什么，撇去基礎(chǔ)設(shè)施架構(gòu)和物理架構(gòu)等視角不談(這些視角聊起來(lái)也是篇幅很長(zhǎng)的)，我挑應(yīng)用邏輯架構(gòu)并從幾個(gè)角度來(lái)嘗試描述一下：

1)從架構(gòu)的總原則的角度：盡可能簡(jiǎn)單(在當(dāng)前場(chǎng)景下要盡可能簡(jiǎn)單便于擴(kuò)展和維護(hù))，但是不能太簡(jiǎn)單(相對(duì)而言太過(guò)于簡(jiǎn)單可能在場(chǎng)景上有所遺漏).

2)從架構(gòu)的目的角度來(lái)考慮：既要解決過(guò)去的問(wèn)題，也要解決現(xiàn)在的問(wèn)題，還能適度解決未來(lái)的問(wèn)題，這些問(wèn)題既包含技術(shù)問(wèn)題，更包含業(yè)務(wù)問(wèn)題。

3)從形態(tài)之 2 維的角度來(lái)考慮：架構(gòu)就是橫的問(wèn)題，和豎的問(wèn)題。橫就是分層，豎就是分區(qū)，橫豎都有抽象的事情要做。

4)從形態(tài)之 3 維的角度來(lái)考慮：架構(gòu)是三維的，在 x 軸和 y 軸上有橫豎的問(wèn)題，在z軸上還有粒度的問(wèn)題。

5)從時(shí)間軸的角度來(lái)考慮：架構(gòu)不是一層不變的，是隨著業(yè)務(wù)的發(fā)展在不斷變化的。

可以看出，雖然我試圖從以上幾個(gè)視角對(duì)架構(gòu)進(jìn)行了描述，但是顯然這些描述都是見(jiàn)仁見(jiàn)智的觀點(diǎn)，是從某個(gè)角度來(lái)看架構(gòu)。內(nèi)心里我覺(jué)得自己提煉的高度是不夠的，實(shí)踐中的總結(jié)必須和業(yè)界的知識(shí)結(jié)合起來(lái)，我必須學(xué)習(xí)前人已經(jīng)總結(jié)的體系。于是在不斷的搜集資料的過(guò)程中，我發(fā)現(xiàn)在 ISO/IEC 42010:20072 中對(duì)架構(gòu)有如下定義：

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

??

這個(gè)最頂層抽象我個(gè)人覺(jué)得非常到位，根據(jù)這個(gè)定義，顯然，我們?cè)诩軜?gòu)中需要：

• 職責(zé)明確的模塊或者組件
• 組件直接的關(guān)聯(lián)關(guān)系非常明確
• 需要有約束和指導(dǎo)原則

這個(gè)架構(gòu)的定義很簡(jiǎn)練，很實(shí)在。小到一個(gè)玩具，大到一個(gè)國(guó)家的運(yùn)作都可以隱含著這樣的內(nèi)容。

但這是一個(gè)廣義上定義的架構(gòu)，經(jīng)過(guò)一些總結(jié)思考，我覺(jué)得實(shí)際上具體到我們?nèi)粘５墓ぷ髦?，在不同的層次，?huì)有更加精細(xì)化的架構(gòu)分類。

1.3 架構(gòu)有哪些分類

在工作中我遇到不同職位的人從不同的角度來(lái)描述架構(gòu)，但是我們鮮有能達(dá)成共識(shí)的，剛開(kāi)始我也不知道為啥討論不到一塊去，后來(lái)經(jīng)過(guò)一段時(shí)間的糾結(jié)和深入仔細(xì)的思考后，我發(fā)現(xiàn)很多時(shí)候大家描述的架構(gòu)都不是同一個(gè)角度的東西，于是我嘗試從如下幾個(gè)角度劃分架構(gòu)的類別，以幫助我們?cè)诓煌膱?chǎng)景和不同的人聊天時(shí)大家可以聚焦，明確我們到底是在討論哪種架構(gòu)，以提升溝通效率，并盡快達(dá)成共識(shí)，目前這個(gè)劃分已經(jīng)在我們團(tuán)隊(duì)基本達(dá)成共識(shí)。

值得注意的是，不管下面哪種分類的架構(gòu)，都符合上一節(jié)總的架構(gòu)的定義：模塊(組件)+ 關(guān)系 + 約束 & 原則。

1. 產(chǎn)品功能架構(gòu)

這個(gè)是產(chǎn)品經(jīng)理最喜歡講的架構(gòu)，一般來(lái)說(shuō)，講我們有什么功能的時(shí)候，產(chǎn)品功能架構(gòu)描述的是能做什么，受眾群體一般是使用產(chǎn)品的同學(xué)。如果我們做軟件設(shè)計(jì)時(shí)，不應(yīng)該產(chǎn)出這玩意，而是應(yīng)該產(chǎn)出應(yīng)用邏輯架構(gòu)和應(yīng)用物理架構(gòu)。但是一旦我們要對(duì)外宣講我們的產(chǎn)品，比如我們的接口有啥用，應(yīng)該怎么用，這個(gè)時(shí)候我們講的應(yīng)該是產(chǎn)品功能架構(gòu)。

• 目的：指導(dǎo)用戶使用產(chǎn)品，所以模塊的聚合是從用戶視角出發(fā)的
• 受眾：使用產(chǎn)品的人
• 包含的內(nèi)容：闡述產(chǎn)品功能模塊的能力：比如一輛汽車，方向盤(pán)有什么功能，方向盤(pán)的按鈕上各區(qū)域的功能是什么，儀表盤(pán)分成哪些功能模塊，每個(gè)功能模塊有什么作用，油門踏板有什么作用，剎車踏板有什么作用。但是也不排除有些高階用戶需要明確知道變速箱的齒比等信息，所以在產(chǎn)品功能架構(gòu)圖上也可以描繪出來(lái)。
• 命名：這里命名需要考慮如何取一個(gè)吸引人的名字(同時(shí)又能表達(dá)產(chǎn)品的能力)來(lái)吸引我們的用戶前來(lái)使用，比如說(shuō)以前經(jīng)常有產(chǎn)品套用“納米”，又有產(chǎn)品套用“綠色”等等。

2. 業(yè)務(wù)能力架構(gòu)

用來(lái)分析業(yè)務(wù)，業(yè)務(wù)概念架構(gòu)是指擁有哪些業(yè)務(wù)模塊，且各自的能力是什么，這張圖有助于我們分析和理解業(yè)務(wù)需求，也有利于產(chǎn)品經(jīng)理分析業(yè)務(wù)。所以業(yè)務(wù)概念架構(gòu)和業(yè)務(wù)概念模型都是用在分析階段。

• 目的：研發(fā)人員和業(yè)務(wù)人員理解業(yè)務(wù)內(nèi)在的概念和聯(lián)系。
• 受眾：研發(fā)人員和業(yè)務(wù)人員，主要是給規(guī)劃業(yè)務(wù)的人使用。
• 包含的內(nèi)容：業(yè)務(wù)能力，能力中的子能力。

3. 應(yīng)用邏輯架構(gòu)

軟件設(shè)計(jì)本身，模塊，粒度，職責(zé)，復(fù)用，等等，在講解軟件設(shè)計(jì)的時(shí)候，使用的是這個(gè)架構(gòu)圖，這個(gè)架構(gòu)圖是通過(guò)系統(tǒng)模型和業(yè)務(wù)概念架構(gòu)推導(dǎo)而來(lái)。所以系統(tǒng)模型和應(yīng)用邏輯架構(gòu)都是用在軟件設(shè)計(jì)階段。

• 目的：指導(dǎo)軟件的研發(fā)。
• 受眾：研發(fā)人員，各層級(jí)架構(gòu)師，各層級(jí)技術(shù)管理者。
• 包含的內(nèi)容：闡述架構(gòu)中各模塊的職責(zé)：如系統(tǒng)模型，技術(shù)模塊，技術(shù)模塊的關(guān)系，技術(shù)模塊的核心抽象，如何用設(shè)計(jì)模式來(lái)讓架構(gòu)符合軟件設(shè)計(jì)原則，等等。如果拿汽車舉例，那就是發(fā)動(dòng)機(jī)模塊中包含了哪些子模塊(活塞，曲軸，連桿，缸體，缸蓋，等等)發(fā)動(dòng)機(jī)模塊和變速箱模塊之間的關(guān)聯(lián)關(guān)系是什么，如何協(xié)同工作，和底盤(pán)的關(guān)聯(lián)關(guān)系是什么，如何協(xié)同工作。發(fā)動(dòng)機(jī)，底盤(pán)，變速箱，電子系統(tǒng)在整輛汽車中的職責(zé)，關(guān)系，約束是什么。這些都是用來(lái)指導(dǎo)汽車研發(fā)的。而不是指導(dǎo)用戶如何使用這輛汽車的。
• 命名：這里的命名需要樸實(shí)無(wú)華，精準(zhǔn)的描述出職責(zé)，華而不實(shí)反而讓技術(shù)的同學(xué)無(wú)法理解這到底是什么玩意，導(dǎo)致實(shí)施的時(shí)候職責(zé)放錯(cuò)地方，挖下大坑讓后人來(lái)填。

4. 應(yīng)用物理(部署)架構(gòu)

軟件部署時(shí)的架構(gòu)，這張圖推導(dǎo)自應(yīng)用邏輯架構(gòu)，推導(dǎo)時(shí)重點(diǎn)邏輯架構(gòu)如何落地，比如使用何種微服務(wù)容器，邏輯架構(gòu)的模塊落地時(shí)應(yīng)該是 package，還是應(yīng)用，也有可能是一組應(yīng)用，是不是要跨機(jī)房部署，甚至跨國(guó)部署等等。還需要考慮穩(wěn)定性，性能，成本等話題。

5. 基礎(chǔ)設(shè)施架構(gòu)

選擇什么樣的中間件，存儲(chǔ)，監(jiān)控，報(bào)警，等等。

6. 等等

1.4 能力和職責(zé)的區(qū)別

在日常的架構(gòu)討論中，有的同學(xué)經(jīng)常談架構(gòu)的能力，有的同學(xué)經(jīng)常談架構(gòu)的職責(zé)，那么能力和職責(zé)有什么區(qū)別?跟產(chǎn)品的同學(xué)打交道多了之后，發(fā)現(xiàn)產(chǎn)品同學(xué)很多都是講能力，后來(lái)技術(shù)的同學(xué)也開(kāi)始講能力，而通常我們架構(gòu)的同學(xué)原來(lái)講的都是職責(zé)，兩者有什么區(qū)別呢，我說(shuō)說(shuō)自己的理解：

1. 能力(產(chǎn)品功能模塊的能力)

是指一個(gè)產(chǎn)品能做什么，比如中臺(tái)本身是一個(gè)產(chǎn)品，對(duì)使用中臺(tái)的同學(xué)來(lái)說(shuō)，我們應(yīng)該講中臺(tái)的能力(其實(shí)是在講中臺(tái)這個(gè)產(chǎn)品的能力)。所以講能力是講給架構(gòu)的使用者或者其他想了解的人來(lái)聽(tīng)的。

2. 職責(zé)(邏輯架構(gòu)中各模塊的職責(zé))

是指架構(gòu)內(nèi)模塊的職責(zé)，用來(lái)指導(dǎo)開(kāi)發(fā)，比如中臺(tái)研發(fā)的同學(xué)，應(yīng)該講架構(gòu)的職責(zé)，依賴，約束。所以講職責(zé)是講給研發(fā)的同學(xué)，講給域內(nèi)的架構(gòu)師，講給域內(nèi)的管理者來(lái)聽(tīng)的，總的來(lái)說(shuō)就是講給架構(gòu)的實(shí)現(xiàn)者來(lái)說(shuō)的。

簡(jiǎn)單來(lái)說(shuō)就是：能力是指產(chǎn)品的能力，職責(zé)是指架構(gòu)內(nèi)部的職責(zé)。如果架構(gòu)本身也是一個(gè)產(chǎn)品需對(duì)外輸出(如中臺(tái)，或者其他技術(shù)框架作為產(chǎn)品輸出)，則對(duì)外輸出時(shí)，我們應(yīng)該講這個(gè)技術(shù)產(chǎn)品的能力(這個(gè)時(shí)候技術(shù)的同學(xué)也就開(kāi)始講能力了)。所以當(dāng)我們討論問(wèn)題的時(shí)候，如果有的人在談產(chǎn)品能力，有人在談架構(gòu)內(nèi)部職責(zé)，那么顯然已經(jīng)不是在討論同一個(gè)話題了，請(qǐng)大家務(wù)必注意區(qū)分這種情況，差之毫厘，謬以千里，雞同鴨講啊。

比如說(shuō)兩個(gè)模塊 A 和 B，職責(zé)不一樣，但是依賴了相同的二方庫(kù)。那我們不能說(shuō)某個(gè)職責(zé)在這個(gè)二方庫(kù)里。這個(gè)二方庫(kù)作為某個(gè)獨(dú)立的技術(shù)小產(chǎn)品，提供了某些能力。但是履行職責(zé)的還是 A 模塊或者 B 模塊。

1.5 應(yīng)用邏輯架構(gòu)的地位

正如前面我們描述的架構(gòu)分類所描述，有些架構(gòu)和具體業(yè)務(wù)是無(wú)關(guān)的，有些架構(gòu)是和具體業(yè)務(wù)息息相關(guān)的，比如說(shuō)應(yīng)用邏輯架構(gòu)就是和業(yè)務(wù)息息相關(guān)，它來(lái)源于業(yè)務(wù)的抽象，甚至我們可以說(shuō)：它是業(yè)務(wù)線技術(shù)架構(gòu)設(shè)計(jì)中第一份產(chǎn)出。

既然他是首要的產(chǎn)出，我們就必須要考慮應(yīng)用邏輯架構(gòu)中應(yīng)該包含的三類主題：

? 模塊

? 依賴

? 約束

絕大部分的架構(gòu)問(wèn)題都可以歸納成這三類主題，這些主題包含哪些內(nèi)容呢?這就是本文接下來(lái)要介紹的內(nèi)容，應(yīng)用邏輯架構(gòu)的設(shè)計(jì)不需要拍腦袋，是通過(guò)科學(xué)的方法體系推導(dǎo)出來(lái)的。

二、架構(gòu)的兩種推導(dǎo)思路

架構(gòu)的產(chǎn)出總的來(lái)說(shuō)有兩種方式，一種是自頂向下的方式來(lái)推導(dǎo)架構(gòu)，一種是自底向上的推導(dǎo)方式，而且兩種方式往往是相互結(jié)合來(lái)產(chǎn)出最合適的結(jié)果。而在業(yè)務(wù)線的同學(xué)，可能接觸最多的是自底向上的推導(dǎo)的方式，自底向上的推導(dǎo)的方式也是本文中要重點(diǎn)講解的架構(gòu)推導(dǎo)方式。

2.1 自頂向下的架構(gòu)推導(dǎo)

自頂向下的推導(dǎo)的關(guān)鍵問(wèn)題在問(wèn)題定義，如果問(wèn)題沒(méi)有被準(zhǔn)確的定義，那么自頂向下就無(wú)法推導(dǎo)出正確的結(jié)果。假設(shè)問(wèn)題被準(zhǔn)確的定義了，如何自頂向下推導(dǎo)呢?

2.2 自底向上的架構(gòu)推導(dǎo)

我們?cè)跇I(yè)務(wù)線做開(kāi)發(fā)的同學(xué)，每天肯定跟很多需求打交道，這些需求哪里來(lái)的?基本上有這三種產(chǎn)出：

1. 有些是來(lái)自產(chǎn)品方一拍腦袋產(chǎn)生的靈感
2. 有些是對(duì)數(shù)據(jù)進(jìn)行了詳細(xì)的分析產(chǎn)出的產(chǎn)品策略
3. 有些是當(dāng)前產(chǎn)品中暴露的一個(gè)個(gè)問(wèn)題

產(chǎn)品方的這些詳細(xì)的需求來(lái)了之后，我們是如何應(yīng)對(duì)的呢?我們首先和產(chǎn)品方一起討論產(chǎn)品方案的合理性，在產(chǎn)品方案合理的基礎(chǔ)上，我們來(lái)開(kāi)始識(shí)別用例，開(kāi)始了一系列軟件工程領(lǐng)域方面的措施。其整體過(guò)程如下圖所示：

??

自底向上推導(dǎo)邏輯架構(gòu)就是最右邊代表的那條曲線。

這里基本上就是本文接下來(lái)要重點(diǎn)闡述的：如何自底向上推導(dǎo)應(yīng)用邏輯架構(gòu)，這個(gè)過(guò)程就是一個(gè)抽象和架構(gòu)的過(guò)程。

那么我們從整體方法論的介紹開(kāi)始，采用總分總的結(jié)構(gòu)，下面這張圖就是應(yīng)用邏輯架構(gòu)自底向上的推導(dǎo)路徑，這個(gè)推導(dǎo)路徑是有序的，每個(gè)步驟都包含了大量的操作技巧，前一步做好，后一步才有可能得出正確的結(jié)果。

??

這張圖中有幾個(gè)重點(diǎn)：

1)軟件研發(fā)分成了兩個(gè)階段：

• 分析階段，也是我們常說(shuō)的問(wèn)題空間領(lǐng)域建模，關(guān)鍵的一步是業(yè)務(wù)概念模型的輸出，而業(yè)務(wù)概念模型輸出的前置條件是從需求中分解出合理的用例集合。
• 設(shè)計(jì)階段，也是我們常說(shuō)的解決方案空間建模，以及應(yīng)用邏輯架構(gòu)。

2)圖中存在了箭頭這個(gè)東西，說(shuō)明了我們做架構(gòu)推導(dǎo)的主要的思維路徑，也說(shuō)明做架構(gòu)不需要拍腦袋，都是根據(jù)嚴(yán)密的邏輯推導(dǎo)出來(lái)的。

這個(gè)嚴(yán)密邏輯基本是一個(gè)自底向上的推導(dǎo)過(guò)程，底層的模型是通過(guò)建模方法演繹出來(lái)，邏輯架構(gòu)中的各個(gè)模塊是通過(guò)歸納的方法推導(dǎo)出來(lái)。那么：

• 什么地方應(yīng)該用演繹，什么地方應(yīng)該用歸納呢?
• 使用演繹的時(shí)候應(yīng)該使用何種具體方法呢?
• 使用歸納的時(shí)候應(yīng)該使用何種具體方法呢?

我們?cè)倭粢粋€(gè)懸念，后面再講。

不管是演繹還是歸納，都是抽象工作的一部分，而且都需要素材，這里的素材就是我們對(duì)需求，對(duì)業(yè)務(wù)的理解，以及對(duì)技術(shù)的深度廣度的把握。沒(méi)有素材，方法論掌握再好也得不出結(jié)果。

素材哪里來(lái)呢?

業(yè)務(wù)素材的來(lái)源大部分是你需要解決問(wèn)題所在的領(lǐng)域，比如我們?cè)陔娚填I(lǐng)域，那么我們就要多搜集電商領(lǐng)域的業(yè)務(wù)知識(shí)。如果我們?cè)跀?shù)據(jù)領(lǐng)域，自然要多搜集數(shù)據(jù)業(yè)務(wù)的相關(guān)知識(shí)，以及我們前文中講到的技術(shù)類的相關(guān)知識(shí)。

而技術(shù)素材是要求我們?cè)诩夹g(shù)領(lǐng)域不斷的鉆研，不斷的擴(kuò)展邊界，深度不斷增加，廣度也不斷增加。所以對(duì)于架構(gòu)師來(lái)說(shuō)計(jì)算機(jī)科學(xué)與技術(shù)是絕對(duì)要不斷精進(jìn)的。

2.3 兩個(gè)方法的區(qū)別

自頂向下推導(dǎo)的一個(gè)前置條件就是你需要知道豬長(zhǎng)什么樣，在架構(gòu)上就是你需要知道這個(gè)架構(gòu)的原來(lái)是是什么樣子的，解決什么問(wèn)題的。如果都不知道豬長(zhǎng)什么樣，那么就無(wú)從判斷豬是不是適合當(dāng)寵物了。此處需要有一定的業(yè)務(wù)領(lǐng)域理解力和領(lǐng)域經(jīng)驗(yàn)(包含：客戶的問(wèn)題和痛點(diǎn)是什么，怎么分析出來(lái)的，當(dāng)前的架構(gòu)方案是什么，當(dāng)前的架構(gòu)方案是如何解決這個(gè)問(wèn)題的，未來(lái)的架構(gòu)方案如何更好的解決這個(gè)問(wèn)題)。

而自底向上推導(dǎo)則沒(méi)有這個(gè)問(wèn)題，因?yàn)槭强粗i來(lái)做推導(dǎo)的，知道豬的細(xì)節(jié)，這個(gè)細(xì)節(jié)的特點(diǎn)如何演繹，如何歸納，最后得出結(jié)論。

所以當(dāng)我們不熟悉一個(gè)大的業(yè)務(wù)的時(shí)候，我們自頂向下推導(dǎo)架構(gòu)的難度是極大的，幾乎不能完成。不了解業(yè)務(wù)或技術(shù)情況時(shí)定義出來(lái)的問(wèn)題也未必是一個(gè)被正確定義的問(wèn)題，容易給人造成一個(gè)印象：瞎指揮。

這個(gè)時(shí)候如何在沒(méi)有知識(shí)背景的情況下快速落地就得自底向上的來(lái)推導(dǎo)架構(gòu)。在自底向上的過(guò)程中慢慢熟悉業(yè)務(wù)。

但是如果工作中每每都是純粹的自底向上的推導(dǎo)架構(gòu)，是無(wú)法幫助我們來(lái)做技術(shù)的前瞻性布局的，此時(shí)架構(gòu)師的成長(zhǎng)就遇到的瓶頸，所以此時(shí)又要使用自頂向下的架構(gòu)推導(dǎo)方式。

綜上所述，不管是自底向上，還是自頂向下，都是架構(gòu)師需要掌握的技能。

三、自底向上的架構(gòu)方法：業(yè)務(wù)概念架構(gòu)推導(dǎo)

這部分內(nèi)容，我在 ICBU，村淘，一達(dá)通，菜鳥(niǎo)，AE 現(xiàn)場(chǎng)分享過(guò)。尤其是在 AE，一達(dá)通和菜鳥(niǎo)，相關(guān)的同學(xué)都拿出了當(dāng)時(shí)的糾結(jié)大家很久的難題，我們一起使用了這樣的方法很快就分析出了業(yè)務(wù)概念模型，并且對(duì)模塊進(jìn)行了簡(jiǎn)要的劃分，形成概要的業(yè)務(wù)概念架構(gòu)。經(jīng)過(guò)大量的實(shí)戰(zhàn)，效果是非常明顯的。

3.1 模型的 3 個(gè)層次

??

在這里，我把一些常見(jiàn)的概念集中起來(lái)，便于大家統(tǒng)一概念：

1)業(yè)務(wù)概念模型，問(wèn)題空間領(lǐng)域模型，信息模型是同樣的意思，這個(gè)層次上的實(shí)體我們稱之為概念實(shí)體，這部分內(nèi)容是用在需求和業(yè)務(wù)分析上的，討論業(yè)務(wù)概念模型時(shí)完全不需要考慮軟件的實(shí)現(xiàn)，這個(gè)過(guò)程是一個(gè)分析過(guò)程，即使不做軟件研發(fā)，做其他的研發(fā)，類似的分析過(guò)程也應(yīng)該是有的。

2)系統(tǒng)模型，解決方案空間領(lǐng)域模型，邏輯模型是同樣的意思，這個(gè)層次上的實(shí)體，我們稱之為系統(tǒng)實(shí)體，或者邏輯實(shí)體，就是各種類，這個(gè)是用在軟件設(shè)計(jì)和軟件研發(fā)上的。

3)存儲(chǔ)模型，數(shù)據(jù)模型，物理模型，在這里也是同樣的意思，這個(gè)層次上的實(shí)體，我們稱之為數(shù)據(jù)實(shí)體，或者物理實(shí)體，也是用在軟件設(shè)計(jì)上。

這 3 個(gè)層次其實(shí)是從 3 個(gè)角度在看待問(wèn)題，他們之間是自上而下的轉(zhuǎn)換的關(guān)系，這里尤其要注意的兩個(gè)詞是：邏輯的，順序的推導(dǎo)。

這些不同層次的模型是應(yīng)用邏輯架構(gòu)的基礎(chǔ)!!!

3.2 模型的推導(dǎo)

3.2.1 用例集合推導(dǎo)概念模型

??

1. 根據(jù)用例集合推導(dǎo)業(yè)務(wù)概念模型
2. 根據(jù)用例中的動(dòng)詞和量詞推導(dǎo)業(yè)務(wù)概念模型的關(guān)聯(lián)關(guān)系
3. 在特定的邊界內(nèi)根據(jù)模型的職責(zé)歸納子域

重要!重要!重要!這里業(yè)務(wù)概念模型如果沒(méi)有分析正確，那么下面要搞清楚是不容易的，這個(gè)分析部分是軟件邏輯架構(gòu)設(shè)計(jì)的基礎(chǔ)。

這個(gè)環(huán)節(jié)需要我們理解業(yè)務(wù)，更需要我們掌握問(wèn)題空間建模這一嚴(yán)謹(jǐn)?shù)姆椒ㄕ摚@樣我們才能推導(dǎo)出合理的模型，整個(gè)過(guò)程是非常嚴(yán)謹(jǐn)?shù)?，非常符合邏輯的?/p>

我在各 BU 分享現(xiàn)場(chǎng)做的多次實(shí)戰(zhàn)演練之所以能成功的快速幫助同學(xué)們梳理出前面花一兩個(gè)月都沒(méi)有理出的模型，完全是因?yàn)橛诂F(xiàn)場(chǎng)的同學(xué)對(duì)業(yè)務(wù)的理解(因?yàn)橛懻撝拔彝耆珱](méi)有了解過(guò)對(duì)方的業(yè)務(wù))和這套方法論(隱含在我的提問(wèn)方式中)。所以說(shuō)對(duì)業(yè)務(wù)的理解和方法論，兩者缺一不可。

3.2.2 對(duì)業(yè)務(wù)概念模型進(jìn)行歸納

在模型產(chǎn)出之后，我們要對(duì)模型進(jìn)行歸納。

什么叫歸納?

歸納的意思是將所有的結(jié)果和想法合并，變成一種思維概念。或者讓某個(gè)模型歸屬于某個(gè)已經(jīng)存在的思維概念。且這些模型或者模塊的職責(zé)不能超越這個(gè)高層次思維概念的邊界。

為什么要?dú)w納?

其實(shí)是為了保證相近的職責(zé)模型聚攏在一起從而保證職責(zé)的高內(nèi)聚，同時(shí)明確出來(lái)的兩個(gè)子域的邊界，保證模塊和模塊之間的低耦合。

對(duì)業(yè)務(wù)概念模型的歸納有助于做業(yè)務(wù)需求分析時(shí)判斷高內(nèi)聚和低耦合，而且在系統(tǒng)模型上，對(duì)系統(tǒng)模型進(jìn)行分類也有助于做應(yīng)用邏輯架構(gòu)中模塊的高內(nèi)聚和低耦合，但是應(yīng)用邏輯架構(gòu)的不止高內(nèi)聚和低耦合，還有其他讓職責(zé)單一的方法，這些后面的章節(jié)會(huì)做介紹。

3.2.3 按職責(zé)來(lái)進(jìn)行歸納

接下來(lái)我們來(lái)講講業(yè)務(wù)概念模型到業(yè)務(wù)概念架構(gòu)判斷方法：

1)通過(guò)名詞定義來(lái)進(jìn)行歸納思維概念

如果多個(gè)模型都在圍繞某個(gè)名詞，那么我們傾向?qū)⑦@個(gè)名詞提煉出來(lái)。產(chǎn)品在設(shè)計(jì)時(shí)，基本上我們已經(jīng)能夠得一個(gè)粗略的業(yè)務(wù)模塊劃分，但是這個(gè)粗略的劃分是不一定是合理：

• 一是有可能我們的理解是不到位的，導(dǎo)致用錯(cuò)了名詞，這個(gè)我們前面的文章中也提到過(guò)了。
• 二是這個(gè)結(jié)果也只是一個(gè)粗略的結(jié)果，需要進(jìn)一步精化。

2)通過(guò)內(nèi)聚的度量公式來(lái)進(jìn)行歸納

??

業(yè)務(wù)模型圖中，模型和模型連線(連線就是模型和模型連接線)數(shù)量除以模型的梳理得到的值比較大的，那么我們可以看做是內(nèi)聚，這些連線比較緊密我們趨向?qū)⑵浞诺揭粋€(gè)模塊中，連線不是那么密切的，我們趨向于將它們放置在不同的模塊中。然后我們?cè)儆^察 連線數(shù) / 模型數(shù) 觀察內(nèi)聚度量是高了還是低了，通過(guò)這樣的方式歸納完成之后，我們?cè)賮?lái)通過(guò)度量公式來(lái)度量各模塊的內(nèi)聚和耦合程度。

3)其他歸納方式

如果我們劃分出了基本模塊，發(fā)現(xiàn)還有一些模型不確定應(yīng)該放到哪些模塊中，我們還可以使用創(chuàng)建者原則和信息專家原則來(lái)判斷應(yīng)該將該模型歸納如哪個(gè)模塊。

比如說(shuō)，對(duì)存儲(chǔ)系統(tǒng)進(jìn)行系統(tǒng)建模，表和字段的關(guān)系在業(yè)務(wù)概念模型中是1對(duì)n的關(guān)系(在系統(tǒng)模型中是組合關(guān)系，強(qiáng)生命周期依賴，但是這里我們還沒(méi)有到討論應(yīng)用邏輯架構(gòu)的時(shí)候，只是在推導(dǎo)業(yè)務(wù)概念架構(gòu))，此時(shí)將字段放到另外一個(gè)模塊顯然不合適，原因是根據(jù)創(chuàng)建者原則。

當(dāng)我們不清楚把字段模型放到哪個(gè)模塊的時(shí)候，我們可以看看字段這個(gè)模型是由誰(shuí)創(chuàng)建的。

根據(jù)這條原則顯然這里是表創(chuàng)建了字段，沒(méi)有表對(duì)象，就沒(méi)有字段對(duì)象，所以根據(jù)這條原則，我們就傾向于把字段模型放到表所在的模塊中。

重點(diǎn)：失去了最底層合理且正確的演繹，上層的歸納掌握的再好，也很難得出合理的結(jié)果。

我們來(lái)看看歸納之后的效果示意圖：

??

圖中的 A1，A2，A3，A4 之類是示意圖，表示 A 模塊內(nèi)部還存在子模塊，當(dāng)然我們其實(shí)是先推導(dǎo)出子模塊，然后對(duì)子模塊再次進(jìn)行高級(jí)別歸納，形成父模塊。

父模塊層級(jí)再進(jìn)行歸納，就形成了祖父模塊，或者再向上形成曾祖父模塊等等。粒度越大的模塊，一般都對(duì)應(yīng)更大的組織，越存在跨團(tuán)隊(duì)溝通，所以劃清邊界的要求就越高。

3.3 業(yè)務(wù)流程

除了業(yè)務(wù)模型之外，業(yè)務(wù)流程也是我們需要總結(jié)并明確的地方，這個(gè)地方主要明確的就是邊界和異常分支等等，尤其是異常分支非常重要，很多業(yè)務(wù)方案的設(shè)計(jì)中對(duì)異常分支的考量是不重復(fù)的，這需要工程師對(duì)業(yè)務(wù)方案提出挑戰(zhàn)，以明確業(yè)務(wù)方案中的各種流程的異常分支。

3.4 業(yè)務(wù)概念架構(gòu)總結(jié)

我們工作中常見(jiàn)的推導(dǎo)有兩種方式，一種是自頂向下推導(dǎo)，一種是自底向上推導(dǎo)，顯然，兩種推導(dǎo)使用的方法是不一樣的。細(xì)心的讀者會(huì)發(fā)現(xiàn)，其實(shí)我們剛剛說(shuō)的問(wèn)題空間領(lǐng)域模型和邊界分析這套方法就是自底向上的演繹和歸納方法。

四、基礎(chǔ)邏輯架構(gòu)推導(dǎo)(軟件設(shè)計(jì)階段)

前面我們講到了業(yè)務(wù)分析階段，也是問(wèn)題空間建模和問(wèn)題空間業(yè)務(wù)概念架構(gòu)梳理，業(yè)務(wù)分析階段和軟件沒(méi)有任何關(guān)系。但本文中它是軟件設(shè)計(jì)的前置條件，沒(méi)有 get 到點(diǎn)的同學(xué)，請(qǐng)務(wù)必再把前一章仔細(xì)閱讀。

接下來(lái)我們來(lái)講講軟件設(shè)計(jì)階段我們需要產(chǎn)出的應(yīng)用邏輯架構(gòu)。

4.1 再談邏輯架構(gòu)特性

文章開(kāi)頭講到了邏輯架構(gòu)的相關(guān)特點(diǎn)，我們回顧一下：

• 應(yīng)用邏輯架構(gòu)的作用：我們把前面那個(gè)例子再搬過(guò)來(lái)：如果拿汽車舉例，那就是發(fā)動(dòng)機(jī)模塊中包含了哪些子模塊(活塞，曲軸，連桿，缸體，缸蓋，等等)發(fā)動(dòng)機(jī)模塊和變速箱模塊之間的關(guān)聯(lián)關(guān)系是什么，和底盤(pán)的關(guān)聯(lián)關(guān)系是什么，發(fā)動(dòng)機(jī)，底盤(pán)，變速箱，電子系統(tǒng)在整輛汽車中的職責(zé)，關(guān)系，約束是什么。這些都是用來(lái)指導(dǎo)汽車研發(fā)的。而不是指導(dǎo)用戶如何使用這輛汽車的。
• 目的：所以系統(tǒng)模型和應(yīng)用邏輯架構(gòu)都是用在軟件設(shè)計(jì)階段，其目的是用來(lái)指導(dǎo)軟件的研發(fā)。
• 受眾：邏輯架構(gòu)的受眾有哪些呢?一般是這些人：研發(fā)人員，各層級(jí)架構(gòu)師，各層級(jí)技術(shù)管理者，總的來(lái)說(shuō)他們都是架構(gòu)的設(shè)計(jì)者和實(shí)現(xiàn)者。

這里還是請(qǐng)大家務(wù)必要跟產(chǎn)品功能架構(gòu)區(qū)分開(kāi)來(lái)，它們的受眾和目標(biāo)是不一樣的。

4.2 基礎(chǔ)邏輯架構(gòu)的推導(dǎo)概要

在文章開(kāi)頭的圖中，我們講到應(yīng)用邏輯架構(gòu)來(lái)源于系統(tǒng)模型，數(shù)據(jù)模型，業(yè)務(wù)概念架構(gòu)，還有流程，如下圖所示。

??

接下來(lái)，我們分別從三個(gè)角度來(lái)闡述邏輯架構(gòu)的生成：

1. 業(yè)務(wù)概念架構(gòu)
2. 模型(系統(tǒng)模型和數(shù)據(jù)模型)
3. 流程(系統(tǒng)調(diào)用流和數(shù)據(jù)流)

看到很多同學(xué)畫(huà)的圖沒(méi)有區(qū)分出調(diào)用流和數(shù)據(jù)流，經(jīng)常造成誤解，造成溝通效率下降，甚至不能夠準(zhǔn)確的說(shuō)明問(wèn)題。所以在畫(huà)圖的時(shí)候，一定要注意區(qū)分調(diào)用流和數(shù)據(jù)流。

接下來(lái)就根據(jù)業(yè)務(wù)概念架構(gòu)和系統(tǒng)模型及流程來(lái)推導(dǎo)一下應(yīng)用架構(gòu)(邏輯架構(gòu))。我們來(lái)看一下一個(gè)簡(jiǎn)單的邏輯架構(gòu)構(gòu)成的 gif 示意圖：

??

從這張圖中，我們可以看出應(yīng)用邏輯架構(gòu)是如何一步步被構(gòu)成的，整個(gè)過(guò)程存在以下關(guān)鍵點(diǎn)：

1)在業(yè)務(wù)概念架構(gòu)的基礎(chǔ)上推演應(yīng)用邏輯架構(gòu)。

2)根據(jù)流程和系統(tǒng)模型來(lái)完善應(yīng)用邏輯架構(gòu)。

3)橫向提煉模塊的問(wèn)題：要實(shí)現(xiàn)業(yè)務(wù)模塊，需要什么非業(yè)務(wù)模塊的支撐，比如監(jiān)控，報(bào)警，配置等等，而這部分內(nèi)容往往還是可復(fù)用的。在上述動(dòng)畫(huà)中，可以理解成移動(dòng)到最右側(cè)的部分，當(dāng)然可以移動(dòng)到左側(cè)，只是動(dòng)畫(huà)中沒(méi)有體現(xiàn)出來(lái)。

4)縱向提煉模塊問(wèn)題：有類似職責(zé)的模塊在技術(shù)實(shí)現(xiàn)上是否可以提煉成可復(fù)用內(nèi)容，提煉的結(jié)果可能是：

• 獨(dú)立的服務(wù)復(fù)用，在上述動(dòng)畫(huà)中，可以理解成最下方。
• 或者二方庫(kù)復(fù)用，在上述動(dòng)畫(huà)中，可以理解成最左或者最右側(cè)。
• 等

5)還有一些模塊是為了支撐性能或者穩(wěn)定性的，并非是從業(yè)務(wù)概念模型提煉而來(lái)，如圖中深藍(lán)色的模塊。

最終，出現(xiàn)的邏輯架構(gòu)是分層的和分片的邏輯架構(gòu)，下面我們來(lái)一步步闡述這個(gè)過(guò)程。

4.3 根據(jù)業(yè)務(wù)概念架構(gòu)推演

業(yè)務(wù)概念架構(gòu)圖產(chǎn)出之后，基本上，我們邏輯架構(gòu)的初步模型就具備了。所以我們可以理解成，第一步就是把業(yè)務(wù)概念架構(gòu)直接先搬到應(yīng)用邏輯架構(gòu)中來(lái)，此處就不用多闡述了。

啰嗦兩句：尤其是較為頂層的粗粒度業(yè)務(wù)架構(gòu)，一個(gè)是自頂向下分解得來(lái)，一個(gè)是自底向上演繹和歸納得來(lái)。而自頂向下分解尤其考驗(yàn)人對(duì)業(yè)務(wù)的理解能力，如果對(duì)業(yè)務(wù)理解不透徹，那很難產(chǎn)出合理的粗粒度業(yè)務(wù)概念架構(gòu)。

4.4 根據(jù)系統(tǒng)流程進(jìn)行推演模塊

當(dāng)業(yè)務(wù)概念架構(gòu)產(chǎn)出之后，邏輯架構(gòu)的骨架初成，接下來(lái)就是在這個(gè)框架上去填充內(nèi)容。第一步就是根據(jù)流程來(lái)進(jìn)行模塊劃分。

總結(jié)一下，這里的方法就是，先根據(jù)業(yè)務(wù)流程，分解出系統(tǒng)時(shí)序圖，根據(jù)時(shí)序圖開(kāi)始對(duì)模塊進(jìn)行歸納，從而得到粒度更大的模塊。

這是粒度比較細(xì)的根據(jù)流程劃分模塊的案例，在粒度更大的流程，此方法同樣適用，看大家是工作在何種粒度上。

通過(guò)流程來(lái)進(jìn)行推導(dǎo)是我們?nèi)粘９ぷ鞅夭豢缮俚囊徊糠?，尤其?dāng)很多場(chǎng)景的流程具有業(yè)務(wù)共同點(diǎn)時(shí)，那么可以考慮提煉出這些業(yè)務(wù)共同點(diǎn)，以提升研發(fā)的效率。

4.5 非業(yè)務(wù)線系統(tǒng)根據(jù)流程推導(dǎo)模塊案例

除了對(duì)流程進(jìn)行歸納之外，我們還可以對(duì)系統(tǒng)模型進(jìn)行歸納。我們知道，業(yè)務(wù)概念模型一般可以直接轉(zhuǎn)換為系統(tǒng)模型，但是系統(tǒng)模型并不只是業(yè)務(wù)領(lǐng)域相關(guān)的模型，比如查詢模型是一個(gè)經(jīng)常出現(xiàn)的，這在 OLTP 的場(chǎng)景十分常見(jiàn)，而在 OLAP 的場(chǎng)景簡(jiǎn)直就是頂梁柱。非常常見(jiàn)的就是 SQL parser 模塊，下圖是 spark 體系中 SQL SQL 的主要流程和對(duì)應(yīng)的模型，根據(jù)這個(gè)模型我們基本上也可以梳理出模塊：

??

根據(jù)這個(gè)流程，我們發(fā)現(xiàn)了什么?我們發(fā)現(xiàn)了 spark 中是這樣分模塊的(這里面的模塊已經(jīng)落地成 package 了)：

??

所以說(shuō)按照業(yè)務(wù)流程轉(zhuǎn)換成的系統(tǒng)流程來(lái)推導(dǎo)模塊是非常重要的手段。

除此之外需要還需要強(qiáng)調(diào)的是，流程和模塊一樣，也是有粒度的，相同粒度的流程節(jié)點(diǎn)放在一起才更加容易推導(dǎo)出合理的架構(gòu)模塊。至于什么叫相同粒度，請(qǐng)參考一下《金字塔原理》。

流程的粒度很重要，粒度粒度粒度，請(qǐng)重視流程的粒度。

4.6 根據(jù)性能 & 穩(wěn)定性 & 成本等進(jìn)行提煉模塊

前面講的都是從業(yè)務(wù)的角度來(lái)闡述架構(gòu)的推導(dǎo)，接下來(lái)我們從計(jì)算機(jī)科學(xué)與技術(shù)的角度來(lái)闡述一下這些非功能性模塊的推導(dǎo)，這里拿性能來(lái)舉個(gè)例子吧。

數(shù)據(jù)分析的報(bào)表場(chǎng)景降低 RT 的方案

在一些數(shù)據(jù)分析產(chǎn)品中，績(jī)效監(jiān)控及報(bào)表展示是一個(gè)非常重要的場(chǎng)景，這個(gè)場(chǎng)景下的數(shù)據(jù)量是比較大的，為了降低 RT，我們不得不通過(guò) ETL 對(duì)數(shù)據(jù)進(jìn)行預(yù)計(jì)算，將原有的大表清洗成聚合之后的小表，以加快查詢的速度。這樣做的缺點(diǎn)是每次進(jìn)行報(bào)表的修改，就要進(jìn)行相關(guān)的ETL邏輯，高時(shí)間和人力成本，高性能。

為了把高時(shí)間和人力成本 & 高性能轉(zhuǎn)換成低成本&高性能，我們需要把人工操作轉(zhuǎn)換成自動(dòng)操作，把 ETL 的過(guò)程去除。

第一個(gè)選擇是將一個(gè)大表的數(shù)據(jù)存儲(chǔ)到另外一個(gè)支持大數(shù)據(jù)下高性能的查詢引擎，這樣就極大的減少了 ETL 的操作，但是這樣就帶來(lái)一個(gè)問(wèn)題，就是大數(shù)據(jù)量下把數(shù)據(jù)從 ODPS 導(dǎo)入到某個(gè) ROLAP 的查詢引擎中是比較耗時(shí)的，而且每次查詢需要進(jìn)行在海量數(shù)據(jù)中進(jìn)行大量的 scan，但實(shí)際上獲取的數(shù)據(jù)量并不大。這樣的查詢的 RT 依然需要亞秒級(jí)。

第二個(gè)選擇是根據(jù)報(bào)表的定義，自動(dòng)的將判斷出用戶需要查詢什么結(jié)果，將查詢結(jié)果提前計(jì)算出來(lái)，然后只把這些少量的預(yù)計(jì)算后的結(jié)果導(dǎo)入到 ROLAP 引擎中(具體請(qǐng)參考 apache 開(kāi)源項(xiàng)目 Kylin)。然后在報(bào)表的場(chǎng)景下，查詢的 RT 下降到了百毫秒級(jí)。

顯然我們要實(shí)現(xiàn)第二種方式，這個(gè)時(shí)候在業(yè)務(wù)功能沒(méi)有增加的情況下，我們必須要增加一個(gè)模塊，在我們的產(chǎn)品中，我們稱之為 intelligent cube，因?yàn)槲覀冞@里引入了機(jī)器學(xué)習(xí)算法對(duì) cube 的構(gòu)建進(jìn)行了預(yù)測(cè)，無(wú)需或者只需非常少量的人為參與。

最后導(dǎo)致邏輯架構(gòu)中有部分是來(lái)自業(yè)務(wù)概念架構(gòu)推導(dǎo)而來(lái)，有部分是系統(tǒng)流程推導(dǎo)而來(lái)，有部分是因?yàn)樾阅?& 成本的需要產(chǎn)生的設(shè)計(jì)。

注意：理論上來(lái)講，邏輯架構(gòu)上需要指出模塊之間的依賴關(guān)系，只是如果這樣，不是特別美觀，所以就根據(jù)上下和左右的位置來(lái)大概描述模塊之間的關(guān)系了。

這兩個(gè)案例基本可以說(shuō)明，根據(jù)性能 & 成本 & 穩(wěn)定性推導(dǎo)出來(lái)的模塊也是邏輯架構(gòu)組成的重要部分。

但是這個(gè)還只是一個(gè)場(chǎng)景一個(gè)場(chǎng)景來(lái)解決 RT 問(wèn)題，雖然 icube 自己內(nèi)部是有個(gè)體系的，但是通過(guò)這樣的方式來(lái)解決 RT 問(wèn)題對(duì)于整個(gè)架構(gòu)來(lái)說(shuō)也是自底向上構(gòu)建的一個(gè)環(huán)節(jié)。在下一篇文章中，我們將會(huì)闡述相同的案例，但是思路是自頂向下來(lái)構(gòu)建性能領(lǐng)域的體系化架構(gòu)。同樣一個(gè)事情，用不同的思路來(lái)做，對(duì)總目標(biāo)的幫助是不一樣的，而且兩個(gè)方法是互補(bǔ)的，誰(shuí)都少不了。

這樣的模塊是如何得來(lái)的呢?

看上去我們都已經(jīng)知道了系統(tǒng)中有不少類似的純技術(shù)相關(guān)的模塊，但是這些模塊內(nèi)部是如何設(shè)計(jì)出來(lái)的呢?

一般來(lái)說(shuō)有如下方法幫助我們做這些模塊的內(nèi)部設(shè)計(jì)：

1)調(diào)查業(yè)界的開(kāi)源技術(shù)類產(chǎn)品中是否有類似功能的，比如預(yù)計(jì)算在業(yè)界有 kylin，而星環(huán)等專業(yè)大數(shù)據(jù)公司也都有自己的 cube 預(yù)計(jì)算產(chǎn)品。

2)查閱業(yè)界相關(guān)的論文，比如說(shuō)在預(yù)計(jì)算領(lǐng)域就已經(jīng)研究了幾十年，計(jì)算機(jī)發(fā)展的不同階段有不同的論文，網(wǎng)上一搜一大堆，不斷研究，必對(duì)工作有幫助。

3)多關(guān)注業(yè)界的牛人，看看他們?cè)谙胧裁?，說(shuō)什么，參加參加相關(guān)的會(huì)議。

4)自己通過(guò)邏輯和數(shù)據(jù)結(jié)構(gòu) & 算法推導(dǎo)出來(lái)。

如果每次都只通過(guò)自己的邏輯和自己已經(jīng)掌握的知識(shí)來(lái)進(jìn)行方案的推導(dǎo)是不夠的，一個(gè)是我們的技能有時(shí)候和事情是不匹配的，但是我們往往不知道這樣的事實(shí)的存在，所以此時(shí)一定要虛心學(xué)習(xí)，請(qǐng)教他人，擴(kuò)展自己的知識(shí)邊界，才能做出更好的方案和技術(shù)決策。

4.7 應(yīng)用邏輯架構(gòu)推導(dǎo)小結(jié)

根據(jù)上文所述，基本上應(yīng)用邏輯架構(gòu)的推導(dǎo)有 4 個(gè)子路徑，他們分別是：

1. 業(yè)務(wù)概念架構(gòu)：業(yè)務(wù)概念架構(gòu)來(lái)自于業(yè)務(wù)概念模型和業(yè)務(wù)流程
2. 系統(tǒng)模型：來(lái)自于業(yè)務(wù)概念模型
3. 系統(tǒng)流程：來(lái)自業(yè)務(wù)流程
4. 非功能性的系統(tǒng)支撐：來(lái)自對(duì)性能，穩(wěn)定性，成本的需要

每個(gè)子路徑中都存在相關(guān)的具體方法。

如果真的要想學(xué)習(xí)東西，而且想學(xué)的更快更深入，就要關(guān)注自己如何集中注意力，要思考自己的思考方式，研究自己的研究方式。