一、             架構是什么

通常關于架構的第一個問題是架構是什么，很自然也很正常，本文也不能免俗。然而關于這個問題卻沒有一致性答案，同時也要注意到不同應用的架構實質上存在不同差異性。

(一) 架構的定義

架構，雖然人們一直在討論它，甚至于每天都在同其工作，然而這個詞并沒有一個被業界廣泛認可的定義。

大致而言，架構的定義分為三類：

(二) 架構的分類

架構由于應用的不同而存在不同。大體而言，我們可以將當前的應用分為如下四種：互聯網應用、企業應用、桌面/移動應用和游戲。

需要一提的是，雖然幾種應用的存在一定的模糊性，某種技術為多種應用所共用，例如很多的企業應用基于互聯網技術SaaS，以及移動設備的支持。但依然存在很大的不同。

特別的，對于企業架構，大體存在如下幾種流派：

1.       TOGAF， OpenGroup組織提出，圍繞業務、應用、技術和數據四個方面描述架構；

2.       DoDAF/MoDAF，美國和英國國防部提出的架構方案；

3.       Zachman Framework， 根據不同角色的5W1H來審視架構；

4.       4+1視圖，由Philippe Kruchten提出，并被RUP采納；

(三) 架構的關鍵非功能指標

通常來講，架構所關注的非功能需求可以分為三個角度5個特性，如下：

非功能性指標當然不止這些，如下是一些參考：

1.         ISO 9126提出的質量特性：

2.         或者通過如下三個視圖來進行：

                               i.        業務視角

Time To Market、Cost and Benefits、Projected life time、Targeted Market、Integration with Legacy System、Roll back Schedule

                             ii.        最終用戶視角

Performance、Availability、Usability、Security

                            iii.        開發視角

Maintainability、Portability、Reusability、Testability

3.         也可以通過諸如：簡潔性、清晰和一致性等指標。

不同類型的應用關注點會有很大不同，例如：互聯網應用由于面臨大量的最終用戶，會特別關注于伸縮性、可靠性和易用性，這并不是說互聯網應用不關注維護性和擴展性，只是會更加強調另外三個特性；而企業應用由于關注于數據、流程以及業務的適應性，會更多得強調維護性和擴展性，而其他特性如易用性相對弱化（面對內部用戶，強制使用），伸縮性（內部用戶訪問量少，大部分情況下通過現有硬件即可支持）。同時，企業應用對數據一致性和準確性要求非常高，而互聯網應用相對可以容忍一定的不一致性和錯誤。因此，一個企業應用的架構師可能無法設計互聯網應用的架構。

二、             架構有什么

架構有什么，通常會來一張或者一堆好看的圖畫。既然本篇不討論具體應用，故而也拿不出啥圖了，也不想討論這些。因為不同的應用存在的差異，非本文所能涵蓋。這里就想討論下形形色色架構圖的背后的內容，以及隸屬架構但未在架構圖表達的內容。

《易經·系辭》有云：“形而上者謂之道，形而下者謂之器”，將架構分為“形而上”和“形而下”兩個部分，如下圖：

(一) 形而上

形而上體系中，除去前置內容，分為文化和支撐兩大塊。

其中，文化部分里最重要的就是原則和方法論，例如：關注點分離原則（SoC），面向對象分析設計和領域驅動設計等等。在此之下，就是架構模式和算法，常見架構模式為：結構化（分層、管道流、黑板）、分布式（代理和管道流）、交互系統（MVC和PAC）和適配系統（微內核、元數據）。當然還有更低一層次的設計模式（創建、結構和行為）。

(二) 形而下

形而下分為三個部分，運行時、工具和文檔。

其中，運行時的內容按照重要性依次為：語言、平臺/中間件、框架、類庫和工具，具體在企業應用中就是：Java/C#、Windows/Linux、Application Server/Database、Spring/Hibernate等等。

如果說運行時決定最終能力，則工具就事關效率。工具中最常見的是集成開發環境了，此外還有配置、部署和測試工具。

文檔部分是另一個重要的內容，應包括：視圖（從不同角色出發，可以參考4+1），范例和各種指導參考文檔。

三、             架構如何設計

如果把“形而下”當成架構設計的產出，那么架構設計往前追溯，就有輸入和加工過程。

(一) 架構的輸入

架構的輸入包括三個部分：目標、需求和相應約束。其中：目標是大方向內容，需求關注在細節，而約束對目標的達成提供了限定。特別的，關注在非功能性指標上。

(二) 架構的設計過程

架構的設計從需求分析開始，結合參考模型或者已有架構體系，結合原則、方法論等等作料。其主要活動有：技術選型、腳手架/框架/平臺搭建等等。

       關于具體過程的描述，可見《如何定義和建立架構》。

四、             架構如何評估

架構設計出后一個重要的工作是對架構（形而下部分）進行評估，進行架構評估的必要性在：使得架構設計工作形成閉環，確保當前架構是合適和正確的。

大體上，架構評估有三種方法：

·           ATAM: Architecture Tradeoff Analysis Method

·           SAAM: Software Architecture Analysis Method

·           ARID: Active Reviews for Intermediate Designs

在進行架構評估工作時，首先要確定架構評估的參與人，包括相應的干系人和獨立的評估隊伍；然后是確定評估的時機：早期（在架構設計期間就參與評估）和晚期（傳動的，在架構設計完成后）。

評估內容包括如下：

1.         首先是要滿足其輸入：目標、需求和約束；

2.         各項的非功能性指標；

五、             小結

以如下思維導圖作為本文的小結：