作者: Anders小明
一、 架構(gòu)是什么
通常關(guān)于架構(gòu)的第一個(gè)問(wèn)題是架構(gòu)是什么,很自然也很正常,本文也不能免俗。然而關(guān)于這個(gè)問(wèn)題卻沒(méi)有一致性答案,同時(shí)也要注意到不同應(yīng)用的架構(gòu)實(shí)質(zhì)上存在不同差異性。
(一) 架構(gòu)的定義
架構(gòu),雖然人們一直在討論它,甚至于每天都在同其工作,然而這個(gè)詞并沒(méi)有一個(gè)被業(yè)界廣泛認(rèn)可的定義。
大致而言,架構(gòu)的定義分為三類(lèi):
類(lèi)別 |
定義 |
結(jié)構(gòu)論 |
牛津高階詞典: The design an structure of a computer system |
韋氏大辭典: The way in which the parts of a computer are organized |
IEEE: The fundamental organisation of a system embodied in its components, their relationships to each other, and to the environment,and the principle guiding its design and evolution |
關(guān)鍵論 |
架構(gòu)是系統(tǒng)中最關(guān)鍵的20%,關(guān)注在系統(tǒng)非功能性需求 |
文化論 |
架構(gòu)是關(guān)于系統(tǒng)一些的決策 |
(二) 架構(gòu)的分類(lèi)
架構(gòu)由于應(yīng)用的不同而存在不同。大體而言,我們可以將當(dāng)前的應(yīng)用分為如下四種:互聯(lián)網(wǎng)應(yīng)用、企業(yè)應(yīng)用、桌面/移動(dòng)應(yīng)用和游戲。
需要一提的是,雖然幾種應(yīng)用的存在一定的模糊性,某種技術(shù)為多種應(yīng)用所共用,例如很多的企業(yè)應(yīng)用基于互聯(lián)網(wǎng)技術(shù)SaaS,以及移動(dòng)設(shè)備的支持。但依然存在很大的不同。
特別的,對(duì)于企業(yè)架構(gòu),大體存在如下幾種流派:
1. TOGAF, OpenGroup組織提出,圍繞業(yè)務(wù)、應(yīng)用、技術(shù)和數(shù)據(jù)四個(gè)方面描述架構(gòu);
2. DoDAF/MoDAF,美國(guó)和英國(guó)國(guó)防部提出的架構(gòu)方案;
3. Zachman Framework, 根據(jù)不同角色的5W1H來(lái)審視架構(gòu);
4. 4+1視圖,由Philippe Kruchten提出,并被RUP采納;
(三) 架構(gòu)的關(guān)鍵非功能指標(biāo)
通常來(lái)講,架構(gòu)所關(guān)注的非功能需求可以分為三個(gè)角度5個(gè)特性,如下:
角度 |
特性 |
說(shuō)明 |
運(yùn)營(yíng)角度 |
伸縮性 |
主要為水平擴(kuò)展能力 |
可靠性 |
包括容錯(cuò)性、可用性和安全性等; |
開(kāi)發(fā)角度 |
維護(hù)性 |
|
擴(kuò)展性 |
能否快速應(yīng)對(duì)業(yè)務(wù)的變化 |
應(yīng)用角度 |
易用性 |
對(duì)最終用戶(hù)是否友好 |
非功能性指標(biāo)當(dāng)然不止這些,如下是一些參考:
1. ISO 9126提出的質(zhì)量特性:
2. 或者通過(guò)如下三個(gè)視圖來(lái)進(jìn)行:
i. 業(yè)務(wù)視角
Time To Market、Cost and Benefits、Projected life time、Targeted Market、Integration with Legacy System、Roll back Schedule
ii. 最終用戶(hù)視角
Performance、Availability、Usability、Security
iii. 開(kāi)發(fā)視角
Maintainability、Portability、Reusability、Testability
3. 也可以通過(guò)諸如:簡(jiǎn)潔性、清晰和一致性等指標(biāo)。
不同類(lèi)型的應(yīng)用關(guān)注點(diǎn)會(huì)有很大不同,例如:互聯(lián)網(wǎng)應(yīng)用由于面臨大量的最終用戶(hù),會(huì)特別關(guān)注于伸縮性、可靠性和易用性,這并不是說(shuō)互聯(lián)網(wǎng)應(yīng)用不關(guān)注維護(hù)性和擴(kuò)展性,只是會(huì)更加強(qiáng)調(diào)另外三個(gè)特性;而企業(yè)應(yīng)用由于關(guān)注于數(shù)據(jù)、流程以及業(yè)務(wù)的適應(yīng)性,會(huì)更多得強(qiáng)調(diào)維護(hù)性和擴(kuò)展性,而其他特性如易用性相對(duì)弱化(面對(duì)內(nèi)部用戶(hù),強(qiáng)制使用),伸縮性(內(nèi)部用戶(hù)訪問(wèn)量少,大部分情況下通過(guò)現(xiàn)有硬件即可支持)。同時(shí),企業(yè)應(yīng)用對(duì)數(shù)據(jù)一致性和準(zhǔn)確性要求非常高,而互聯(lián)網(wǎng)應(yīng)用相對(duì)可以容忍一定的不一致性和錯(cuò)誤。因此,一個(gè)企業(yè)應(yīng)用的架構(gòu)師可能無(wú)法設(shè)計(jì)互聯(lián)網(wǎng)應(yīng)用的架構(gòu)。
二、 架構(gòu)有什么
架構(gòu)有什么,通常會(huì)來(lái)一張或者一堆好看的圖畫(huà)。既然本篇不討論具體應(yīng)用,故而也拿不出啥圖了,也不想討論這些。因?yàn)椴煌膽?yīng)用存在的差異,非本文所能涵蓋。這里就想討論下形形色色架構(gòu)圖的背后的內(nèi)容,以及隸屬架構(gòu)但未在架構(gòu)圖表達(dá)的內(nèi)容。
《易經(jīng)·系辭》有云:“形而上者謂之道,形而下者謂之器”,將架構(gòu)分為“形而上”和“形而下”兩個(gè)部分,如下圖:
(一) 形而上
形而上體系中,除去前置內(nèi)容,分為文化和支撐兩大塊。
其中,文化部分里最重要的就是原則和方法論,例如:關(guān)注點(diǎn)分離原則(SoC),面向?qū)ο蠓治鲈O(shè)計(jì)和領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)等等。在此之下,就是架構(gòu)模式和算法,常見(jiàn)架構(gòu)模式為:結(jié)構(gòu)化(分層、管道流、黑板)、分布式(代理和管道流)、交互系統(tǒng)(MVC和PAC)和適配系統(tǒng)(微內(nèi)核、元數(shù)據(jù))。當(dāng)然還有更低一層次的設(shè)計(jì)模式(創(chuàng)建、結(jié)構(gòu)和行為)。
(二) 形而下
形而下分為三個(gè)部分,運(yùn)行時(shí)、工具和文檔。
其中,運(yùn)行時(shí)的內(nèi)容按照重要性依次為:語(yǔ)言、平臺(tái)/中間件、框架、類(lèi)庫(kù)和工具,具體在企業(yè)應(yīng)用中就是:Java/C#、Windows/Linux、Application Server/Database、Spring/Hibernate等等。
如果說(shuō)運(yùn)行時(shí)決定最終能力,則工具就事關(guān)效率。工具中最常見(jiàn)的是集成開(kāi)發(fā)環(huán)境了,此外還有配置、部署和測(cè)試工具。
文檔部分是另一個(gè)重要的內(nèi)容,應(yīng)包括:視圖(從不同角色出發(fā),可以參考4+1),范例和各種指導(dǎo)參考文檔。
三、 架構(gòu)如何設(shè)計(jì)
如果把“形而下”當(dāng)成架構(gòu)設(shè)計(jì)的產(chǎn)出,那么架構(gòu)設(shè)計(jì)往前追溯,就有輸入和加工過(guò)程。
(一) 架構(gòu)的輸入
架構(gòu)的輸入包括三個(gè)部分:目標(biāo)、需求和相應(yīng)約束。其中:目標(biāo)是大方向內(nèi)容,需求關(guān)注在細(xì)節(jié),而約束對(duì)目標(biāo)的達(dá)成提供了限定。特別的,關(guān)注在非功能性指標(biāo)上。
(二) 架構(gòu)的設(shè)計(jì)過(guò)程
架構(gòu)的設(shè)計(jì)從需求分析開(kāi)始,結(jié)合參考模型或者已有架構(gòu)體系,結(jié)合原則、方法論等等作料。其主要活動(dòng)有:技術(shù)選型、腳手架/框架/平臺(tái)搭建等等。
關(guān)于具體過(guò)程的描述,可見(jiàn)《如何定義和建立架構(gòu)》。
四、 架構(gòu)如何評(píng)估
架構(gòu)設(shè)計(jì)出后一個(gè)重要的工作是對(duì)架構(gòu)(形而下部分)進(jìn)行評(píng)估,進(jìn)行架構(gòu)評(píng)估的必要性在:使得架構(gòu)設(shè)計(jì)工作形成閉環(huán),確保當(dāng)前架構(gòu)是合適和正確的。
大體上,架構(gòu)評(píng)估有三種方法:
· ATAM: Architecture Tradeoff Analysis Method
· SAAM: Software Architecture Analysis Method
· ARID: Active Reviews for Intermediate Designs
在進(jìn)行架構(gòu)評(píng)估工作時(shí),首先要確定架構(gòu)評(píng)估的參與人,包括相應(yīng)的干系人和獨(dú)立的評(píng)估隊(duì)伍;然后是確定評(píng)估的時(shí)機(jī):早期(在架構(gòu)設(shè)計(jì)期間就參與評(píng)估)和晚期(傳動(dòng)的,在架構(gòu)設(shè)計(jì)完成后)。
評(píng)估內(nèi)容包括如下:
1. 首先是要滿(mǎn)足其輸入:目標(biāo)、需求和約束;
2. 各項(xiàng)的非功能性指標(biāo);
五、 小結(jié)
以如下思維導(dǎo)圖作為本文的小結(jié):