如何定義和建立架構

這文章太需要了！tigelivable！想要融匯貫通還需認真對待啊~

http://blog.csdn.net/lins/archive/2010/10/31/5977406.aspx

 

在牛津高階詞典（第7版）中，架構（architecture）一詞的解釋是：the design an structure of a computer system。這個解釋實際上已經描述了架構的本質：架構是關於怎麼做（構成系統）的，而非做什麼的。更進一步，架構是由人來設計實施，因此架構實際上是一個文化（culture）——我們怎麼認識或理解系統/產品的，並且我們準備怎麼做，在做的過程中我們認為什麼是好的，什麼是好的等等。

任何系統都有架構，無論多小的系統都有。區別在於其架構是否是經過明確設計並表達。一個合理的架構無疑是經過精心設計和維護的，而進行架構設計，或者說定義/建立一個架構可以分為如下幾個步驟。

特別的，本文針對於企業應用架構，其他應用未必適用。

 

基線準備 

如果建立第一版架構（即從零開始）可以跳過此步，但對於建立第n版（n>=2）架構，則需要進行基線準備。通常從上一個架構設計開始，去除不在必要的內容作為基線。

非功能性需求的收集、分析和細化 

這步驟非常關鍵，本質上架構關注的是系統的非功能性需求，雖然不是系統的全部，但無疑是最重要的20%，而這也是不同公司/產品的架構差異性的根源。

一個完整的非功能性需求列表不僅僅來自業務部門（系統客戶），還需要包括開發/研發管理層以及開發團隊。實踐中可以如下檢查列表來幫助收集：

l         目標應用，企業應用和網際網路應用就不太相同

l         目標環境，系統部署的硬體環境、網路環境等，更有云計算環境和傳統伺服器環境的差異。

l         常見技術指標

n         穩定性/可用性，主要是MTBF和MTBR指標要求

n         效能，如Web應用下單次操作1/5/10原則，相關併發壓力要求等

n         容量，主要是資料容量，此外有時還要考慮記憶體的限制

n         實時性，涉及到資料同步/複製/訊息傳播/非同步操作

n         易用性，這個指標不容易衡量

l         系統/專案/產品自身，來自客戶

l         管理指標，主要來自管理層

n         成熟度/培訓招聘成本

n         產品化/定製化

n         元件化

n         領域化

n         標準性

n         平臺化/小型中介軟體

n         整合性/相容/遷移能力

涉及遺留系統，關於相容需要明確的相容方式和相容模式。相容方式包括：語義相容/原始碼（語言級/API級）相容/執行時相容（執行庫/二進位制）；相容模式：向前相容/向後相容。

n         1.4.6 容錯性

包括速錯能力和消除易錯機制（error-prone mechanism）

n         1.4.7 升級性

以上列表略顯草根性，實際過程中也可以從架構評估角度反向進行非功能性需求收集，可以參考《Attribute Based Architectural Evaluation》。

一次性完整地收集非功能性需求並不是件容易的事，因此在架構釋出後也要不停的進行改進。

架構定義 

完成非功能性需求並明確後，就可以進行架構定義了。架構定義可以分為三個部分：設計、選型以及構建和評估。

 

架構設計

這個階段相對務虛，但卻是整個架構定義的基礎，決定了所有的後續工作。主要包括如下三個工作內容：

l         確定架構手段，包括架構的原則、規範、模式、工具、框架/平臺和語言，以及這些手段的適用範圍，哪些問題應用工具來解決，而另一些問題採用哪個框架/平臺完成，還有一些通過原則或規範處理。

l         確定組織分工和流程，不同的工作通過組織內不同角色完成。

l         確定結構化範圍，區分系統內和系統外，並非所有非功能性需求都是通過系統的手段解決，適當採用系統外手段甚至更簡單和準確。

 

技術選型/預研

紙面上的架構其約束性和可操作性非常低，為了讓架構從三萬英尺的高空落地有兩種辦法：流程和平臺。其中，流程是由元件分工完成，而平臺構建通常不會從零開始，實踐中會盡可能利用已有成果：商業產品和開源產品。因此技術選型以及預研工作則顯得非常重要。

進行技術選型需要注意兩個關鍵點：

u       評估單項技術的有用性（技術功能）和可用性（非功能性需求，即使用成本）

有用性是指相應的技術功能點是否解決架構所面臨的功能性和非功能性需求；

可用性是指是否滿足整體的非功能性需求，如效能、容量和穩定性。以及管理層關注指標（使用成本），如技術成熟度、標準性、培訓招聘成本以及產品的生命週期，以及License費用等。

u       保持全域性視角

關注全域性，木桶理論的再次應用，避免某項技術存在的缺陷影響整體。

主要的選型內容如下：

l         語言，不同語言所能提供的開發能力是不同。而且開發語言直接影響到後續技術的選型以及人員的招聘。

l         框架/平臺，提供執行環境和整合環境。

l         工具，古話說：磨刀不誤砍柴工。但要注意避免工具中心論，正確認識工具的用於——工具是幫助我們解決一些髒活累活的，除此外無它。在整個架構中，工具的作用是大大低於語言和框架/平臺。

除去技術選型外，對於一些不確定的內容，還需開展預研工作，驗證其可行性或者進行效能測試。

 

架構構建和評估

如前所述為了使架構落地，在技術選型後完成後進行架構構建，包括了定製化設計和開發，並進行質量保證。

架構構建的結果通常分為三個層次：

