在系統架構領域，將軟體的物理現實可視化，與定義其邏輯結構同等重要。部署圖提供了這種物理視圖，映射軟體組件所存在的硬體拓撲結構。本文檔概述了使用此建模技術規劃基礎設施佈局的權威方法，確保程式碼與運算資源之間的對齊。
💡 主要要點
- 物理映射：部署圖彙集了軟體組件與執行它們的硬體之間的差距。
- 節點抽象：使用節點來代表處理資源，與其上運行的組件區分開來。
- 通訊路徑：明確定義連接分散式系統的協定與介面。
- 可擴展性：設計能容納未來成長的佈局，而無需進行完整的結構性重構。
理解部署層 📍
部署圖是 UML 圖的一種特殊形式，用以描述系統的物理架構。與專注於靜態結構的類圖或專注於行為的序列圖不同，部署圖專注於拓撲結構。它回答的問題是：軟體運行在哪裡，以及它如何與自身的其他執行個體進行通訊？
此規劃階段對 DevOps 團隊、系統架構師和基礎設施工程師至關重要。它作為配置環境、設定網路安全以及建立監控協定的藍圖。透過明確硬體節點及其所承載的軟體組件，團隊能更清楚地掌握依賴關係與資源配置。
核心組件 🧱
要構建有意義的基礎設施佈局，必須理解基本的構建模塊。這些元素構成了部署模型的詞彙。
| 元素 | 描述 |
|---|---|
| 節點 | 實體或虛擬的運算資源。範例包括伺服器、工作站、路由器或雲端容器。 |
| 組件 | 軟體的實體表示。範例包括可執行檔、函式庫、設定指令碼或資料庫結構。 |
| 組件 | 部署至節點的功能邏輯分組。 |
| 關聯 | 連接節點與組件，或節點與其他節點之間的關係。 |
| 通訊路徑 | 節點之間的網路連接，通常指定如 HTTP 或 TCP/IP 等協定。 |
映射物理架構 🔗
規劃基礎架構佈局時，第一步是識別節點。節點代表可用的運算能力。在現代情境中，這些節點很少是實體的金屬機箱。它們通常是虛擬機器、Kubernetes Pod 或無伺服器函數。儘管存在抽象，部署圖仍必須將它們視為獨立實體，能夠承載物件。
每個節點都應標註其類型和容量。例如，Web 伺服器節點可能與資料庫節點不同。這種區分有助於理解資源瓶頸。Web 伺服器需要高 I/O 來處理請求，而資料庫節點則需要高磁碟吞吐量和記憶體穩定性。將類似的節點分組，可讓擴展策略更為簡單。
節點類型與角色
- 客戶端節點： 用戶互動的入口點。這可能是瀏覽器、行動裝置，或厚客戶端應用程式。
- 應用伺服器： 承載業務邏輯。它處理來自客戶端的請求，並與資料來源互動。
- 資料伺服器： 專注於持久化。它負責資訊的儲存與檢索。
- 網路設備： 路由器、防火牆和負載平衡器，用於在節點之間導向流量。
戰略規劃步驟 📝
建立部署圖不僅僅是畫方框；更是規劃系統生命週期的過程。
- 資產評估： 列出目前所有可用的硬體與軟體資源。識別限制因素，例如頻寬上限或儲存配額。
- 物件定義： 決定需要部署什麼。是編譯後的二進位檔、容器映像檔，還是設定檔？
- 拓撲設計： 設計節點佈局以最小化延遲。若效能至關重要，應將資料伺服器靠近應用伺服器放置。
- 安全區隔： 定義網路邊界。使用防火牆將對外公開的節點與內部資料節點分離。
- 冗餘規劃： 決定故障轉移節點的位置。若一台伺服器當機，流量將轉移到哪裡？
常見模式與考量 🛡️
規劃基礎架構時，某些架構模式經常出現。識別這些模式有助於應用標準解決方案。
客戶端-伺服器架構
這是最常見的模式。客戶端發起請求，伺服器負責處理。在部署圖中，這會以一側的節點與另一側節點相連來表示。此處的安全考量在於保護伺服器節點，防止透過通訊路徑進行未經授權的存取。
多層架構
在此架構中，邏輯被分為明確的層級：表示層、應用層與資料層。每一層都位於不同的節點上。這種分離使得團隊能獨立擴展特定層級。例如，若應用層負載過重，可在此層新增更多節點，而無需觸及資料庫層。
微服務架構
在分散式系統中，服務會部署在許多節點上。部署圖會迅速變得複雜。使用聚合來分組相關的服務。顯示服務網狀結構或負載平衡器，以路由這些微服務之間的流量。
通訊路徑 🔌
節點並非孤立存在。它們會互相通訊。部署圖中連接它們的線條代表這些路徑。明確指定所使用的協定至關重要。標示為「HTTP」的線條表示網路流量，而「資料庫協定」則表示直接存取資料。
安全性內建於這些路徑之中。跨越防火牆邊界的路徑應特別標示。對於敏感資料傳輸，應考慮使用 TLS 等加密標準。若圖中顯示公開節點與私有資料庫節點之間存在直接連接，則表示存在安全風險，必須在基礎設施規劃中加以處理。
維護圖表 🔄
基礎設施會變更。伺服器會更換，IP 位址會移動，雲端區域也會擴展。部署圖是一份活文件，必須持續維護才能保持其價值。
- 版本控制： 將圖表檔案與原始程式碼或基礎設施即程式碼（IaC）腳本一同儲存。
- 審查週期： 在每次重大發行或架構審查期間更新圖表。
- 自動化： 在可能的情況下，從基礎設施設定自動產生圖表，以確保準確性。
透過將部署圖視為動態資產，團隊可確保其文件反映實際情況。這能降低工程師在排錯或新成員入職時的認知負擔。
與邏輯模型整合 🧩
部署圖不應孤立存在。它應與類別圖或元件圖等邏輯模型相輔相成。邏輯模型定義系統的功能，而部署模型則定義系統的執行位置。將邏輯模型中的元件對應至部署模型中的節點，可呈現系統的完整面貌。
例如，代表付款處理器的特定類別可能被部署至防火牆後方的安全節點。這種連結確保物理佈局符合安全需求，同時也有助於容量規劃。若某元件至關重要，應確保其部署於高可用性節點上。
最終考量 🚀
有效的基礎設施規劃依賴於清晰的溝通與精確的文件。部署圖在此目的上扮演視覺語言的角色。它能將抽象的需求轉化為具體的硬體與網路設定。
透過專注於節點、實體與連接，架構師可建構出穩健、可擴展且安全的系統。目標不僅是描述現狀，更在於驗證未來狀態。一張精心設計的圖表能預見成長與失敗模式，引導團隊走向具韌性的設計。