Microsoft 體繫結構概述

來源:互聯網
上載者:User
Microsoft 體繫結構概述
Michael Platt
Microsoft Corporation

目錄
  • 企業體繫結構
  • 應用程式和技術體繫結構
  • 概念、邏輯和物理視圖
  • 應用程式體繫結構
  • 應用程式模式
  • 技術體繫結構
  • 技術模式

本文的目標讀者是那些希望理解 Microsoft 在企業、應用程式和技術體繫結構方面提供的方法的商業、軟體和基礎設施體繫結構設計師。它包括體繫結構的術語、模式、概念和定義,以及體繫結構的一系列視圖。

企業體繫結構

ANSI/IEEE Std 1471-2000 中使用的體繫結構定義是:“一個系統的基主要組織,表現為系統的組件、組件之間的相互關係、組件與環境之間的相互關係以及設計和進化的原理。”

企業體繫結構 (EA) 是協助組織理解自己的結構及其原理的概念工具。它提供了企業的結構圖,是業務和技術變化的規劃工具。

一般來說,企業體繫結構表現為一整套相互關聯的模型,這些模型描述了企業的結構和功能。企業體繫結構主要用於系統化的 IT 規劃和架構,以及改進的決策過程。

EA 中的各個模型以邏輯方式來排列,可以使企業的詳細資料處於不斷增長中,包括:

  • 目的和目標。
  • 過程和組織。
  • 系統和資料。
  • 使用的技術。
Microsoft 體繫結構剖析

企業體繫結構中的資訊可以從不同角度來審視,並且可以滿足各種需要。體繫結構的使用者包括業務經理和分析員、系統體繫結構設計師、工作流程和程式分析員、後勤專家、組織分析員等。這些人員要求有進階的概括資訊、詳細的資料和各種層級的中間資料。這些需要通過建立概念視圖、邏輯分析和物理實現來滿足。

在 Microsoft,我們發現了四個重要並且常用的基本審視角度。它們是業務、應用程式、資訊和技術角度。

業務角度

“業務角度”描述了業務的運作方式。它包括廣泛的商業策略,以及為了將組織從目前狀態推進到構想的未來狀態而做的計劃。一般包括以下內容:

  • 企業的進階目標。
  • 整個企業或企業的重要部分實施的業務過程。
  • 執行的業務功能。
  • 主要的組織圖。
  • 各元素之間的相互關係。
應用程式角度

“應用程式角度”定義了企業的資產應用,以應用程式為中心。一般包括下列內容:

  • 有關支援業務過程的自動服務的描述。
  • 有關組織中應用程式系統的相互作用和相互依賴(介面)的描述。
  • 根據企業目標開發新應用程式和改造舊應用程式,以及發展技術平台的計劃。

應用程式角度可表示跨組織的服務、資訊和功能,串連具有不同技能和技術的使用者以便達到共同的營運目標。

資訊角度

“資訊角度”描述了組織在業務處理和運作過程中需要知道的資訊。包括下列內容:

  • 標準資料模型。
  • 資料管理策略。
  • 組織中資訊產生和使用的模式說明。

資訊角度還描述了資料與工作流程關聯的方式,包括整個組織中存在的結構化資料存放區(如資料庫)和非結構化資料存放區(如文檔、試算表和簡報等)。

技術角度

“技術角度”對組織提供硬體和軟體支援。它包括但不僅限於:

  • 台式機和伺服器硬體。
  • 作業系統。
  • 網路連接組件。
  • 印表機。
  • 數據機。

技術角度對支援應用程式和資訊角度所需的基礎設施和系統組件提供了邏輯化的、獨立於供應商的描述。它定義了一套完成業務所需的技術標準和服務。

儘管有許多角度,但是從這些角度看到的只是一個企業體繫結構。企業體繫結構的價值不在於任何一個單獨的角度,而在於各角度之間的相互關係、相互作用和相互依賴。

儘管所有角度都是企業體繫結構的關鍵元素,本文仍將集中討論應用程式和技術角度。

應用程式和技術體繫結構

軟體系統的“功能”需求描述了軟體提供的商業價值。對於天氣預報服務來說,功能需求可以描述為“將組織良好的資訊 A 作為輸入,服務將返回對於資訊 A 所表示的時間跨度和地理位置來說正確的資訊 B”。

