在現代軟體架構中，理解程式碼如何與實體基礎設施互動至關重要。UML 部署圖為此互動提供了藍圖。它可視化軟體組件所存放的實體節點及其通訊方式。本指南探討部署圖的運作原理、符號表示與實際應用，不依賴特定工具或行銷誇飾。
🧩 什麼是部署圖？
部署圖是統一模型語言（UML）中的一種靜態結構圖。它描述了系統的實體架構。與專注於邏輯的類圖，或專注於流程的序列圖不同，部署圖專注於拓撲結構。它回答組件存放位置的問題。
- 硬體表示： 伺服器、路由器、工作站與行動裝置。
- 軟體表示： 可執行檔、程式庫、資料庫與作業系統。
- 連線： 使這些實體能夠交換資料的網路連結。
此圖表作為開發人員、系統架構師與運營團隊之間的溝通橋樑。它確保各方在實施前對環境達成共識。
🔑 關鍵元件與符號
要有效閱讀或建立這些圖表，必須理解 UML 規範中使用的標準符號。這些符號具有普遍性，不依賴專有軟體。
🖥️ 節點（計算資源）
主要的構建模塊是 節點。在 UML 符號中，節點以一個三維立方體表示。它代表可託管組件的計算資源。
- 裝置： 一種實體硬體裝置的節點。範例包括筆電、伺服器或行動電話。
- 執行環境： 提供執行環境的節點。範例包括作業系統、虛擬機器或資料庫管理系統。
- 組件： 軟體的實體表示。包括可執行檔、檔案或資料儲存。
📄 組件
組件是部署到節點上的軟體項目。它們以文件圖示（帶有折角的矩形）表示。
- 可執行檔： 在伺服器上執行的編譯後程式碼。
- 程式庫： 應用程式所需的共用程式碼模組。
- 資料庫： 存儲結構位於特定節點上。
- 設定檔： 定義軟體在該環境中行為的設定。
🔗 通訊路徑
節點必須互相通訊才能作為一個系統運作。連接它們的線條代表通訊的媒介。
- 關聯： 一條簡單的線，表示連接存在。
- 依賴： 一條虛線搭配箭頭，表示一個節點需要另一個節點。
- 訊息傳遞： 一個箭頭，顯示資料傳輸的方向。
🛠️ 建構模組：節點與實體
構建圖表需要仔細選擇節點與實體。細緻程度至關重要。細節過多會造成混亂；過少則會產生模糊。
實體節點與邏輯節點
部署圖表可以在兩個抽象層級上檢視。
- 實體： 代表實際的硬體。你可能會看到特定的機架伺服器、防火牆設備或客戶端工作站。
- 邏輯： 代表功能性的分組。你可能會看到「Web層」或「資料層」，但不需指定具體硬體。
選擇合適的層級取決於觀眾。運營團隊需要實體細節，開發人員可能更傾向於邏輯分組。
將實體對應到節點
實體必須放置在它所佔據的節點上。這種關係通常以實線或嵌套關係來表示。實體被繪製在節點內部或與其連接。
考慮一個標準的網頁應用程式結構：
- Web伺服器節點： 主機存放 HTML 檔案、CSS 與 JavaScript。
- 應用程式伺服器節點： 主機存放後端邏輯（例如 Java 壓縮檔或 Python 程式碼）。
- 資料庫伺服器節點： 主機存放 SQL 檔案或 NoSQL 資料儲存。
🔗 連接與依賴
連接性定義了系統的功能。節點之間的線條不僅僅是線條；它們代表協定和限制。
網路協定
雖然UML不會強制要求在線條上標示協定名稱，但最佳實務是進行標示。這能清楚說明資料如何傳輸。
| 連接類型 | 常見協定 | 使用案例 |
|---|---|---|
| HTTP/HTTPS | 網頁請求 | 瀏覽器至伺服器 |
| SQL/JDBC | 資料庫查詢 | 應用伺服器至資料庫伺服器 |
| Socket/SSH | 安全殼層 | 管理員至伺服器 |
| 檔案傳輸 | FTP/SFTP | 備份系統 |
依賴關係
並非所有連接都相同。依賴關係表示來源節點無法在沒有目標節點的情況下運作。例如，應用伺服器依賴資料庫伺服器。如果資料庫停止運作，應用程式將無法處理交易。
📝 分步建構指南
建立部署圖需要有系統性的方法。遵循以下步驟以確保準確性和清晰度。
1. 確定範圍
定義系統的邊界。您是在繪製整個企業系統，還是僅針對特定的微服務？範圍決定了細節層級。
2. 資源清單（硬體）
列出所有涉及的實體裝置。包括：
- 應用伺服器
- 負載平衡器
- 防火牆
- 客戶端裝置
- 網路交換器
3. 軟體資產清單
列出需要部署的軟體組件。包含：
- 作業系統版本
- 中介軟體（例如：Web 伺服器軟體）
- 應用程式可執行檔
- 資料庫執行個體
4. 定義關係
繪製連接節點的線條。若已知，請指定通訊協定。確保箭頭指向主要資料流的方向。
5. 檢查完整性
確認每個資產都有明確的歸屬。確認每個節點都邏輯上與網路其他部分連接。確認安全區域已正確呈現。
🎨 視覺標準與佈局
如果無法閱讀，圖表就毫無用處。遵循視覺標準能提升理解度。
- 一致性：在圖表中，為類似節點使用相同的圖示風格。
- 間距：在節點之間留白，以避免線條重疊。
- 分組：使用子節點或邊界來分組相關組件。
- 標籤：保持標籤簡潔。如需較長描述，可使用文字方塊。
安全區域
安全性是部署中的關鍵要素。使用邊界來標示安全區域。
- 公開區域：可從網際網路存取。包含負載平衡器和 Web 伺服器。
- DMZ（非軍事區）：半信任。包含代理伺服器或閘道。
- 內部區域：信任。包含資料庫與後端邏輯。
呈現這些區域有助於安全團隊識別架構中的潛在弱點。
🚫 需避免的常見陷阱
即使是經驗豐富的架構師也會犯錯。避免這些常見錯誤，以維持圖表的完整性。
- 過度複雜化：將每個微服務都包含在單一圖表中會導致圖表無法閱讀。應根據功能或層級拆分圖表。
- 忽略延遲：未能顯示網路距離。本地資料庫與遠端雲端資料庫不同。
- 靜態狀態：部署圖會變動。當基礎設施變更時，務必更新圖表。過時的圖表比沒有圖表更糟糕。
- 遺漏硬體：僅關注軟體。硬體限制（CPU、記憶體）通常決定了軟體的表現。
- 標籤不清：使用觀眾不理解的縮寫。如有必要，應定義術語。
☁️ 雲端與本地部署的表示方式
現代架構通常涉及混合環境。表示雲端資源需要特別考慮。
雲端節點
在雲端環境中，硬體被抽象化。「伺服器」可能是一個虛擬實例。
- 虛擬機：以帶有雲端圖示或標籤的節點表示。
- PaaS（平台即服務）：以執行環境表示，不指定作業系統。
- SaaS（軟體即服務）：以透過網路存取的外部實體表示。
網路拓撲
雲端圖表通常包含區域與可用性區域。
- 區域：包含多個資料中心的地理區域。
- 可用性區域：區域內的獨立資料中心。
呈現這些內容可確保系統設計具備冗餘與災難恢復能力。
🔄 與其他 UML 模型的整合
部署圖並非孤立存在。它會與其他UML圖表連接，以提供完整的系統視圖。
與類圖的關係
類圖定義了軟體結構。部署圖定義了該結構運行的位置。部署圖中的某個實體通常對應於類圖中的類或套件。
與組件圖的關係
組件圖顯示軟體模組。部署圖顯示物理節點。組件圖會細化部署圖中所發現的「實體」。
與活動圖的關係
活動圖顯示動作的流程。部署圖提供了這些動作發生的背景環境。例如，活動「處理付款」可能發生在「付款伺服器」節點上。
🔍 維護與生命週期
架構並非靜態的。它會隨著需求與技術的演進而發展。
版本控制
與程式碼一樣，圖表也應該進行版本控制。使用與軟體發行版本相符的版本標籤來標記圖表。這使得團隊能在審計時比較舊的與新的架構。
自動化生成
在某些工作流程中，部署圖是從設定檔自動生成的。雖然手動繪製具有彈性，但自動化生成能確保圖表與實際基礎架構狀態一致。然而，這需要嚴格的設定管理。
審查週期
在專案的設計階段納入圖表審查。在撰寫程式碼之前，必須先核准部署計畫。這可避免在硬體錯誤配置後產生昂貴的返工。
📊 符號元素概要
為方便快速參考，以下是此類建模中最常見元素的概要。
| 元素 | 形狀 | 含義 |
|---|---|---|
| 節點 | 立方體 | 硬體或執行環境 |
| 實體 | 文件圖示 | 軟體檔案或資料 |
| 關聯 | 實線 | 物理連接 |
| 依賴 | 虛線 + 箭頭 | 邏輯需求 |
| 邊界 | 帶標籤的矩形 | 安全區域或分組 |
🚀 實際範例情境
考慮一個公司從單體系統遷移到分散式系統的情境。
- 第一階段（單體）：單一伺服器節點同時承載應用程式與資料庫。
- 第二階段（拆分）：應用伺服器節點與資料庫伺服器節點由網路連結分隔。
- 第三階段（雲端）：負載平衡器節點將流量導向跨不同區域的多個應用伺服器節點。
每個階段都需要一個獨特的部署圖。圖之間的轉換記錄了架構的演進過程。
🔐 安全考量
安全不能是事後補救。圖表應反映安全控制措施。
- 防火牆：繪製為過濾區域之間流量的節點。
- 加密：在線條上標註「SSL/TLS」以表示安全通訊。
- 驗證：標註驗證認證金鑰的位置（例如在負載平衡器或應用伺服器上）。
透過可視化安全邊界，架構師可以發現單點故障或未受保護的資料路徑。
📈 可擴展性影響
部署圖有助於規劃成長。
- 水平擴展：增加相同類型的節點。圖中顯示多個相同的節點連接到負載平衡器。
- 垂直擴展：升級單一節點的硬體。圖中可能標註節點的容量限制。
理解這些選項有助於容量規劃。圖表可作為未來擴展的指南。
🤝 協作優勢
最後，這些圖表促進了協作。
- 開發人員： 知道將程式碼部署到哪裡。
- 運營人員： 知道如何配置網路。
- 管理層： 理解基礎設施成本。
共享的視覺語言能減少誤解。它讓團隊對軟體系統的實際物理現實達成共識。
