架構(gòu)這個(gè)概念,，和計(jì)算機(jī)科學(xué)（包括近幾年才成為一級(jí)學(xué)科的軟件工程）的其他術(shù)語(yǔ)類似，都是從傳統(tǒng)學(xué)科借用來(lái)的,。這是因?yàn)橛?jì)算機(jī)科學(xué)太年輕,、發(fā)展太快，來(lái)不及形成自己特有的術(shù)語(yǔ)和名詞,。因此,，在學(xué)習(xí)和思考方法上，我常常推薦類比法,，嘗試用一些耳熟能詳?shù)氖挛锶ダ斫夂徒忉層?jì)算機(jī)科學(xué)領(lǐng)域的概念,，以求“老嫗?zāi)芏钡男Ч?/span>

今天給大家分享的主要包括以下內(nèi)容：

這里介紹的一些內(nèi)容，大多是個(gè)人在學(xué)習(xí)和實(shí)踐過(guò)程中的一些思考和體會(huì),，還很不成體系,，還有很多需要繼續(xù)推敲的地方,。我會(huì)在未來(lái)的工作實(shí)踐中更加深入思考，廣泛參考領(lǐng)域內(nèi)的成果,，力求概念準(zhǔn)確,，容易理解。也歡迎各位同行專家不吝賜教,。

關(guān)于架構(gòu)概念的學(xué)習(xí)和理解，我建議從2個(gè)方面入手：

1. 這個(gè)概念來(lái)自于建筑工程領(lǐng)域,，要深入準(zhǔn)確地理解,，需要看一些建筑方面的資料，比如我會(huì)看梁思成《圖像中國(guó)建筑史》手繪圖,，從中體會(huì)什么是架構(gòu),；我也會(huì)到建筑工地去看建筑施工的一些情況；還會(huì)在旅游時(shí)有意識(shí)地關(guān)注不同樣式的建筑,，體會(huì)其架構(gòu)的不同,。“建筑是凝固的音樂(lè)”,，我們要試圖體會(huì)架構(gòu)之美,。

2. 對(duì)于計(jì)算機(jī)科學(xué)與工程實(shí)踐中總結(jié)出來(lái)的一些架構(gòu)，我們要通過(guò)實(shí)踐來(lái)學(xué)習(xí)和領(lǐng)會(huì),。比如對(duì)于MVC架構(gòu),，我們是否聯(lián)想到用VC++編程時(shí)“Document/View”模型？比如說(shuō)到三層架構(gòu)或者多層架構(gòu),，我們是否考慮到與“Client/Server”二層架構(gòu)的關(guān)系,？

架構(gòu)工作可能是隱式的

架構(gòu)工作，不管有沒(méi)有架構(gòu)師被指派,，其實(shí)都是會(huì)做的,，只是有些時(shí)候，架構(gòu)工作被做了,，但沒(méi)有人意識(shí)到,。

有明確的架構(gòu)師，可能會(huì)使架構(gòu)工作更加專業(yè)化,，可能對(duì)提高架構(gòu)的質(zhì)量有幫助,；但并不是只有架構(gòu)師才可以做架構(gòu)工作。

我們應(yīng)該把架構(gòu)師當(dāng)成一種角色,，而不僅僅是一個(gè)頭銜,、一個(gè)位子。也許有很多人的工作頭銜是架構(gòu)師,，但其實(shí)際工作和架構(gòu)關(guān)系不大,，也可能有些人沒(méi)有架構(gòu)師頭銜,，但其在實(shí)際工作中為架構(gòu)正在做貢獻(xiàn)。

// As shown in the figure, TOGAF divides an enterprise architecture into four categories, as follows:
// 1.Business architecture—Describes the processes the business uses to meet its goals
// 2.Application architecture—Describes how specific applications are designed and how they interact with each other
// 3.Data architecture—Describes how the enterprise datastores are organized and accessed
// 4.Technical architecture—Describes the hardware and software infrastructure that supports applications and their interactions

圖中,，TOGAF把企業(yè)架構(gòu)分為4個(gè)部分：

• 業(yè)務(wù)架構(gòu),。描述業(yè)務(wù)流程及其達(dá)成的業(yè)務(wù)目標(biāo)。

