Microsoft 體系結構概述
Michael Platt
Microsoft Corporation
2002 年 7 月
本文的目標讀者是那些希望理解 Microsoft 在企業、應用程序和技術體系結構方面提供的方法的商業、軟件和基礎設施體系結構設計師。它包括體系結構的術語、模式、概念和定義,以及體系結構的一系列視圖。
ANSI/IEEE Std 1471-2000 中使用的體系結構定義是:“一個系統的基本組織,表現為系統的組件、組件之間的相互關系、組件與環境之間的相互關系以及設計和進化的原理?!?/p>
企業體系結構 (EA) 是幫助組織理解自己的結構及其原理的概念工具。它提供了企業的結構圖,是業務和技術變化的規劃工具。
一般來說,企業體系結構表現為一整套相互關聯的模型,這些模型描述了企業的結構和功能。企業體系結構主要用于系統化的 IT 規劃和架構,以及改進的決策過程。
EA 中的各個模型以邏輯方式來排列,可以使企業的詳細信息處于不斷增長中,包括:
企業體系結構中的信息可以從不同角度來審視,并且可以滿足各種需要。體系結構的用戶包括業務經理和分析員、系統體系結構設計師、工作流程和程序分析員、后勤專家、組織分析員等。這些人員要求有高級的概括信息、詳細的數據和各種級別的中間數據。這些需要通過創建概念視圖、邏輯分析和物理實現來滿足。
在 Microsoft,我們發現了四個重要并且常用的基本審視角度。它們是業務、應用程序、信息和技術角度。
“業務角度”描述了業務的運作方式。它包括廣泛的商業策略,以及為了將組織從當前狀態推進到構想的未來狀態而做的計劃。一般包括以下內容:
“應用程序角度”定義了企業的資產應用,以應用程序為中心。一般包括下列內容:
應用程序角度可表示跨組織的服務、信息和功能,連接具有不同技能和技術的用戶以便達到共同的業務目標。
“信息角度”描述了組織在業務處理和運作過程中需要知道的信息。包括下列內容:
信息角度還描述了數據與工作流程關聯的方式,包括整個組織中存在的結構化數據存儲(如數據庫)和非結構化數據存儲(如文檔、電子表格和演示文稿等)。
“技術角度”對組織提供硬件和軟件支持。它包括但不僅限于:
技術角度對支持應用程序和信息角度所需的基礎設施和系統組件提供了邏輯化的、獨立于供應商的描述。它定義了一套完成業務所需的技術標準和服務。
盡管有許多角度,但是從這些角度看到的只是一個企業體系結構。企業體系結構的價值不在于任何一個單獨的角度,而在于各角度之間的相互關系、相互作用和相互依賴。
盡管所有角度都是企業體系結構的關鍵元素,本文仍將集中討論應用程序和技術角度。
軟件系統的“功能”需求描述了軟件提供的商業價值。對于天氣預報服務來說,功能需求可以描述為“將組織良好的信息 A 作為輸入,服務將返回對于信息 A 所表示的時間跨度和地理位置來說正確的信息 B”。
“應用程序體系結構”是自動服務的體系結構,用于支持和實現這樣的業務需求,包括該業務與其他應用程序之間的接口。它描述了應用程序的結構,以及該結構如何實現組織的功能需求。雖然在理想情況下,一個組織應該只有一個應用程序體系結構,但實際上,一個組織往往會有許多不同的應用程序體系結構。
軟件系統的“運作”需求定義了軟件的可靠性、可管理性、性能、安全性和互操作性等。常見的例子是僅對授權用戶開放的服務,這種服務要求在 99.999% 的時間內都能正確實現它的功能。
“技術體系結構”是支持組織以及實現運作(非功能)需求(尤其是組織的應用程序和信息體系結構)的硬件和軟件基礎設施的體系結構。它描述了所使用技術的結構和內部關系,以及這些技術如何支持組織的運作需求。
好的技術體系結構可以提供安全性、可用性和可靠性,還可以支持各種其他運作需求。但是如果應用程序的設計沒有利用技術體系結構的優點的話,它的執行效果會很差,或者會難以部署和運作。同樣,即使一個優秀的應用程序體系結構是通過使用最新的技術、利用可重用軟件組件來構建的,能很好地滿足業務過程的需求,它也可能不能很好地反映實際的技術配置,例如:服務器沒有經過正確配置來支持應用程序組件,網絡硬件設置不能支持信息流等。這顯示了應用程序體系結構和技術體系結構之間的相互關系:一個好的技術體系結構能夠支持組織中關鍵的應用程序,而一個好的應用程序體系結構能夠充分利用技術體系結構,在整個運作需求中提供一致的性能。
圖 1:體系結構之間的關系
所有體系結構角度都有多種體系結構視圖,通常分為概念、邏輯和物理視圖?!案拍钜晥D”是最抽象的視圖,一般用系統用戶(非 IT 專業用戶)熟悉的術語來描述。概念視圖用于定義應用程序的功能需求和商業用戶視圖,以便生成業務模型?!斑壿嬕晥D”顯示了主要的功能組件和它們在系統中的關系,而不涉及功能的實現細節。體系結構設計師創建的“應用程序模型”就是業務模型的邏輯視圖,因為它們決定了如何滿足業務目標和需求。應用程序模型表示應用程序體系結構的邏輯視圖?!拔锢硪晥D”是最不抽象的,它們表示特定的實現組件和它們之間的關系。物理視圖中的每個元素一般都由設計和開發過程來實現,如軟件和硬件系統?!皩崿F視圖”通常歸組織的開發或運作部門管理,因此不在本文的討論范圍內。
圖 2:體系結構視圖
每一個體系結構級別均可能有(事實上通常都會有)多個視圖,例如,每個應用程序通常都會有一個邏輯應用程序體系結構。
這些視圖由一組需求來驅動,反過來又會生成設計、開發、配置和運作過程及系統的輸入。
圖 3:體系結構視圖和模式
本指南的其余部分將集中討論應用程序和技術體系結構,以及利用 Web 服務技術構造基于服務的應用程序的概念和關鍵模式。雖然實現部分(包括設計、開發、配置、部署和管理)對于總體系統的生成十分重要,但是不在本文的討論范圍內。
如前所述,應用程序體系結構提供了三種視圖:概念、邏輯和物理視圖。體系結構設計師可以使用這些視圖在組織中生成支持和滿足其業務需求的模型。理想情況下,每個視圖只有一個模型,但實際上每個視圖可能有多個模型,這是由于組織和技術在不斷成長和改變。然而,是否能得到這些模型的合理的最小集合是組織是否靈活、高效的關鍵。
概念視圖用于定義應用程序的業務需求和商業用戶視圖,以便生成“業務模型”。概念性建模技術(如用例分析、活動圖解、過程設計和業務實體建模等)有助于構建關鍵業務過程及其使用的數據的描述,可以強調業務目標和需求,并且不包含實現技術。
體系結構設計師創建的“應用程序模型”就是業務模型的邏輯視圖,因為它們決定了如何滿足業務目標和需求。應用程序模型表示應用程序體系結構的邏輯視圖。
體系結構設計師關心的是應用程序的總體結構。他們決定數據管理和處理步驟的對應關系,根據邏輯信息和順序設計模型部件之間的交互,并確定模型保留的數據類型和狀態。
應用程序模型的每個元素均要求映射到真正的技術元素。通過這種方法,應用程序模型以“實現模型”的方式得以實現。當程序員將詳細的業務邏輯編寫成代碼時,常規的開發過程承擔了部分實現任務,但大部分實現活動應歸為框架完成??蚣芡瓿墒且环N開發技術,大多數分布式應用程序和數據管理的基礎設施都是由復雜的框架處理的,而這些框架由自定義的應用程序邏輯和公布的控件結構進行了擴展??蚣芡瓿墒归_發人員避免了繁瑣的工作(例如錯綜復雜的異步消息處理),使普通開發人員能夠對項目作出更大的貢獻。
為組織規劃和構建不同級別的模型是一項相當費時費力的工作。而且,能否正確定義這些模型對于組織來說也是至關重要的。體系結構模型的設計錯誤總是會導致嚴重的設計問題或運作問題(例如可伸縮性和可靠性問題),嚴重時甚至會導致項目無法完成以及影響業務。體系結構設計師正在尋找框架和指南以幫助他們創建和實現這些模型,并把由于使用錯誤模型而帶來的風險降到最低。
體系結構設計師可以使用兩種體系結構指南和幫助來加快建模速度和降低風險。
第一是一組體系結構概念,它們提供:
第二是一組模式,基于大量成功的分布式應用程序的實際經驗,由這些基本概念組成。這些模式通過提供優秀的、經過測試的體系結構模型,封裝了重要的最佳分布式應用程序設計實例,并且能使項目失敗的風險降到最低。
圖 4:應用程序體系結構的視圖
這兩組指南(概念和模式)在概念級(它們是企業模型概念和模式)、邏輯級(它們是應用程序概念和模式)和技術級都有對應的指南。提供這些概念和模式對于在組織中成功、快速和高效地實現系統以及采用技術是十分關鍵的。
過去,應用程序的構建是通過集成本地系統服務(如文件系統和設備驅動程序)來實現的。這種模型在訪問豐富的開發資源以及精確控制應用程序的行為方面提供了很大的靈活性,但同時也容易出錯、成本較高并且較為費時。
現在,可以通過集成整個網絡上現有的應用程序和服務,然后使用諸如業務實體、數據實體和其他方面在其上提供獨特的附加價值,來構造復雜的分布式應用程序。這就使開發人員能夠將注意力集中于提供獨特的業務價值,從而減少進入市場的時間,提高開發效率,并且最終開發出高質量的軟件。多年來,這一直是一個強大的體系結構模型,但它產生了“應用程序通風口”或“信息孤島”,而這在體系結構重用中會引起重大問題。
現在,我們進入下一個計算階段。這個階段通過 Internet 和 Web 服務概念來實現,能夠創建可以隨時隨地使用的強大的應用程序。它增加了應用程序的應用范圍,并且可以不斷交付軟件。在這種情況下,軟件即服務 - 一種通過通信網絡來訂購和使用的服務。
.NET 通過結合 N 層計算的高效的緊耦合特點以及 Web 以信息為導向的松耦合概念來推進了這種理念。這種計算方式稱為“XML Web Service”。它代表了下一代應用程序開發技術,并且是概念性應用程序體系結構的基礎。
Web 服務是應用程序邏輯的有效單元,它們提供了基于消息的、適合通過網絡訪問的接口。通常,服務既提供業務邏輯,也提供與要解決的問題相關的狀態管理。在設計服務時,您的目標是有效地封裝與現實世界中的過程相關的邏輯和數據,對要包括在內的內容和要作為獨立服務實現的內容作出明智的選擇。
狀態處理由業務規則來管理。業務規則是相對穩定的算法(例如從商品清單匯總出發票的方法),一般是作為應用程序邏輯來實現的。
服務由策略來管理。與業務規則相比,策略的穩定性較差,并且可能是區域性的或針對特定客戶的。策略一般是通過在運行時查閱表格來驅動的。
因此,服務的更完整的定義應該是:“服務是能在網絡上運行的軟件單元,它通過消息來實現邏輯、管理狀態和通信,并且由策略來管理?!?/p>
應用程序的概念視圖在 Application Architecture: Conceptual View(英文)中有詳細介紹。
模式是問題在環境中的解決方案。模式將從某個領域內收集的特定知識整理成文。應用程序模式是體系結構級的模式,它定義了體系結構設計在特定應用程序環境中的最佳實例。
模式有許多種分類法可以作為特定模式的定義和解釋,但不在本文的討論范圍內。許多現有的體系結構模式都可以應用到基于 Web 服務的體系結構中,但在 Web 服務的新結構還帶來了大量新的模式。
與應用程序體系結構相似,技術體系結構也提供了三種視圖:概念、邏輯和物理視圖。體系結構設計師可以使用這些視圖在組織中生成支持和滿足其運作需求的模型。就象應用程序一樣,應當只有一個技術體系結構,但實際上由于組織和技術在不斷成長和改變,幾乎總是存在多個技術體系結構。組織的一個關鍵需求是將這些完全不同的技術體系結構集成到一個完整的體系結構中,以便重用現有的應用程序,并使這些技術體系結構達到合理的最小集合。這樣一個公共的體系結構對于創建高效、靈活的組織是至關重要的。
技術體系結構的概念視圖用于將技術領域制定為結構和框架。它用于定義、命名和定位 IT 供應商和使用技術的組織都能理解的領域,確保在實現組織的運作或非功能性需求時所需的所有技術領域都得到定義并可供組織使用。
技術體系結構的邏輯視圖是主要的功能元素,它們提供對企業級運作需求的支持,并提供相互之間的內部關系。企業技術元素(例如數據庫、郵件系統、交易支持和可靠的消息傳送)是在邏輯視圖中提供的。在這個級別上提供的技術通常由企業軟件供應商與服務器一起提供。
技術體系結構的每個元素均需要映射到硬件和軟件的實際技術元素上。通過這種方法,技術體系結構可以實現為網絡、服務器、操作系統等的完整系統。實際的物理位置、服務器產品名稱和連接都顯示在這個級別上。
體系結構設計師正在從 IT 供應商處尋找框架和指南,以幫助他們構建能滿足組織運作需求的系統,并確保組織的技術與 IT 供應商的技術相一致。
技術概念體系結構是在組織中建立企業級 Web 服務的技術基礎。技術概念體系結構的高級圖表顯示了一組一般的級別,為 Web 服務的生成提供了基于企業的服務。這些級別包含 Web 服務應用程序或系統所需的公共元素。
圖 5:技術體系結構的概念視圖
圖表的底部是“服務平臺”,它提供了操作系統、硬件、存儲、聯網以及整個系統的信任和管理服務。
“服務框架”提供基于 Web 服務的應用程序所需的過程、邏輯、功能和狀態管理,也是專門支持 Web 服務的完整的企業應用程序服務器。
“服務傳遞”包含門戶和客戶端服務,主要用于提供問題和技術,包括對各種設備的支持。
“服務集成”提供了服務與以下現有操作系統之間的集成和互操作:舊應用程序、商用應用程序、數據庫和其他 Web 服務。這通常稱為企業應用程序集成 (EAI)。
最后,“服務創建和部署”提供了設計、開發、組裝、管理、部署和測試 Web 服務所需的工具、過程、方法和模式。
技術體系結構的概念視圖在 Technology Architecture: Conceptual View(英文)中有詳細介紹。
技術模式是體系結構級的模式,它定義了體系結構設計在特定應用程序環境中的最佳實例。企業體系結構設計師正在為組織尋找以下關鍵領域的指南和最佳實例: