建模軟體系統的物理架構是設計階段中至關重要的一步。它超越抽象邏輯，定義實際的硬體、網路拓撲以及將執行應用程式的軟體實體。部署圖是此目的的主要視覺工具，用以呈現系統的執行時期物理視圖。透過規劃節點、實體與連接關係，架構師可確保基礎設施能支援功能需求與非功能限制，例如安全性與效能。
本指南提供如何建立有效部署圖的全面概述。我們將探討核心元件、語義關係與實用模式，用以呈現複雜系統，且不依賴特定供應商產品。目標是建立一份清晰且可維護的藍圖，讓利害關係人與開發人員能在系統生命週期中持續參考。
理解物理視圖 🖥️
在繪製線條與形狀之前，必須清楚區分架構的邏輯視圖與物理視圖。邏輯視圖著重於軟體元件的組織及其互動關係。相反地，物理視圖則回答軟體執行位置的問題。
- 邏輯視圖： 定義類別、介面與子系統。它描述 什麼 系統的功能。
- 物理視圖： 定義伺服器、裝置、網路與程序。它描述 在哪裡 系統執行的位置。
部署圖彙集了軟體設計與基礎設施規劃之間的差距。它確保應用程式邏輯能成功對應到可用的硬體資源上。此對應過程包含決定程序在節點之間的分佈，並定義它們之間的通訊管道。
部署圖的核心元件 🧱
部署圖由三個主要元件組成：節點、實體與連接。理解每個元件的語義對於準確建模至關重要。
1. 節點（處理與裝置） 🖨️
節點代表系統中可用的運算資源。它們是實體的容器。在標準建模符號中，節點以三維立方體表示。
- 處理節點： 這些代表可執行軟體程序的主動運算裝置。範例包括伺服器、工作站或行動裝置。
- 裝置節點： 這些代表被動硬體元件，例如路由器、交換器或專用硬體加速器。
- 通訊節點： 這些代表促進資料流動的網路基礎設施元件，例如閘道器或防火牆。
每個節點都應明確標示，以顯示其在基礎設施中的角色。可使用範疇標籤提供額外背景資訊，例如將節點標示為「資料庫伺服器」或「負載平衡器」。
2. 實體（軟體與資料） 📦
實體代表部署到節點上的實際軟體或資料片段。它們以右上角摺起的文件圖示表示。
- 可執行檔： 在節點上執行的實際二進位碼（例如：服務、可執行檔、函式庫）。
- 資料檔： 應用程式所需的資料庫、設定檔或靜態資源（影像、指令碼）。
- 接口： 軟體與外部環境或其他節點互動方式的定義。
重要的是要區分邏輯組件（設計）與實體物件（實作）。部署圖專注於實體物件。
3. 連接（依賴關係與通訊） 🌐
連接定義了節點與實體物件之間的互動方式。它們代表資料或控制信號的流動。
- 關聯： 顯示節點包含或主機實體的結構性連結。
- 依賴關係： 表示一個實體物件依賴另一個實體物件才能正確運作。
- 通訊路徑： 代表連接兩個節點的網路媒介。可以是一條簡單的線，或特定的協定樣式（例如 TCP/IP、HTTP）。
逐步建模流程 📝
建立部署圖是一個迭代的過程。需要收集基礎設施的資訊，並隨著需求演變不斷優化模型。遵循以下步驟，以建立穩健的圖表。
步驟 1：識別系統邊界 🚧
定義系統的範圍。部署中包含哪些內容？僅僅是後端，還是也包含客戶端裝置？明確劃分系統邊界，以避免在建模過程中出現範圍蔓延。
步驟 2：清點硬體資源 🖥️
列出所有可用或規劃中的硬體。應考慮：
- 伺服器容量（CPU、記憶體、儲存空間）。
- 網路拓撲（區域網、廣域網、雲端）。
- 安全需求（防火牆、DMZ）。
不要假設只有一台單一的巨量伺服器。現代系統通常會將工作負載分散到多個節點，以提升可擴展性與冗餘性。
步驟 3：將軟體實體映射到節點 📤
將實體放置在它們將執行的節點上。這正是邏輯組件被實例化的地點。應考慮以下事項：
- 哪個節點將主機資料庫？
- 網頁伺服器位於哪裡？
- 是否有邊緣裝置會在本地處理資料？
確保節點具備主機實體所需的資源。例如，繁重的運算程序不應放置在低功率裝置上。
步驟 4：定義通訊通道 📡
繪製節點之間的連接。明確指定通訊所使用的協定。這有助於識別潛在的瓶頸或安全漏洞。例如，敏感資料不應透過未受保護的網路傳輸。
常見的部署模式 🔄
雖然每個系統都是獨特的，但某些模式會在不同架構中反覆出現。識別這些模式有助於標準化文件編寫和溝通。
| 模式 | 描述 | 使用案例 |
|---|---|---|
| 單體部署 | 所有組件都在單一節點或叢集中運行。 | 小型應用程式、內部工具。 |
| 客戶端-伺服器 | 使用者透過網路連接到中央伺服器。 | 網路應用程式、企業系統。 |
| 分散式/微服務 | 組件被分散在多個獨立節點上。 | 高規模、雲原生應用程式。 |
| 邊緣運算 | 運算在靠近資料來源的裝置上進行。 | 物聯網系統、即時分析。 |
單體部署 🏢
在此模式中，整個應用程式被部署到單一伺服器或緊密耦合的叢集中。這簡化了網路設定，並降低了內部組件之間的延遲。然而，它可能成為單一故障點，且在水平擴展方面可能遇到困難。
分散式架構 🌍
在此架構中，應用程式的不同部分在獨立的節點上運行。這允許針對特定服務進行獨立擴展。如果資料庫成為瓶頸，只需升級資料庫節點，無需升級整個應用伺服器。
- 負載平衡：多個節點處理請求，以分散流量。
- 冗餘：重複的節點可確保在一個節點失效時仍能保持高可用性。
- 地理分布：將節點放置在不同區域，以降低全球使用者的延遲。
進階考量 🛡️
除了基本的連線性之外，部署圖形還應考慮實際運營狀況。這些細節確保系統具備韌性和安全性。
安全區域與DMZ 🚧
安全性在實體架構中至關重要。節點應根據其信任等級分組到不同的區域中。
- 內部區域：敏感資料存放的可信網路。
- DMZ（非軍事化區）：用於公開服務（例如：網頁伺服器）的緩衝區。
- 外部區域：公眾互聯網。
使用防火牆的圖示來標示流量過濾的位置。此視覺提示有助於安全團隊確認外部存取僅限於授權端點。
冗餘與故障轉移 ♻️
生產系統很少依賴單一節點。部署圖應展示備援機制。
- 主動-主動：多個節點同時提供流量服務。
- 主動-被動：若主節點發生故障，備用節點將接手。
- 叢集：一群節點共同作為單一系統運作。
在圖中標示這些關係，可讓運營團隊更清楚災難復原策略。
網路延遲與頻寬 🚦
並非所有連接都相同。在建模分散式系統時，應考慮節點之間的物理距離。
- 高頻寬：資料大量傳輸時所需（例如：影片串流）。
- 低延遲：對即時互動至關重要（例如：交易平台）。
以通訊協定或頻寬估計標示連接，有助於在設計階段識別效能風險。
維護的最佳實務 📚
部署圖是一份持續更新的文件。隨著基礎架構的變更，圖表也必須同步演進。遵循最佳實務可確保圖表長期保持實用性。
命名的一致性 🏷️
為節點與元件使用標準化的命名規則。例如，資料庫節點以「DB-」開頭，網頁節點以「WEB-」開頭。這可讓圖表更易閱讀，並在討論系統時減少歧義。
抽象層級 🎯
不要試圖將所有細節塞入單一圖表中。應針對不同受眾使用不同的視圖。
- 高階視圖： 展示主要節點和資料中心，供管理使用。
- 低階視圖： 展示特定伺服器、埠和設定，供工程使用。
分離這些視圖可防止資訊過載，並保持文件的可管理性。
版本控制 📅
將圖示視為程式碼。儲存在版本控制系統中，以追蹤隨時間的變更。這讓團隊能在部署失敗時回復到先前的設定，或為合規性審計變更。
應避免的常見陷阱 ⚠️
即使經驗豐富的架構師在建模實體架構時也會犯錯。了解常見陷阱可大幅節省實作階段的時間。
- 過度設計： 增加不必要的節點或連接，這些並未反映實際部署情況。保持簡單。
- 忽視安全性： 忽略顯示防火牆或加密點，可能導致最終實作中出現安全漏洞。
- 靜態建模： 建立一個未考慮擴展性的圖示。應考慮當流量增加時，圖示會如何變化。
- 遺漏依賴關係： 忘記顯示某項實體如何依賴特定函式庫或外部服務，可能導致部署失敗。
最終考量 ✅
使用部署圖來建模實體架構，需要在技術準確性與清晰溝通之間取得平衡。透過專注於節點、實體及其關係，架構師可以建立一份藍圖，有效引導基礎設施團隊。
請記住，圖示是一種理解工具，而不僅僅是文件。它應促進關於容量、安全性和可靠性的討論。隨著系統演進，圖示也應更新以反映基礎設施的當前狀態。
透過仔細規劃並遵守標準符號，部署圖成為軟體開發週期中不可或缺的資產。它確保實體現實與邏輯設計相符，降低風險並提升系統穩定性。