• 應(yīng)用架構(gòu),。描述具體的應(yīng)用系統(tǒng)的設(shè)計(jì)以及相互之間的關(guān)系,。

• 數(shù)據(jù)架構(gòu)。描述企業(yè)的數(shù)據(jù)存儲(chǔ)以及訪問(wèn)方式,。

• 技術(shù)架構(gòu),。描述基礎(chǔ)設(shè)施如何支持應(yīng)用系統(tǒng)的運(yùn)行及交互。

其中,，一個(gè)重要的理念是業(yè)務(wù)架構(gòu)與應(yīng)用架構(gòu)的映射關(guān)系（依賴,、推理）。應(yīng)用架構(gòu)要基于業(yè)務(wù)架構(gòu)來(lái)考慮,，而不是憑空想象,。應(yīng)用是業(yè)務(wù)能力的提供者。

我們?cè)谶@里重點(diǎn)關(guān)注數(shù)據(jù),。

很多時(shí)候,，IT部門、以及IT部門的一些人,，常常把自己當(dāng)成數(shù)據(jù)的所有者,，導(dǎo)致認(rèn)為地制造了藩籬，阻礙數(shù)據(jù)的共享及訪問(wèn),。其實(shí),，IT通常應(yīng)該只是“司機(jī)”的角色。角色錯(cuò)位了,，想做事正確,？難于緣木求魚(yú)。

這里強(qiáng)調(diào)數(shù)據(jù),，是因?yàn)閿?shù)據(jù)是對(duì)客觀世界的反映，而我們的每一個(gè)應(yīng)用,，不過(guò)是客觀世界的一個(gè)視圖,。

數(shù)據(jù)是最基本的。數(shù)據(jù)可以被處理,、解釋而得到各種信息,，而信息又可以被挖掘出有用的知識(shí)。我們也可以從中理解當(dāng)今所謂DT的重要性,，以及大數(shù)據(jù)時(shí)代,，數(shù)據(jù)就像工業(yè)時(shí)代的石油一樣重要,。

架構(gòu)是客觀存在的，不管我們是否有意識(shí)地考慮它,。架構(gòu)不是孤立存在的,，它是在具體的上下文環(huán)境中，為達(dá)到明確的目標(biāo)而存在的,。架構(gòu)不是“屠龍術(shù)”,。

“規(guī)劃-架構(gòu)-設(shè)計(jì)”這三者是緊密聯(lián)系的，常常被混為一體,。為了理解這些概念的聯(lián)系和區(qū)別,，我們可以與市政規(guī)劃進(jìn)行類比。巴西利亞的建城史,、華盛頓的城市規(guī)劃,，其理念值得我們?cè)诳紤]架構(gòu)時(shí)借鑒。

1,、規(guī)劃與架構(gòu)

這里把規(guī)劃提取出來(lái),，而不是與架構(gòu)混為一談，是為了有助于理解思考與實(shí)踐的不同階段和步驟,，幫助思維更加清晰,。從軟件工程與建筑工程的類比，更容易地理解架構(gòu)和規(guī)劃,。另外,，“自頂向下，逐步細(xì)化”的結(jié)構(gòu)化思想也清晰可見(jiàn),。我們推崇面向?qū)ο蟮姆椒?，因?yàn)樗c客觀世界的實(shí)際情況更接近，同時(shí),，我們也要繼承和發(fā)揚(yáng)結(jié)構(gòu)化方法,。

2、架構(gòu)與設(shè)計(jì)

所有的架構(gòu)都是設(shè)計(jì),，但不是所有的設(shè)計(jì)都是架構(gòu),。架構(gòu)可以認(rèn)為是宏觀設(shè)計(jì)、頂層設(shè)計(jì),。

計(jì)算模式經(jīng)歷了以下幾個(gè)發(fā)展階段：

1. 主機(jī)-終端（mainframe）

2. 個(gè)人計(jì)算機(jī)（PC）

3. 客戶機(jī)/服務(wù)器（C/S）

4. 分布式計(jì)算（網(wǎng)格,、云計(jì)算等）

我們選擇什么的模式，一方面要跟上技術(shù)發(fā)展的趨勢(shì),，另一方面要知道目的是什么,。

如果規(guī)模不大，采用分布式部署意義不大。

