1 什么是軟件架構(gòu)

如下是幾個(gè)對軟件架構(gòu)的理解：

• 應(yīng)用軟件架構(gòu)（architecture）是指一個(gè)過程，在這個(gè)過程中來定義一個(gè)合理的軟件結(jié)構(gòu)，這個(gè)結(jié)構(gòu)滿足所有的技術(shù)和操作需求，同時(shí)保證更優(yōu)的軟件質(zhì)量。軟件質(zhì)量參數(shù)包括性能，安全性，可管理性，以及保證應(yīng)用軟件最后能夠成功問世等內(nèi)容。
• 應(yīng)用軟件架構(gòu)過程是圍繞著一系列的重要決策進(jìn)行，這些決策包括：系統(tǒng)構(gòu)件的選擇，構(gòu)件間接口的設(shè)計(jì)，構(gòu)件間如何進(jìn)行組合，各個(gè)構(gòu)件的行為以及它們之間如何配合工作，如何將這些構(gòu)件以及行為元素組成更大的子系統(tǒng)，以及選擇一個(gè)總領(lǐng)全局的架構(gòu)風(fēng)格。軟件架構(gòu)過程還包括功能性，可靠性，性能，可重用，可理解，經(jīng)濟(jì)性以及技術(shù)條件約束，各種決策的取舍以及審美的考量。
• 從這個(gè)系統(tǒng)的頂層出發(fā)，將系統(tǒng)分解為若干小的子系統(tǒng)，分解后的每個(gè)子系統(tǒng)又有其自身的架構(gòu)方案，且這些方案通常會(huì)隨軟件系統(tǒng)的生命期不斷變化，最后，架構(gòu)即濃縮為最終剩下的一些最為重要的系統(tǒng)內(nèi)容。
• 軟件架構(gòu)過程即一個(gè)動(dòng)態(tài)決策和設(shè)計(jì)進(jìn)化的過程。
• 軟件架構(gòu)也可以理解為是一個(gè)最終形態(tài)，即軟件或系統(tǒng)的結(jié)構(gòu)。其中的組成元素即各種軟件組件。這些組件從外部看，只有其公共接口，以及不同組件間的關(guān)系。架構(gòu)只是這些公共的，外部直接可見的接口及關(guān)系（或協(xié)作）。而組件的內(nèi)部細(xì)節(jié)，并非架構(gòu)所關(guān)注的內(nèi)容。

1.1 軟件架構(gòu)的重要性

其實(shí)軟件的架構(gòu)和現(xiàn)實(shí)世界中的工程的架構(gòu)都是一個(gè)意思，即進(jìn)行構(gòu)建。

任何軟件都必須在一個(gè)堅(jiān)實(shí)的基礎(chǔ)上建立起來。雖然現(xiàn)代軟件工具可以簡化構(gòu)建的實(shí)施過程，但它們無法簡化或自動(dòng)完成軟件的架構(gòu)設(shè)計(jì)。

軟件架構(gòu)過程中需要考慮的因素有三點(diǎn)：

• 用戶
• 底層支撐平臺(tái)
• 具體業(yè)務(wù)要求

而在架構(gòu)過程中，時(shí)常在這三者間進(jìn)行折中，進(jìn)行平衡。例如，總體的用戶體驗(yàn)總是由業(yè)務(wù)和底層平臺(tái)來實(shí)現(xiàn)的，如果將業(yè)務(wù)或者底層平臺(tái)做修改，就可能引起用戶體驗(yàn)的極大變化。另外，如果對用戶體驗(yàn)需求進(jìn)行改變，也可能極大影響到業(yè)務(wù)的設(shè)計(jì)以及底層系統(tǒng)的選擇。

性能可能是一個(gè)主要的用戶體驗(yàn)?zāi)繕?biāo)以及業(yè)務(wù)目標(biāo)，但對于底層系統(tǒng)來說，這個(gè)目標(biāo)不會(huì)總是在考慮范圍之內(nèi)。必須針對這個(gè)目標(biāo)，在三者中進(jìn)行一個(gè)平衡。

軟件架構(gòu)的一個(gè)主要關(guān)注點(diǎn)是構(gòu)成系統(tǒng)的構(gòu)件之間如何進(jìn)行交互。

而構(gòu)件的數(shù)據(jù)結(jié)構(gòu)和算法或?qū)崿F(xiàn)細(xì)節(jié)則是設(shè)計(jì)過程中的關(guān)注點(diǎn)。