“應用程式體繫結構”是自動服務的體繫結構,用於支援和實現這樣的業務需求,包括該業務與其他應用程式之間的介面。它描述了應用程式的結構,以及該結構如何?組織的功能需求。雖然在理想情況下,一個組織應該只有一個應用程式體繫結構,但實際上,一個組織往往會有許多不同的應用程式體繫結構。

軟體系統的“運作”需求定義了軟體的可靠性、可管理性、效能、安全性和互通性等。常見的例子是僅對授權使用者開放的服務,這種服務需求在 99.999% 的時間內都能正確實現它的功能。

“技術體繫結構”是支援組織以及實現運作(非功能)需求(尤其是組織的應用程式和資訊體繫結構)的硬體和軟體基礎設施的體繫結構。它描述了所使用技術的結構和內部關係,以及這些技術如何支援組織的運作需求。

好的技術體繫結構可以提供安全性、可用性和可靠性,還可以支援各種其他運作需求。但是如果應用程式的設計沒有利用技術體繫結構的優點的話,它的執行效果會很差,或者會難以部署和運作。同樣,即使一個優秀的應用程式體繫結構是通過使用最新的技術、利用可重用軟體組件來構建的,能很好地滿足業務過程的需求,它也可能不能很好地反映實際的技術配置,例如:伺服器沒有經過正確配置來支援應用程式組件,網路硬體設定不能支援資訊流等。這顯示了應用程式體繫結構和技術體繫結構之間的相互關係:一個好的技術體繫結構能夠支援組織中關鍵的應用程式,而一個好的應用程式體繫結構能夠充分利用技術體繫結構,在整個運作需求中提供一致的效能。

圖 1:體繫結構之間的關係

概念、邏輯和物理視圖

所有體繫結構角度都有多種體繫結構視圖,通常分為概念、邏輯和物理視圖。“概念視圖”是最抽象的視圖,一般用系統使用者(非 IT 專業使用者)熟悉的術語來描述。概念視圖用於定義應用程式的功能需求和商業使用者視圖,以便產生業務模型。“邏輯視圖”顯示了主要的功能組件和它們在系統中的關係,而不涉及功能的實現細節。體繫結構設計師建立的“應用程式模型”就是業務模型的邏輯視圖,因為它們決定了如何滿足營運目標和需求。應用程式模型表示應用程式體繫結構的邏輯視圖。“物理視圖”是最不抽象的,它們表示特定的實現組件和它們之間的關係。物理視圖中的每個元素一般都由設計和開發過程來實現,如軟體和硬體系統。“實現視圖”通常歸組織的開發或運作部門管理,因此不在本文的討論範圍內。

圖 2:體繫結構視圖

每一個體繫結構層級均可能有(事實上通常都會有)多個視圖,例如,每個應用程式通常都會有一個邏輯應用程式程式體繫結構。

這些視圖由一組需求來驅動,反過來又會產生設計、開發、配置和運作過程及系統的輸入。

圖 3:體繫結構視圖和模式

本指南的其餘部分將集中討論應用程式和技術體繫結構,以及利用 Web 服務技術構造基於服務的應用程式的概念和關鍵模式。雖然實現部分(包括設計、開發、配置、部署和管理)對於總體系統的產生十分重要,但是不在本文的討論範圍內。

應用程式體繫結構

如前所述,應用程式體繫結構提供了三種視圖:概念、邏輯和物理視圖。體繫結構設計師可以使用這些視圖在組織中產生支援和滿足其業務需求的模型。理想情況下,每個視圖只有一個模型,但實際上每個視圖可能有多個模型,這是由於組織和技術在不斷成長和改變。然而,是否能得到這些模型的合理的最小集合是組織是否靈活、高效的關鍵。

概念視圖

概念視圖用於定義應用程式的業務需求和商業使用者視圖,以便產生“業務模型”。概念性建模技術(如用例分析、活動圖表解、過程設計和業務實體建模等)有助於構建關鍵業務過程及其使用的資料的描述,可以強調營運目標和需求,並且不包含實現技術。

邏輯視圖

體繫結構設計師建立的“應用程式模型”就是業務模型的邏輯視圖,因為它們決定了如何滿足營運目標和需求。應用程式模型表示應用程式體繫結構的邏輯視圖。