對(duì)解耦與服務(wù)化的關(guān)系進(jìn)行深入思考,，嘗試?yán)斫馄浔举|(zhì),，明確什么是目的，什么是手段,。在做決策的時(shí)候,，就有助于分清主次。

下圖展示一種不嚴(yán)格的解耦方法：

• 代碼行,，是度量程序規(guī)模和約束程序代碼風(fēng)格的常用維度,。

• 這里，考慮通過(guò)限制子程序代碼行數(shù)來(lái)保證“單一職責(zé)”,。

對(duì)于企業(yè)應(yīng)用架構(gòu)向“微”服務(wù)演化,，解耦是基礎(chǔ)。為此,，在程序?qū)崿F(xiàn)時(shí),，“單一職責(zé)”原則需要尊循。即使不走服務(wù)化道路,，降低耦合度也是好的,。

是否可以假定：一般情況下，對(duì)于特定的語(yǔ)言環(huán)境,，比如：java和C#,，較少的代碼行很難實(shí)現(xiàn)多個(gè)業(yè)務(wù)功能？于是以子程序(函數(shù),，過(guò)程,，方法)代碼行數(shù)對(duì)工程師執(zhí)行“單一職責(zé)”原則進(jìn)行度量。

對(duì)于不同語(yǔ)言,，建議對(duì)開(kāi)發(fā)小組的代碼行進(jìn)行統(tǒng)計(jì),，經(jīng)過(guò)一段時(shí)間的積累得出合適的經(jīng)驗(yàn)值。一般地,，這個(gè)代碼行數(shù)的經(jīng)驗(yàn)值是和小組的能力相關(guān)的,。

敏捷方法的使用離不開(kāi)迭代，我們需要合理地使用這兩種方法,，才能使我們的交付物越來(lái)越逼近用戶的真實(shí)需求,。

這里提到了用戶的真實(shí)需求，我也多說(shuō)幾句,。用戶的需求不應(yīng)該是我們作為BSA或者SME假設(shè)出來(lái)的,，而是我們通過(guò)各種有效的方法，比如訪談,，從用戶那里捕獲的。即使我們對(duì)用戶的建議是正確的，幫助用戶完善需求的,，也一定要取得用戶的完全理解并由用戶正式確認(rèn),。

無(wú)論服務(wù)化還是分布式，都需要進(jìn)程間通訊（IPC）,，也包括線程間的通訊,。這樣，一個(gè)好的通訊協(xié)議是必要的,。HTTP協(xié)議的設(shè)計(jì)初衷據(jù)說(shuō)是為了人-機(jī)通訊,，后來(lái)被用作機(jī)器間通訊（M2M），這是服務(wù)化/分布式的網(wǎng)絡(luò)基礎(chǔ),。

其他協(xié)議,，也可以擔(dān)此大任。只是從復(fù)雜性,、使用難易程度,、普遍性等方面要多加考慮。比如傳統(tǒng)的web services,，其SOAP協(xié)議除了可以基于HTTP,，還可以基于 SMTP。

沒(méi)有分工,，協(xié)作就是一句空話,。沒(méi)有明確的分工，就會(huì)造成扯皮等現(xiàn)象,。分工有助于提高效率和質(zhì)量,。要想分工，就要做好功能分解,。而功能分解到合適的粒度,，也可以認(rèn)為是服務(wù)化的基礎(chǔ)。

微服務(wù)所倡導(dǎo)的“單一職責(zé)”,，其實(shí)質(zhì)也是明確責(zé)任,，消除歧義。簡(jiǎn)單即美,，大道至簡(jiǎn),。單一職責(zé)恰恰符合這個(gè)原則。

從圖中這個(gè)對(duì)制造別針的分工的描述,，你會(huì)體會(huì)到并發(fā)現(xiàn),，很多基本道理是相通的，不論對(duì)于生產(chǎn)制造還是軟件開(kāi)發(fā),。這就是道法自然,。

演化這個(gè)詞越來(lái)越流行了，但仔細(xì)想一想,，有些情況演化的周期是很長(zhǎng)的,。就像不可降解的塑料制品，其以無(wú)害身份重新回歸自然需要幾百年甚至更長(zhǎng)的時(shí)間,?？紤]演化時(shí)，也要結(jié)合軟件/應(yīng)用系統(tǒng)的生命周期,，否則失去意義,。

