鏈接上文[解讀REST] 2.REST用來干什么的？，上文中解釋到什么是架構風格和應該以怎樣的視角來理解REST（Web的架構風格）。本篇來介紹一組自洽的術語，用它來描述和解釋軟件架構；以及列舉下對于基于網絡的應用來說，哪些點是需要我們重點關注的。

1 軟件架構

軟件架構方面關注的是如何以最佳的方式劃分一個系統、如何標識組件、組件之間如何通信、信息如何表達、組成系統的元素如何獨立的進化，以及如何表達上述的內容。一個優秀的軟件架構并非憑空靠想象得來的，每一個架構級的決策，都應該根據被設計的系統功能、行為和社交三方面的需求而作出。這是一個基本的設計原則，即“形式追隨功能”，這條原則源自于建筑學領域在數百年中失敗的建筑項目中獲得的經驗，但是卻總被軟件行業所忽略。“dedign-by-buzzword”的行為隨處可見，出現這種行為的原因在于很多設計者在選擇某一個優秀的軟件架構時，不了解這個架構的適用場景是什么、背后是基于什么考量才得出的這樣的架構，以及是否吻合自己的需求。下面先介紹一組自洽的術語來描述解釋軟件架構。

1.1 運行時抽象

軟件架構是一個軟件系統在其運行過程中某個階段的運行時元素的抽象。一個系統可能會有多層抽象和多個運行階段組成，每一個抽象和運行階段都是自己的軟件架構。

軟件架構的核心是抽象：通過封裝來隱藏系統的一些細節，從而更好的識別其架構屬性。一個復雜的系統會有著多層抽象，每一層都有自己的架構，架構代表了某個層次上系統行為的抽象。除了層次之外，系統還會有多個運行階段，比如啟動、初始化、正常運行、停止、重新初始化等，每個階段也都有自己的架構，比如配置文件在啟動的時候會作為架構的一個數據元素來處理，到了正常運行的時候，這些數據元素已經分散到了系統的各個方面，在后續的階段中就不會再把它作為一個數據元素了。

很多時候很容易把軟件的源代碼的靜態結構視為軟件架構，其實這是不妥的。軟件結構是靜態的源代碼的組織結構方式，而非其真正運行起來時所表現出來的功能、層次和行為等。舉個小例子，比如一個接口和它的一個實現者，它們在源代碼級別是歸屬在一個地方的，但是在運行時我們關注的通常是其接口的行為，而非它的實現者身在何處。

1.2 架構元素

軟件架構是由一些架構元素（組件、連接器和數據）的配置來定義的，這些元素之間的關系受到一組約束，以獲得期望的架構屬性。具體的元素類型如下：

組件：組件是軟件指令和內部狀態的抽象單元，通過其接口提供數據的轉換能力。比如執行從硬盤加載數據到內存、執行一些計算、轉換為另外一種格式等。每個組件的行為是架構的一部分，能夠被其他組件觀察到或者識別出來（即由某個組件為其他組件提供的接口和服務來定義該組件，而不是由該組件內部的實現來定義）。具體的例子有瀏覽器，網關，Web服務器（apache，ngnix.，iis）等。
連接器：對于組件之間的通信、配合或者協作進行中間周旋的一種抽象機制。區分連接器和組件的最佳方式是看其對數據的處理方式，連接器是把數據從一個接口移交到另外一個接口而不改變數據，以此來支持組件之間的通信。在連接器的內部，可能是由多個組件組成的子系統，為了移交的目的而對數據進行某種轉換、執行移交然后做想法的轉換并交付與原始數據相同的結果。然而在架構所能捕獲的外部行為抽象中，可以忽略這些細節。具體的例子有緩存，SSL/TLS等等這類。
數據：數據是組件通過連接器接收或發送的信息元素。在基于網絡應用的結構中，數據元素的特性往往會決定某一種架構風格是否適用，比如是直接的和組件進行交互，還是把組件轉換為數據元素，通過網絡移交該元素，然后再對該數據元素做相反的轉換，得到一個能夠在本地與之交互的組件。具體的數據例子有二進制數據，json，HTML文檔，圖片等。

1.3 配置

配置是系統在運行期間和組件、連接器和數據之間的架構關系的結構。此配置非彼配置，指的不是一個系統的各項配置參數，而是如何組織架構元素之間的關系。

1.4 架構屬性

架構屬性是軟件架構對組件、連接器和數據的選擇以及排列所產生的屬性。其包含了系統的功能性屬性以及非功能性屬性（比如組件的可重用性、效率、擴展能力等）。架構屬性是由一組架構約束產生的，而架構約束則是由在架構元素的某一個方面應用軟件工程原則來驅動的。比如統一管道和過濾器架構風格通過在組件的接口上應用通用性的原則（強迫組件實現統一的接口），從而獲得組件的可重用性和可配置性的架構屬性。因此它的架構約束就是由通用性原則所驅動的“統一組件接口”，目的是獲得上述的可重用性和和配置性這兩個架構屬性。舉個簡單的小實例，比如asp net mvc中的filter。