體繫結構設計師關心的是應用程式的總體結構。他們決定資料管理和處理步驟的對應關係,根據邏輯資訊和順序設計模型組件之間的互動,並確定模型保留的資料類型和狀態。

物理視圖

應用程式模型的每個元素均要求映射到真正的技術元素。通過這種方法,應用程式模型以“實現模型”的方式得以實現。當程式員將詳細的商務邏輯編寫成代碼時,常規的開發過程承擔了部分實現任務,但大部分實現活動應歸為架構完成。架構完成是一種開發技術,大多數分布式應用程式和資料管理的基礎設施都是由複雜的架構處理的,而這些架構由自訂的應用程式邏輯和公布的控制項結構進行了擴充。架構完成使開發人員避免了繁瑣的工作(例如錯綜複雜的非同步訊息處理),使普通開發人員能夠對項目作出更大的貢獻。

為組織規劃和構建不同層級的模型是一項相當費時費力的工作。而且,能否正確定義這些模型對於組織來說也是至關重要的。體繫結構模型的設計錯誤總是會導致嚴重的設計問題或運作問題(例如延展性和可靠性問題),嚴重時甚至會導致項目無法完成以及影響業務。體繫結構設計師正在尋找架構和指南以協助他們建立和實現這些模型,並把由於使用錯誤模型而帶來的風險降到最低。

體繫結構設計師可以使用兩種體繫結構指南和協助來加快建模速度和降低風險。

第一是一組體繫結構概念,它們提供:

  • 一般的理解和通訊。
  • 關於如何以及何時使用某個概念的指南,以及有關其屬性的資訊。
  • 根據這些指南或實際的技術,何時可以實現和使用這些概念的指示。

第二是一組模式,基於大量成功的分布式應用程式的實際經驗,由這些基本概念組成。這些模式通過提供優秀的、經過測試的體繫結構模型,封裝了重要的最佳分布式應用程式設計執行個體,並且能使項目失敗的風險降到最低。

圖 4:應用程式體繫結構的視圖

這兩組指南(概念和模式)在概念級(它們是企業模型概念和模式)、邏輯級(它們是應用程式概念和模式)和技術級都有對應的指南。提供這些概念和模式對於在組織中成功、快速和高效地實現系統以及採用技術是十分關鍵的。

應用程式體繫結構:概念視圖

過去,應用程式的構建是通過整合本地系統服務(如檔案系統和裝置驅動程式)來實現的。這種模型在訪問豐富的開發資源以及精確控制應用程式的行為方面提供了很大的靈活性,但同時也容易出錯、成本較高並且較為費時。

現在,可以通過整合整個網路上現有的應用程式和服務,然後使用諸如業務實體、資料實體和其他方面在其上提供獨特的附加價值,來構造複雜的分布式應用程式。這就使開發人員能夠將注意力集中於提供獨特的業務價值,從而減少進入市場的時間,提高開發效率,並且最終開發出高品質的軟體。多年來,這一直是一個強大的體繫結構模型,但它產生了“應用程式通風口”或“資訊孤島”,而這在體繫結構重用中會引起重大問題。

現在,我們進入下一個計算階段。這個階段通過 Internet 和 Web 服務概念來實現,能夠建立可以隨時隨地使用的強大的應用程式。它增加了應用程式的應用範圍,並且可以不斷交付軟體。在這種情況下,軟體即服務 - 一種通過通訊網路來訂購和使用的服務。

.NET 通過結合 N 層計算的高效的緊耦合特點以及 Web 以資訊為導向的松耦合概念來推進了這種理念。這種計算方式稱為“XML Web Service”。它代表了下一代應用程式開發技術,並且是概念性應用程式體繫結構的基礎。

Web 服務是應用程式邏輯的有效單元,它們提供了基於訊息的、適合通過網路訪問的介面。通常,服務既提供商務邏輯,也提供與要解決的問題相關的狀態管理。在設計服務時,您的目標是有效地封裝與現實世界中的過程相關的邏輯和資料,對要包括在內的內容和要作為獨立服務實現的內容作出明智的選擇。

狀態處理由商務規則來管理。商務規則是相對穩定的演算法(例如從商品清單匯總出發票的方法),一般是作為應用程式邏輯來實現的。

服務由策略來管理。與商務規則相比,策略的穩定性較差,並且可能是地區性的或針對特定客戶的。策略一般是通過在運行時查閱表格來驅動的。

