軟體架構通常始於白板或數位圖形工具。然而，從概念模型到功能完善的生產環境的旅程充滿了摩擦。這種摩擦通常源於設計階段與部署現實之間的脫節。當「部署圖被視為靜態產物而非動態地圖時，錯誤便會蔓延至基礎設施層。
本指南探討如何構建部署圖，以準確反映系統的物理與邏輯拓撲結構。我們將檢視將軟體元件映射至硬體節點的機制，確保設計意圖在實現的複雜性中得以保留。
🧩 理解部署圖
部署圖是一種 UML 圖，用於展示軟體產物的物理實現。與專注於程式碼結構的類別圖，或專注於執行時行為的序列圖不同，部署圖專注於「基礎設施。它回答了這個問題：「這套軟體位於何處，又是如何與世界其他部分溝通？」
若缺乏明確的部署策略，團隊常會面臨以下問題：
- 環境一致性問題：程式碼在開發機上運作正常，卻因缺少函式庫或設定差異而在生產環境中失敗。
- 網路瓶頸：設計為本地通訊的元件被部署至廣域網路，卻未考量延遲問題。
- 安全缺口：敏感資料透過未加密的通道傳輸，因為拓撲結構未正確映射。
- 擴展失敗：系統無法負載，因為圖表未考量負載平衡器或叢集機制。
透過視覺化物理節點及其間的通訊路徑，架構師可在撰寫任何一行設定程式碼前識別風險。
🏗️ 部署圖的核心元件
要有效縮小差距，必須理解構建這些圖表所使用的基礎元件。這些元素代表您系統的實體資產。
1. 節點（硬體或虛擬）
節點代表實體或虛擬的運算資源，是軟體的容器。在現代情境中，這些可能並非實體伺服器，而是虛擬機器、容器或無伺服器函式。
- 裝置節點：實體硬體，例如路由器、防火牆或行動裝置。
- 伺服器節點：虛擬機器或承載應用程式的實體伺服器。
- 容器節點：執行環境，例如容器編排叢集。
- 雲端區域：代表特定地理數據中心的抽象節點。
2. 構建產物（軟體元件）
構建產物是部署到節點上的軟體項目。這些是構建過程的具體輸出成果。
- 可執行檔：編譯後的二進位檔或腳本。
- 函式庫：執行時所需的共用相依套件。
- 設定檔：決定特定環境中行為的設定。
- 資料庫：附著於節點的資料儲存實體。
3. 通訊路徑
連線代表節點之間交換資料所使用的網路協定或通道。這些定義了系統的信任邊界與效能特性。
- 網路協定：HTTP、TCP/IP、gRPC 或 WebSocket。
- 安全層：加密通道（TLS）或公共網際網路連線。
- 負載平衡：將流量分發至多個節點的路徑。
📐 為現實而設計
部署圖只有在反映實際基礎設施時才有用。為現實而設計需要考慮程式碼本身之外的限制條件。
1. 環境一致性
最常見的失敗之一發生在開發環境與生產環境存在顯著差異時。圖表應明確區分不同環境。
- 開發環境：節點數量最少、資源共用、安全要求較寬鬆。
- 預發布環境：複製生產環境的大小與配置，用於最終測試。
- 生產環境：高可用性、嚴格的安全措施、冗餘路徑。
2. 網路拓撲
物理位置決定了網路延遲與成本。圖表必須顯示節點之間的相對位置。
- 單一區域：低延遲，但若該區域發生故障，則有全面停機風險。
- 多區域：高可用性與災難復原能力，但跨區域呼叫的延遲較高。
- 混合式：部分元件位於本地端，其他則在雲端。需仔細規劃閘道器的對應關係。
3. 安全邊界
安全性在設計中常被視為事後考量。圖表應清楚劃定信任區域。
- DMZ（非軍事區）：面向公眾的伺服器，作為緩衝區。
- 內部網路：後端服務，絕不應直接對外暴露。
- 私有子網路：與直接網際網路存取隔離的資料庫節點。
🛠️ 部署流程工作流
建立圖表並非一次性事件，而是將設計與營運對齊的持續工作流的一部分。
步驟 1：盤點現有資產
在繪製新路徑之前，先編目現有內容。這可避免基礎設施重複或與舊系統產生衝突。
- 列出所有活躍伺服器及其角色。
- 識別現有的負載平衡器及其設定。
- 記錄當前的網路區段規則。
步驟 2：定義新需求
根據業務需求，確定所需內容。這包括效能指標、可用性目標與合規需求。
- 吞吐量：每秒必須處理多少請求？
- 延遲：可接受的回應時間為何？
- 合規性：是否有需考慮的資料駐留法規？
步驟 3：將元件對應至節點
將軟體產出物放置於硬體節點上。請確保尊重相依性。例如，網頁伺服器不應放置在缺乏所需執行階段函式庫的節點上。
步驟 4：驗證通訊路徑
追蹤資料流程。每個節點是否都能存取其所需的服務？是否存在單點故障？若某個節點當機，路徑是否會完全中斷？
⚠️ 應避免的常見陷阱
即使是經驗豐富的架構師在視覺化基礎設施時也會犯錯。了解這些常見陷阱可節省大量時間與資源。
| 陷阱 | 後果 | 緩解策略 |
|---|---|---|
| 過度簡化 | 遺漏隱藏的相依性或安全漏洞。 | 納入防火牆規則與特定通訊協定。 |
| 靜態表示 | 部署後圖表很快就會過時。 | 將圖表與基礎設施即程式碼儲存庫連結。 |
| 忽略伸縮性 | 因缺乏叢集而在負載下導致系統當機。 | 在負載平衡器後方繪製多個執行個體。 |
| 環境混淆 | 開發環境與生產環境之間的設定錯誤。 | 針對不同環境使用不同的形狀或顏色。 |
| 網路盲點 | 延遲問題或連線逾時。 | 在路徑上標註通訊協定與延遲估算。 |
🤝 跨團隊協作
部署圖是一種溝通工具，作為開發、營運與安全團隊之間的共同語言。
針對開發人員
開發人員需要知道程式碼的執行位置，才能有效除錯。圖表應清楚顯示：
- 哪些服務依賴哪些資料庫。
- 日誌記錄與監控代理程式的放置位置。
- 如何存取外部 API。
針對作業團隊
作業團隊負責管理硬體與網路。他們需要釐清以下事項：
- 資源配置（CPU、記憶體、儲存空間）。
- 備份與還原點。
- 網路埠與存取控制清單。
針對安全團隊
安全團隊進行漏洞審計。此圖表協助他們識別：
- 已暴露的端點。
- 跨信任邊界之資料流程。
- 靜態與傳輸中之加密需求。
🔄 維護與演進
基礎設施不斷變更。未維護的部署圖表會成為負擔，可能誤導新進人員，或在遷移期間導致部署失敗。
圖表版本控制
將圖表視為程式碼。將其儲存於版本控制系統中，與您的設定檔案並列。如此可追蹤隨時間的變更，並在必要時進行還原。
自動化更新
在可行時，應從基礎設施定義自動產生圖表。這可確保視覺化呈現始終與系統實際狀態相符。
定期審計
排定圖表的定期檢視，並提出以下問題：
- 是否有新增未文件化的服務？
- 是否仍有已棄用之元件列於圖表中？
- 網路路徑是否仍符合安全政策？
✅ 最佳實踐清單
使用此清單以確保您的部署圖表堅固且具實用性。
- 使用標準符號：遵循 UML 標準以定義節點與產出物，確保普遍理解。
- 標註連接：務必在連接線上註明通訊協定（例如 HTTPS、TCP）。
- 群組相關節點：使用區隔將節點依功能分組（例如「前端」、「後端」、「資料層」）。
- 標示關鍵路徑：使用粗線或顏色來標示高優先級或高風險的通訊通道。
- 記錄假設：添加註解，說明為何做出某些設計決策。
- 保持易讀性：避免雜亂。如果圖表過大，請將其拆分為多個視圖（例如：「全局視圖」、「詳細視圖」）。
🌐 與更廣泛架構整合
部署圖並非孤立存在，它與更廣泛的系統架構相連接。
與元件圖的關係
元件圖顯示內部結構，而部署圖顯示外部部署位置。請確保第一張圖中的元件能正確對應到第二張圖中的工件。
與序列圖的關係
序列圖顯示互動的時間順序。部署圖則提供這些互動的上下文。如果序列圖顯示跨網路的呼叫，部署圖應顯示實體路徑。
🔒 設計中的安全考量
安全必須內建於設計中，而非事後添加。部署圖是用於視覺化安全態勢的主要工具。
- 隔離：確保敏感服務放置在無法從公共網際網路存取的節點上。
- 加密：為所有傳輸敏感資料的連線標註加密指示符。
- 驗證：記錄驗證閘道在流程中的位置。
- 監控：確保每個節點都有路徑連接到中央記錄或監控服務。
📈 擴展策略
為擴展進行設計需要部署圖中可見的特定模式。
水平擴展
增加更多節點以處理增加的負載。圖表應顯示負載平衡器後有多個相同服務的實例。
垂直擴展
增加單一節點的資源。圖表應註明每種節點類型的資源限制（CPU/記憶體）。
資料庫擴展
分離讀取與寫入操作。圖表應區分主要資料庫節點與複寫資料庫節點。
🏁 結語
填補設計與部署之間的差距需要紀律與清晰。部署圖是架構師與操作人員之間的契約。當以精準方式建立時，它能降低風險、改善溝通並加速交付。
透過聚焦於基礎設施的實體現實，您能確保軟體按預期運作。請將此圖視為隨系統演進的動態地圖，而非靜態繪圖。此方法能導向更具韌性、安全性與可維護性的軟體架構。
請記住，目標並非圖面的完美，而是理解的準確。運用這些圖表促進對話、驗證假設，並引導複雜系統的實作。