不過有些時(shí)候，架構(gòu)關(guān)注點(diǎn)和設(shè)計(jì)關(guān)注點(diǎn)時(shí)常重疊，一般情況下，不要去硬生生將二者分離，而是將二者結(jié)合考慮。只有在特征十分明顯的前提下，才分架構(gòu)關(guān)注點(diǎn)和設(shè)計(jì)關(guān)注點(diǎn)來分別進(jìn)行考慮。

在進(jìn)行軟件架構(gòu)過程時(shí)，考慮如下高層次的關(guān)注內(nèi)容：

• 用戶是如何使用這個(gè)app的？
• 應(yīng)用如何被部署到生產(chǎn)環(huán)境，如何在部署后進(jìn)行管理？
• 應(yīng)用的質(zhì)量屬性需求都有哪些？比如安全性、性能、多線程能力、國際化以及可配置性。
• 如何進(jìn)行架構(gòu)，以保障應(yīng)用隨時(shí)間推移的情況下，仍然有足夠的靈活性來應(yīng)對未來的維護(hù)要求？
• 當(dāng)前業(yè)界架構(gòu)的趨勢是什么？這種趨勢是否會(huì)對應(yīng)用的未來產(chǎn)生影響？

1.2 軟件架構(gòu)的目標(biāo)

軟件架構(gòu)的任務(wù)是在業(yè)務(wù)需求和技術(shù)需求間架設(shè)一座橋梁。即架構(gòu)過程中首先會(huì)明確用例，而后尋找實(shí)現(xiàn)這些用例的途徑，最終構(gòu)成一個(gè)可用的軟件系統(tǒng)。

架構(gòu)的目標(biāo)是識別需求中會(huì)影響到軟件結(jié)構(gòu)的各種內(nèi)容。

好的軟件架構(gòu)能夠在技術(shù)實(shí)現(xiàn)過程中，盡量降低有關(guān)業(yè)務(wù)風(fēng)險(xiǎn)。

一個(gè)好的設(shè)計(jì)必須足夠靈活，能夠適應(yīng)隨時(shí)間推移由軟硬件技術(shù)改變所引起的變化。

架構(gòu)必須考慮總體的設(shè)計(jì)決定，以及各種決策的權(quán)衡。

記住如下架構(gòu)原則：

• 暴露系統(tǒng)結(jié)構(gòu)，隱藏實(shí)現(xiàn)細(xì)節(jié)
• 明確所有可能的用例及使用場景
• 盡可能搜集到更多目標(biāo)用戶的需求
• 要處理功能性和質(zhì)量性的需求

1.2.1 軟件架構(gòu)概覽

首先要了解軟件架構(gòu)過程中影響到?jīng)Q策的一些因素，以及其中哪些因素會(huì)在未來對軟件架構(gòu)產(chǎn)生影響。

這些決定性因素主要由用戶的意愿，產(chǎn)品性能以及環(huán)境的適應(yīng)性所驅(qū)動(dòng)。

以下是一些決定性因素：

• 使用場景
• 市場成熟度
• 設(shè)計(jì)靈活性
• 未來趨勢

1.3 架構(gòu)設(shè)計(jì)的一些主要原則

首先，在進(jìn)行架構(gòu)設(shè)計(jì)時(shí)，前提條件是這個(gè)設(shè)計(jì)會(huì)隨時(shí)間不斷發(fā)生變化，而當(dāng)前的你無法預(yù)知之后的各種可能情況，也就是說無法在當(dāng)前就設(shè)計(jì)一個(gè)架構(gòu)可以滿足未來的一切需求。

架構(gòu)的設(shè)計(jì)需要隨著系統(tǒng)的施工過程不斷進(jìn)化，因?yàn)檫@個(gè)過程中，會(huì)對面對的問題不斷加深理解，并且現(xiàn)實(shí)世界中的需求也不斷驅(qū)動(dòng)架構(gòu)的更新。

所以在架構(gòu)設(shè)計(jì)過程中，必須要抱著進(jìn)化的觀點(diǎn)來看問題（新奧法施工隧道），這樣的架構(gòu)才能適應(yīng)未來各種新需求。

在架構(gòu)設(shè)計(jì)時(shí)，時(shí)刻關(guān)注如下問題：

