架構漫談二

架構的定義

架構（Architecture）一詞源於建築領域，其自己就是建築的意思，也是體系結構的意思。維基百科英文版裏對 Architecture 的解釋是：規劃、設計和建造建築物的過程及產物。

鑑於軟件工程與建築工程同樣是一項系統的工程性工做，引入到計算機領域後，軟件架構就成爲了描述軟件規劃設計技術的專有名詞。

特別地，軟件架構師一詞在英文裏，和建築師也是同一個詞（Architect）。

維基百科裏對軟件架構的定義：

軟件架構是有關軟件總體結構與組件的抽象描述，用於指導大型軟件系統各個方面的設計。

軟件架構師定義和設計軟件的模塊化，模塊之間的交互，用戶界面風格，對外接口方法，創新的設計特性，以及高層事物的對象操做、邏輯和流程。軟件架構是一個系統的草圖。

軟件架構描述的對象是直接構成系統的抽象組件。各個組件之間的鏈接則明確和相對細緻地描述組件之間的通信。

在實現階段，這些抽象組件被細化爲實際的組件，好比具體某個類或者對象。在面向對象領域中，組件之間的鏈接一般用接口來實現。

比較公認的軟件架構定義是在 2000 年的 ANSI/IEEE 1471 標準中定義的：

1. 架構過程：在系統整個生命週期中構思、定義、表達、記錄、交流，驗證合適實現，維護和改進架構的過程，也就是設計過程。

2. 架構：一個系統體如今其環境中的元素、關係的基本概念或屬性，以及其設計和進化原則。

3. 架構描述：表達一個架構的工做產出物（一般指的是各類架構圖和設計文檔）。

4. 架構視圖：經過系統的某些關注點的視角，表達一個系統的工做產出物（例如部署視圖、開發視圖等）。

5. 系統：包含了一個或多個進程、硬件、軟件、工具與能夠知足需求的人的集合。

6. 環境：決定了開發、操做、策略和其餘影響系統的設置和條件。

在 UML 中，架構則被認爲是系統的組織結構和相關行爲。架構可被分解爲經過接口互聯部分的關係，以及相互做用。

經過接口相互做用的部分包括類、組件和子系統。這樣就能夠經過 UML 的各類架構圖來描述這些對象和關係，從而表達清楚一個系統的架構。

總結 

軟件架構是一個用於指導系統實現的草圖，這個草圖越詳細對於系統實現的指導意義越重大，貫穿於軟件的整個生命週期。

在建築領域，大樓還沒有建造前，就已經存在於建築師的腦海裏；一樣地，系統開始編寫第一行代碼以前，就已經存在於軟件架構師的內心。

幾個相關概念

模式（Pattern）

UML 中給出的解釋更通俗易懂：模式是對於廣泛問題的廣泛解決方案。

咱們能夠把一類問題的共性抽象出來，這樣就能夠用一樣的處理辦法去解決這些問題，從而造成模式，因此模式是一些經驗的總結。

類庫（Library）

類庫是一組可複用的功能或工具的集合，應用系統經過調用它們從而達到複用功能的目的。

例如，Windows 應用開發裏的各類靜態或動態連接庫 DLL 文件，Java 開發中項目裏依賴的或者 Maven 中央庫裏的各類 jar 包，都是 Library，好比 Apache Commons IO、HttpClient，Log4j 等。

框架（Framework）

框架是基於一組類庫或工具，在特定領域裏根據必定的規則組合成的、開放性的應用骨架。

好比 SSM/SSH 框架，更大範圍來講 Dotnet Framework、JDK 都算是一種框架。

關於框架與架構的關係，Vasyl Boroviak 曾在 Stack Overflow 網站上經過兩張圖作了形象的對比，以下所示。

• 框架：

• 架構：

模塊（Module）

模塊是業務或系統的安裝特定維度的一種切分，同時也能夠看作是各類功能按照某種分類聚合的一種形式。

例如咱們的一個電商系統，能夠從業務上劃分爲用戶模塊、商品模塊、訂單模塊、支付模塊、物流模塊、售後模塊等。

另外一方面，咱們也能夠說用戶模塊聚合了用戶註冊、用戶驗證等業務功能。

組件（Component）

組件是一組能夠複用的業務功能的集合，包含一些對象及其行爲。

組件能夠直接被用作業務系統的組成部分，粒度通常小於模塊，也是一種功能的聚合形式。好比日誌組件、權限組件等。

服務（Service）

服務是一組對外提供業務處理能力的功能，服務須要使用明確的接口方式（好比 WebService 或 Rest 等）。

服務描述裏應該包括約束和策略（好比參數、返回值，使用什麼通信協議和數據格式等）。

平臺（Platform）

平臺通常來講，是一個領域或方向上的生態系統，是不少解決方案的集大成者，提供了不少的服務、接口、規範、標準、功能、工具等。

例如 J2EE 平臺，包含了企業級應用開發裏的各類基於 Java 語言和 JVM 虛擬機運行時的技術能力。