l         整合環境，提供一個開發的腳手架，這個是最低層次。

l         程式設計模型，提供一個統一的程式設計模型，包含了自定義框架和類庫，並對底層技術提供了一定封裝和隱藏。當前的趨勢是：提供一個POJO一致性的程式設計模型。

l         執行平臺，提供了一個執行平臺，（勉強）可以算做一箇中介軟體產品。

 

架構構建過程中應注意如下內容：

l         應用區分平臺系統和應用開發介面

應用開發介面是給後續產品開發使用，介面一旦設計釋出應當保持問題性和相容性；而平臺系統對後續系統開發不可見，避免相容設計成本，有利後續升級和變化。

l         簡單的API，強大的功能，類似於高階語言

l         可以擴充套件的SPI，另一種形式的API

l         消除易錯機制（error-prone mechanism），避免當錯誤使用後的修正成本太高

l         適應變化和二八原則，避免在需求變化時後調整的成本過高

l         隔離具體技術，保持未來的遷移性和可升級性

l         提供呼叫介面和模型應具備一定抽象性

l         分離關注點，縱向的層次化抽象，以及橫向的模組與切面

l         提供申明式定義（如XML），由反向解析對映到具體技術，關注於做什麼而非怎麼做。

 

架構完成構建後，進入架構評估。

架構評估是確保架構有效性的重要步驟，需要針對所收集到的非功能性需求——工作上形成一個閉環，確保工作的有效性——因為架構涉及系統中最重要的20%，應該儘早驗證，而不是簡單地希望一切都好。

架構評估包括兩個工作：進行驗證和協助。

可以根據非功能性需求列表來制定驗證點，這裡列舉下主要的驗證點：

l         技術點驗證

l         效能壓力驗證

l         穩定性驗證

更正規的評估方法可以參考《Attribute Based Architectural Evaluation》。

 

協助是架構評估的另一項工作。架構不是幾個人關在一個房間裡整出來的與世隔絕的東西。需要專案/系統/產品的等相關利益者理解它。這項工作不應是釋出幾份文件宣稱架構如此如此（見後續《架構釋出》），它應當在架構評估時進行（雖然可以在架構構建時進行，但是由於此時架構並未成形，此時的效果有限）。

架構釋出 

當架構構建完成並通過評估，架構就可以正式釋出了。

框架/平臺和工具

毫無疑問，框架/平臺和工具是架構釋出主要內容之一。

文件

除去框架框架/平臺和工具，還有其他重要的內容需要釋出，文件無疑必須的。但文件也存在尷尬的情況，已知的工程實踐中已經發布了太多無用的文件、過期的文件。

應努力保證所釋出文件的必要性和有效性，建議文件如下：

l         架構介紹，可以參考RUP4+1檢視，部署檢視、執行檢視、開發檢視等

l         快速入門

l         開發指南

l         服務配置和使用介紹

示例程式碼

完整可用的程式碼，執行指令碼、註釋。完整豐富的示例程式碼在很多時候比文件更直接，尤其在展示細節問題上。

培訓和指導

很多時候，培訓和指導被忽略了。相對於文件和示例程式碼，培訓和指導更有互動性，可以更深入討論，並可以深入到架構設計背後的故事。

架構改進 

如前所述，通常無法一次收集完整地非功能性需求；而隨著時間發展，更新更細節的非功能性需求會不斷的湧現和被發現；還有一部分之前已識別但被暫時擱置的非功能性需求開始變得重要。因此架構需要不斷髮展，而此時的改進通常是以小步快跑的方式進行。

 

下一個週期 

不能期望10年前的架構能夠滿足今天的需求（它可能依然可以工作）。架構釋出後到一定階段，已經無法通過小的改進滿足新的要求，重新進行架構設計成為一個必然。而當前的架構設計可以轉為下一次設計的基線。

常見的問題 

l         試圖建立一個私有的程式設計模型標準

很少有人這麼幹，不過有時還遇到這樣的做法。通常在封裝一些商業或開源產品，美名其曰——隔離實現，這是一個危險的做法，其實質是建立一個私有程式設計模型標準，如果業界沒有紙上標準或實際標準，基於某個產品實現所建立的私有標準無法真正的遷移到別的產品實現；如果有，那就根本不需要建立私有標準。

另有一種封裝，其目的是為了簡化商業或開源產品，這種封裝不打算遮蔽底層的實現——它只是讓工作更簡單。

如果一定要建立一個程式設計模型的話，應該是POJO。

l         不那麼正確的二八原理

二八原理通常很有效，然而它有缺陷——他是基於統計的，這意味著是事後應對。如果沒有已有實踐經驗，那麼在一開始很難做出正確判斷。

而一旦做出錯誤的決策導致的問題，很可能出現“玻璃裂紋”現象——不斷的擴散並破壞架構設計——直到玻璃碎掉。

更槽糕的是，很多時候所謂的二八劃分，基於的是感覺而非統計。

l         過分關注在技術模型上

雖然架構針對的非功能性需求，關注在技術模型沒有問題，但是實際上更應關注的是資訊模型。而在多數情況下，資訊模型是以層的形式來表示。

這裡面最典型的是所謂的N層（n-tier）模型，實際上，N層（n-tier）模型就是一個技術模型，描述的一個分散式系統結構。

而真正的N層（n-layer）設計卻被忽視，分層Layer模式才是一個架構模式（見POSA vol1），ISO-7層網路協議是一個典型示例。