缺少規(guī)劃則難于演化

單靠演化，即使能使架構(gòu)越來(lái)越優(yōu)化,，也可能需要很長(zhǎng)的周期,，而對(duì)于產(chǎn)品或者項(xiàng)目，時(shí)間這個(gè)約束條件往往是苛刻的,。

如前面所闡述,，迭代是有條件的。我的建議是：在有規(guī)劃的基礎(chǔ)上進(jìn)行演化,。我們無(wú)法得到普適的架構(gòu),，但可以得到確定領(lǐng)域的通用架構(gòu)，可以在特定領(lǐng)域通過(guò)演化使應(yīng)用架構(gòu)逐步優(yōu)化,，逐步與業(yè)務(wù)架構(gòu)相適應(yīng),，提高匹配度。

通過(guò)調(diào)研,，我們發(fā)現(xiàn)企業(yè)應(yīng)用系統(tǒng)面臨的三個(gè)主要痛點(diǎn)：

1. 靈活性差

2. 交付時(shí)間長(zhǎng),，動(dòng)輒3個(gè)月或者半年乃至一年

3. 性能差，用戶體驗(yàn)不好

針對(duì)靈活性差,，我們提出要降低耦合度,，這也是軟件工程中的一個(gè)基本原則。這樣的問(wèn)題,，反映出我們的軟件設(shè)計(jì),、開(kāi)發(fā)水平不高的現(xiàn)實(shí)，專業(yè)性差,。很多時(shí)候,，很多開(kāi)發(fā)人員還分不清程序和軟件的區(qū)別，還只停留在功能實(shí)現(xiàn)的低水平上,。這不單是靠架構(gòu)優(yōu)化能解決的,，而是要靠提高整體開(kāi)發(fā)水平來(lái)解決。

針對(duì)交付時(shí)間長(zhǎng),，我們考慮從提高重用和構(gòu)件化等方面著手,，不斷積累企業(yè)應(yīng)用構(gòu)件庫(kù),。這好比我們燒磚建房，我們從實(shí)際需求出發(fā),，逐步建立并不斷更新有限的磚塊規(guī)格集合,，未來(lái)所有的房屋都使用標(biāo)準(zhǔn)件來(lái)搭建,。

針對(duì)性能問(wèn)題,，我們?cè)跇?gòu)件化的基礎(chǔ)上逐步地適度地服務(wù)化，這樣講是因?yàn)槲覀冋J(rèn)為,，不是所有的應(yīng)用系統(tǒng)都適合服務(wù)化,。有了這樣的基礎(chǔ)，我們對(duì)系統(tǒng)的擴(kuò)展,，包括水平和垂直,，都會(huì)變得容易，分布式的部署水到渠成,。

通過(guò)前面的痛點(diǎn)及解決方案的分析,，我們總結(jié)了好的企業(yè)應(yīng)用架構(gòu)的三要素，同時(shí)也作為我們的三步走戰(zhàn)略：

1. 組件化/構(gòu)件化

2. 服務(wù)化

3. 分布式環(huán)境

服務(wù)化是和多進(jìn)程/多線程相關(guān)的,，是減小應(yīng)用部署粒度的過(guò)程,。而分布式部署，其基礎(chǔ)是進(jìn)程/線程間的通信,。要理解RPC,，最好首先理解IPC，這個(gè)前面已有論述,。

這是我們針對(duì)企業(yè)應(yīng)用系統(tǒng)服務(wù)化而開(kāi)發(fā)的模型,，考慮了多種邏輯和物理架構(gòu)。結(jié)合企業(yè)應(yīng)用,，基于多層分布式體系結(jié)構(gòu)而進(jìn)行的實(shí)例化,。我們希望該模型能夠覆蓋企業(yè)的全部應(yīng)用，包括基于package的二次開(kāi)發(fā)系統(tǒng)（如SAP,，Oracle）,，基于SaaS的云應(yīng)用（如SFDC），以及基于Java/.Net自開(kāi)發(fā)的一些應(yīng)用,。我們正在實(shí)踐中逐步完善這個(gè)模型,，希望能為企業(yè)架構(gòu)的優(yōu)化助力。