• 在整個(gè)架構(gòu)設(shè)計(jì)過程中，有哪些內(nèi)容是不能被理解錯(cuò)的（如果理解錯(cuò)了就會(huì)導(dǎo)致整個(gè)軟件系統(tǒng)無效，或是會(huì)給整個(gè)系統(tǒng)帶來巨大風(fēng)險(xiǎn)）？
• 架構(gòu)中有哪些部分是可變的？或者是哪些部分能夠在未來延遲設(shè)計(jì)而不會(huì)影響到當(dāng)前整個(gè)架構(gòu)？
• 架構(gòu)設(shè)計(jì)過程中，都有哪些基本假設(shè)？你又是如何測試這些假設(shè)的？
• 當(dāng)什么情況發(fā)生時(shí)，會(huì)驅(qū)使你重構(gòu)這個(gè)設(shè)計(jì)？

不要過度設(shè)計(jì)！不要做一些無法被驗(yàn)證或測試的假設(shè)！如果遇到這樣的情況，將這些選項(xiàng)保留，在未來的架構(gòu)中再加入它們。

需要明確哪些是架構(gòu)中的基礎(chǔ)性內(nèi)容！如果這些內(nèi)容設(shè)計(jì)錯(cuò)誤，將會(huì)導(dǎo)致架構(gòu)的重新設(shè)計(jì)，進(jìn)而造成巨大損失。

1.3.1 架構(gòu)設(shè)計(jì)準(zhǔn)則

在架構(gòu)設(shè)計(jì)時(shí)，需要記住如下原則：

• 以變化為前提進(jìn)行設(shè)計(jì)，而非一次設(shè)計(jì)永遠(yuǎn)不變。
• 建模分析（如UML），降低風(fēng)險(xiǎn)。首先這個(gè)建模只是分析模型，不要過早進(jìn)行詳細(xì)設(shè)計(jì)，更不要以分析模型作為設(shè)計(jì)過早定型。
• 利用模型和視圖作為交流和溝通工具。好的架構(gòu)設(shè)計(jì)內(nèi)容、決策內(nèi)容以及未來設(shè)計(jì)變化三者的有機(jī)結(jié)合。利用模型、視圖以及其他可視化工具來將架構(gòu)呈現(xiàn)給更多的人，并將決策所引起的變化更快引入到已設(shè)計(jì)的架構(gòu)中。
• 認(rèn)真學(xué)習(xí)前人總結(jié)的關(guān)鍵工程決策內(nèi)容，融入再總結(jié)。

盡量考慮使用一種增量的和迭代的方式來改善架構(gòu)。

首先由一個(gè)架構(gòu)骨架開始，對架構(gòu)有一個(gè)總體的正確性驗(yàn)證，而后不斷變化，生成更多的迭代架構(gòu)，再對這些架構(gòu)進(jìn)行測試和修改優(yōu)化。

不要嘗試在第一次就把所有東西都全部完善，迭代有一個(gè)過程，設(shè)計(jì)過程中的每個(gè)決定都是建立在對需求和假設(shè)可測試的基礎(chǔ)上的。

將設(shè)計(jì)細(xì)節(jié)加入，測試通過，再進(jìn)行下一輪迭代，加入設(shè)計(jì)細(xì)節(jié)，再測試通過，如此往復(fù)。這樣的過程可以保證設(shè)計(jì)決定的大方向是對的，之后只需要再次對設(shè)計(jì)細(xì)節(jié)進(jìn)行完善即可。

一個(gè)常犯的錯(cuò)誤是過早進(jìn)入到設(shè)計(jì)細(xì)節(jié)中，然后卻由于錯(cuò)誤的假設(shè)將設(shè)計(jì)引向萬劫不復(fù)的深淵。

另外一個(gè)常見錯(cuò)誤就是沒有或者是無法對架構(gòu)進(jìn)行評估。

故在測試架構(gòu)時(shí)，需要記住問自己如下問題：

• 這個(gè)架構(gòu)中的假設(shè)都有哪些？
• 架構(gòu)中顯式地或隱含地滿足了哪些需求？
• 這樣的架構(gòu)中有哪些關(guān)鍵風(fēng)險(xiǎn)？
• 為緩和這些關(guān)鍵風(fēng)險(xiǎn)，可以有哪些對策？
• 和上一個(gè)迭代架構(gòu)相比，這個(gè)架構(gòu)在哪些方面有所提升？

另外一些推薦閱讀書籍：

Software Architecture in Practice

Patterns of Enterprise Application Architecture