知乎社區編程領域優秀問題回答者 ze ran 說：

庫是工具箱。

框架是一套通用的解決方案。

架構是高度抽象的需求，是系統中的不變量。

平臺是全部可能作的事的集合。

從軟件的生命週期看架構設計

設計期

在設計期，軟件做爲一個成品還不存在，因此咱們能夠稱之爲概念形態。

此時架構師、產品經理或需求分析師等人員利用本身的經驗能力，對系統的業務需求進行分析、拆解、抽象，造成業務文檔和技術文檔，以及技術驗證代碼等。

這個階段，架構設計工做是重中之重，其中包括：

• 系統分拆：如何把系統拆解爲不一樣的子系統、模塊、業務單元；

• 技術選型：使用什麼樣的基礎技術框架或腳手架；

• 技術驗證：肯定核心技術難點如何解決，檢驗可否知足指望指標；

• 接口規範：系統的內部不一樣部分以何種形式肯定接口契約和數據通訊；

• 集成方式：系統與外部其餘業務系統如何進行集成；

• 技術規範：如何規範開發、測試、部署和運維的技術標準性；

• 部署方案：系統如何進行物理部署，須要多少機器、什麼配置，對網絡有什麼要求；

• 運維方案：系統如何進行技術性運維，如何平常監控、預警報警；

• ……

這個階段總結一下就是：業務爲要，架構先行（包括業務架構和技術架構）。

實現期

這個階段主要是編碼與測試，準備部署上線，是軟件從代碼到最終的生產系統的過程，咱們能夠稱之爲代碼形態。此階段須要考慮的技術類工做包括：

• 確保各項技術規範和技術指標的執行落地，保障高質量的代碼；

• 指導研發人員和解決各種技術問題，提高研發團隊效率；

• 制定測試的技術性方案和基準，自動化、性能、安全等；

• 配合準備部署環境，運維實施方案落地等。

運行期

這個階段系統上線、驗收經過，已經初步穩定，而後進入維護階段，成爲了設計期架構設計草圖的一個可用實例，咱們能夠稱之爲實例形態。此時須要考慮：

• 發佈上線相關基礎性工做，包括是否使用持續集成（CI)、自動化發佈等技術；

• 運維基礎性工做，自動化運維，監控等相關技術。

架構的形式與特色

設計文檔和代碼

咱們通常說的架構既包括架構的設計過程，也包括設計的產出物，通常能夠包括各種設計文檔、設計圖，也能夠包括一些技術驗證代碼、Demo 或者其餘相關程序。

文檔的目的在於準確記錄咱們的思惟產物，在軟件還沒有實現時，做爲指導藍圖，儘可能精確的描述清楚軟件。

在軟件的實現過程當中，可能隨時隨着咱們的深刻研究，根據具體狀況對文檔作出局部的一些調整和修改。

文檔做爲結項或交接的一部分，也是整個軟件項目的產出物的一部分，成爲公司 IT 資產的有機組成部分。

架構服務於業務

正如 19 世紀的偉大建築師路易斯•沙利文（Louis Sullivan）倡導的建築設計著名格言：「功能決定形式（Form follows function）」。

軟件架構首先是要服務於業務功能的。

架構影響研發團隊的組織形式

業務拆分的方法和技術框架的選擇必然會影響到研發團隊的組織形式。

業務拆分的越細緻，越有利於咱們更好的對項目的各項指標量化計算，更精確的估計工時和成本，從而指導咱們每一個小組應該分配多少資源，使用什麼樣的協同和任務確認形式。

而且隨着項目的推動，計劃與實際狀況之間的匹配程度也隨時能夠進一步精確調整，進而影響到咱們應該對每一塊任務的投入資源進行動態調整。

架構存在於每個系統

每個已經實現並運行的系統，都是特定架構設計的載體。

有些系統對應的架構，有詳細的設計文檔來描述；有些系統的設計文檔，殘缺不全，甚至還由於在系統的發展變化的同時，文檔沒有更新，致使設計文檔與實際系統不符。

有些系統乾脆就沒有設計文檔。

可是這些系統，都是基於必定的架構來建立的。

每種架構都有特定的架構風格

每種架構方式，每一個具體系統內所體現的架構設計，都是能夠被工程師們理解，進而提煉出來一些架構思想和設計原則，這些思想和原則就是這種架構方式的風格。依據這些風格，咱們能夠將各類架構方式，進行分門別類，從而進一步討論每種架構風格的特色。

架構須要不斷的發展演進

隨着計算機軟硬件的不斷髮展，軟件架構思想也在不斷的發展變化。

另外一方面，軟件爲其提供業務處理和服務能力的每一個具體行業領域也在不斷髮展變化，業務處理流程、參與角色、業務形式不斷的推陳出新。

這就要求咱們在系統架構設計時，保持終身學習的精神，持續吸取新思想新知識，保持貼近一線業務羣體，隨時因地制宜，調整架構設計，採起最適合當下場景的解決方案。

附錄:

轉載於：https://blog.csdn.net/csdnnews/article/details/79441488