作業: 說明分佈
這項作業依據實體節點及其交互作用,定義分散式系統的部署架構。
規範: 分析 設計
目的
說明系統的功能如何分散到多個實體節點上。這項作業只適用於分散式系統。
關係
角色主要執行者: 其他執行者:
輸入強制: 選用:
輸出
流程用法
主要說明

這項作業依據實體節點及其交互作用,定義系統的部署架構。 在作業:架構分析期間,會定義起始的部署模型。在這項作業中,將要修正「部署模型」(亦即部署觀點),以反映最新的設計。

在「詳述」階段的早期,部署觀點通常極為原始,但是到「詳述」階段的後期時,部署觀點應該已經完備定義。

步驟
分析分散需求
目的 定義系統需要的分散範圍。 

分散需求是由以下驅動:

  • 問題領域(功能需求)中的分散要求 - 系統可能有明確的需求,需要存取或使用特定的分散式處理器、資料庫或舊版系統,來執行它的部分功能。
  • 選擇的部署配置 - 特定的部署配置會因為定義了節點及交互作用的數目和類型,而限制了系統的分散方式。例如,選擇多層部署配置時,通常是表示您有一個用戶端節點、一個 Web 伺服器節點以及一個應用程式伺服器節點。特定的部署配置通常是在作業:架構分析期間選擇,並在這項作業期間加以修正。
  • 必要的資源(非功能需求) - 費時或耗費大量運算的功能,很可能需要特定的硬體配置,尤其是要用來處理功能方面的需求時尤然;例如,需要快速的處理器、大量 RAM,或是大量磁碟空間。其範例如數位訊號處理,這種處理需要特殊且專用的處理器。 
  • 容錯能力(非功能需求) - 需求可能要求儲備備用處理器。
  • 延展性及彈性考量(非功能需求) - 任何一個處理器都無法支援過多的大量並行使用者。因此可能需要維持系統功能的負載平衡,以提供最高的效能和延展性。
  • 經濟效益考量 - 較小型且價廉的處理器效能不能和較大型模型相比。

和許多架構問題一樣,這些需求之間可能會互斥。但在一開始時,有互相衝突的需求存在並非不尋常。依重要性將需求區分等級,會有助於解決衝突。

定義網路配置
目的 定義網路的配置與拓樸。 

在這個步驟中,會修正起始的部署模型(在作業:架構分析中定義),以支援在前一個步驟指出的分散需求。

網路的拓樸,以及網路上的處理器及裝置的功能和特性,會決定系統可以分散的本質和程度。

以下是必須擷取的資訊:

  • 網路的實際佈置,包括其位置
  • 網路上的節點,以及各節點的配置和功能(配置包括節點上安裝的軟硬體、處理器數目、磁碟空間數量、記憶體數量交換數量等等)- 節點上安裝的硬體可以用裝置代表
  • 網路上的每個區段頻寬
  • 存在網路上的任何冗餘路俓(這會有助於提供容錯能力)
  • 節點的主要用途,包括:
    • 使用者用的工作站節點
    • 進行無監視器型處理程序的伺服器節點(為簡化伺服器配置,可以將伺服器元件封裝在無監視器型的影像中,其中包含無使用者介面元件)
    • 用於進行開發及測試的特殊配置
    • 其他專用的處理器
  • IP 設計與機能(例如 DNS、VPN),若有 IP 網路存在的話
  • 網際網路在解決方案中扮演的角色

範例

下圖顯示 ATM 的「部署觀點」

ATM 部署觀點圖

ATM 部署觀點

圖解中包含兩個節點(ATM 本身,這是此範例的焦點)和 ATM 網路伺服器,所有通往銀行內部網路的連線都是透過這部伺服器。雖然「ATM 網路伺服器」是超出 ATM 的建立範圍,在這裡將其顯示出來的原因,是要彰顯如何記錄網路的頻寬。圖解也會顯示在 ATM 節點上執行的程序與執行緒,這會在下一個步驟配置系統元素給節點中討論。

請注意使用註解來記錄處理器和網路容量。此種文件也可以放在節點(或裝置)的文件欄位中,在此情況下,此文件就不會顯示在圖解中。

配置系統元素給節點
目的  分散系統的工作量。 

在這個步驟中,會配置系統元素給在上一個步驟定義的節點。部署可以從邏輯角度及實體角度來說明。

邏輯部署是將邏輯元素(類別、子系統,或這些元素的實例)對映到節點。這些元素可以包括控制緒。例如,邏輯部署可能會指出要將 AuctionManager 子系統部署至應用程式伺服器。

實體部署是將檔案對映至節點。例如,實體部署可能會指出要將 CloseAuctionTimer.class 檔部署到 server76。

分散情況會造成總計可能並且通常是小於各個部分的總計。若要獲得分散的實際好處,需要努力和審慎的規劃。在決定要將哪些元素對映到哪些節點時,請注意如下事項:

  • 節點容量(就記憶體和處理功力而言)
  • 通訊媒體頻寬(匯流排、LAN、WAN)
  • 硬體及通訊鏈結、重新遞送的可用性
  • 冗餘及容錯需求
  • 回應時間需求
  • 通訊量需求

配置元素給節點時,是為了縮減通過網路的傳輸數量;需要進行大量互動的元素,應該要放置在相同的節點上;而互動較少的元素,則可以位在不同的節點上。最重要,並且通常需要反覆進行的決策,是要如何區分。將處理作業分散到兩個以上的節點時,需要詳細審查系統中的跨程序通訊型樣。一般都認為分散處理程序,可以將某部機器上的工作負荷移到另一部機器。但在實際情況中,如果沒有審慎考量程序和節點的界線,額外的跨程序通訊工作量卻很可能會抵銷分散工作量所帶來的好處。

範例

前一個範例圖解 ATM 部署觀點顯示 ATM 節點將程序配置給節點。其中有一個程序 (ATM Main),此程序包含三個不同的控制緒(客戶介面、ATM 網路介面以及裝置控制器)。

有些環境會提供機制來自動化及/或簡化分散作業。例如:

  • 叢集:叢集是指一組視同一個單元行動的一組伺服器,通常會包括如失效接手及負載平衡功能。在此情況下,「部署觀點」就應該說明如何將系統元素配置給叢集,以及如何配置叢集,使其對映至實體節點。
  • 儲存器:在諸如 J2EE、Microsoft .NET 等等的元件環境中,在邏輯運算環境中執行的元件,就稱為儲存器。儲存器可以想成是「邏輯節點」。部署觀點應該說明如何將系統元素部署到儲存器,以及如何配置儲存器給實體節點。

這種支援分散機制的用法,以及必須如何配置及對映至實體節點,以符合分散需求,應該記錄作為「部署觀點」的一部分。

詳細資訊