因此,服務的更完整的定義應該是:“服務是能在網路上啟動並執行軟體單元,它通過訊息來實現邏輯、管理狀態和通訊,並且由策略來管理。”

應用程式的概念視圖在 Application Architecture: Conceptual View(英文)中有詳細介紹。

應用程式模式

模式是問題在環境中的解決方案。模式將從某個領域內收集的特定知識整理成文。應用程式模式是體繫結構級的模式,它定義了體繫結構設計在特定應用程式環境中的最佳執行個體。

模式有許多種分類法可以作為特定模式的定義和解釋,但不在本文的討論範圍內。許多現有的體繫結構模式都可以應用到基於 Web 服務的體繫結構中,但在 Web 服務的新結構還帶來了大量新的模式。

技術體繫結構

與應用程式體繫結構相似,技術體繫結構也提供了三種視圖:概念、邏輯和物理視圖。體繫結構設計師可以使用這些視圖在組織中產生支援和滿足其運作需求的模型。就象應用程式一樣,應當只有一個技術體繫結構,但實際上由於組織和技術在不斷成長和改變,幾乎總是存在多個技術體繫結構。組織的一個關鍵需求是將這些完全不同的技術體繫結構整合到一個完整的體繫結構中,以便重用現有的應用程式,並使這些技術體繫結構達到合理的最小集合。這樣一個公用的體繫結構對於建立高效、靈活的組織是至關重要的。

概念視圖

技術體繫結構的概念視圖用於將技術領域制定為結構和架構。它用於定義、命名和定位 IT 供應商和使用技術的組織都能理解的領域,確保在實現組織的運作或非功能性需求時所需的所有技術領域都得到定義並可供組織使用。

邏輯視圖

技術體繫結構的邏輯視圖是主要的功能元素,它們提供對企業級運作需求的支援,並提供相互之間的內部關係。企業技術元素(例如資料庫、郵件系統、交易支援和可靠的訊息傳送)是在邏輯視圖中提供的。在這個層級上提供的技術通常由企業軟體供應商與伺服器一起提供。

物理視圖

技術體繫結構的每個元素均需要映射到硬體和軟體的實際技術元素上。通過這種方法,技術體繫結構可以實現為網路、伺服器、作業系統等的完整系統。實際的物理位置、伺服器產品名稱和串連都顯示在這個層級上。

體繫結構設計師正在從 IT 供應商處尋找架構和指南,以協助他們構建能滿足組織運作需求的系統,並確保組織的技術與 IT 供應商的技術相一致。

技術體繫結構:概念視圖

技術概念體繫結構是在組織中建立企業級 Web 服務的技術基礎。技術概念體繫結構的進階圖表顯示了一組一般的層級,為 Web 服務的產生提供了基於企業的服務。這些層級包含 Web 服務應用程式或系統所需的公用元素。

圖 5:技術體繫結構的概念視圖

圖表的底部是“服務平台”,它提供了作業系統、硬體、儲存、連網以及整個系統的信任和管理服務。

“服務架構”提供基於 Web 服務的應用程式所需的過程、邏輯、功能和狀態管理,也是專門支援 Web 服務的完整的公司專屬應用程式程式伺服器。

“服務傳遞”包含門戶和用戶端服務,主要用於提供問題和技術,包括對各種裝置的支援。

“服務整合”提供了服務與以下現有作業系統之間的整合和互操作:舊應用程式、商用應用程式、資料庫和其他 Web 服務。這通常稱為企業應用程式整合 (EAI)。

最後,“服務建立和部署”提供了設計、開發、組裝、管理、部署和測試 Web 服務所需的工具、過程、方法和模式。

技術體繫結構的概念視圖在 Technology Architecture: Conceptual View(英文)中有詳細介紹。

技術模式

技術模式是體繫結構級的模式,它定義了體繫結構設計在特定應用程式環境中的最佳執行個體。企業體繫結構設計師正在為組織尋找以下關鍵領域的指南和最佳執行個體:

  • 安全性、身份識別和信任。
  • 未來系統和現有操作(舊的)系統之間的整合和互操作。
  • 部署、監控和管理。
  • 分布式技術體繫結構的延展性和效能。
  • 技術體繫結構的可靠性和可用性

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.