架構設計的目標是創建包含一組期望的架構屬性的架構。這組架構屬性是系統需求的一個超集，不同架構屬性的在這組集合中的所占的比重取決于系統本身的需要。后面會介紹對于一個基于網絡的應用來說，哪些架構屬性是值得關注的。

1.5 架構風格

架構風格的定義在上一篇中已經簡單的解釋過了，這里更嚴謹的定義一下：架構風格是一組相互協作的架構約束，這些架構約束限制了架構元素的角色和功能，以及在任何一個遵循該架構風格的架構中允許存在的元素之間的關系。

一個架構中即會包含功能屬性又會包含非功能屬性，直接比較不同類型的架構時是比較困難的。架構風格是一種對架構進行分類并且定義它們的公共特征的機制。通過比較這部分公共部分的架構約束，來識別其能獲得的架構屬性的差異。好比上篇文章中說到的佛教建筑和古羅馬建筑，比較它們的不同之處的辦法在于用其各自的特征來對比。架構風格是比軟件架構更加抽象的一個層次。比如說面向對象語言如果是架構風格，則Java，C#這些具體的實現了面向對象的語言則是具體的軟件架構；當我們拿C#和C對比的時候，它們的本質差異歸根到底是面向對象與面向過程的差異，而并不是分別實現了面向對象的C#和面向過程的C的具體細節差異。

2 基于網絡應用的架構

軟件架構可以存在于軟件系統的多個層次之上。而REST則是聚焦于軟件架構的最高層次的抽象，即跨越網絡的運行環境，這里的組件是通過網絡通信來實現組件的交互的。

軟件方面的研究通常是關注軟件設計如何分類和設計，但是卻很少能客觀的評估不同的設計對于系統行為有什么影響。

網絡方面的研究則聚焦于系統之間的通信細節以及如何提高通信性能，卻通常忽略一個事實，有時候改變一個應用的交互風格對于性能產生的影響要比改變所使用的通信協議更大。

基于網絡 VS 分布式：基于網絡的架構和軟件架構的區別在于，組件之間的通信僅限于消息傳遞或者消息傳遞的等價物。基于網絡的系統和分布式系統之間有細微的差異，比如一個分布式系統在其消費者看來和普通的集中式系統沒什么區別（只是它背后是運行在多個獨立的系統之上），也就是說其背后的實現對其消費者而言是透明的。而基于網絡的系統則是無需對消費者透明的，比如消費者在執行一個網絡請求時，如果本地的緩存可以滿足其需要，則無需執行一個真正的網絡請求。可以簡單的認為分布式應用屬于基于網絡應用的一個子集。當然也并不是說分布式系統就沒有緩存，這只是一種很細微的差異。

應用軟件 VS 網絡軟件：應用軟件通常來說指的是包含系統中包含業務行為的那部分功能。而網絡軟件的目的通常來說是關注與如何把數據跨越網絡傳遞到另外一個地方，其關心的是如何傳輸，而不關心為何要傳遞這些數據。應用軟件是對整個系統的一個抽象，比如用戶執行一個動作，這個動作中會包含如何獲取數據，執行網絡請求和對請求結果進行呈現，而網絡傳輸則是其中的一個環節。

3 基于網絡應用的關鍵架構屬性

REST關注的是基于網絡的應用軟件的架構設計，這也正是Web的訴求，Web是一個互聯網規模的分布式超媒體系統，互聯網規模意味著無法控制的可伸縮性和組件的獨立部署。那么如何評估一個軟件架構是否滿足Web的需求，把它實現出來看一下？不現實吧。比較可取并且可行的辦法就是利用上面所介紹到的架構屬性來和Web的需求目的進行比較：首先是要滿足功能性的要求，如果一個架構連基本的功能性需求都滿足不了，評估對于它來說就沒什么意義；其次則是非功能性的屬性，這也是評估的主要關注點。下面列舉下基于網絡的應用的關鍵架構屬性。

3.1 性能

性能這個話題或許是計算機行業永遠也繞不開的話題。基于網絡的應用的性能首先取決于應用的需求，然后是所選擇的交互風格，接下來是實現的架構，最后則是每個組件的實現細節。換句話說，應用軟件無法回避為了實現該軟件的需求而付出的基本成本。比如說軟件需要的數據位于系統A，并由系統B來處理，那么該軟件就無法避免的要把數據從系統A移動到系統B（好比你要訪問數據庫，這部分網絡開銷是無論如何也繞不過去的）。無論架構怎樣優秀，網絡的速度再快，也不可能比直接在系統A處理要快。

用戶感知的性能：用戶的一個動作從發出，到其得到響應的時間，其主要有兩個衡量指標，延遲和完成時間。比如打開一張圖片，一邊下載一邊顯示和等下載完后再顯示，對于用戶感知的性能是有明顯的區別的。
網絡性能：通常來講，網絡性能指的的網絡傳輸的吞吐量以及其支撐這些吞吐量所產生的開銷。
網絡效率：一個有趣的現象是，最佳的應用性能通常時通過不使用網絡而獲得的。這也就是說，對于一個基于網絡的應用來說，把對網絡的使用降低到最少，才是最高效的架構風格。