建立混合基礎設施的統一視圖需要精確的架構文件。當系統跨越公有雲環境與私有資料中心時，單一的部署圖對利益相關者理解資料流、依賴關係與物理邊界變得至關重要。本指南概述了構建準確圖示的方法，以清晰呈現兩種環境而不產生混淆。遵循標準的建模規範，可確保開發人員、運營團隊與安全審計人員都能清楚理解。🛡️
理解混合環境背景 🌐
部署圖可視化系統的實體或虛擬硬體與軟體架構。在混合模型中，這意味著呈現邏輯上獨立但功能上整合的資源。其挑戰在於維持視覺一致性，同時區分雲端服務的管理性與本地硬體的管理控制權。若缺乏明確區分，圖示將無法有效傳達風險、延遲或所有權資訊。
在建模這些環境時，請牢記以下目標：
- 清晰性：觀看者必須能立即辨識哪些組件位於哪個環境中。
- 準確性： 網路拓撲必須反映實際的網路路徑與連接協定。
- 可維護性： 圖示應在基礎設施隨時間變更時仍保持有效。
- 安全性： 防火牆與加密區域等邊界必須明確標示。
圖示的核心元件 📊
為了建立穩健的呈現，您必須定義 UML 為基礎的部署建模中所使用的標準元件。這些元件構成您圖示的詞彙。
1. 節點與裝置
節點代表實體或虛擬的執行環境。在混合架構中，節點依其位置與管理類型進行分類。
- 雲端節點： 代表由第三方提供商主機的虛擬機器、容器或無伺服器函式。這些通常具有暫時性或動態擴展的特性。
- 本地節點： 代表由內部 IT 團隊管理的實體伺服器、大型主機或本地虛擬化主機。這些通常具有固定容量與硬體依賴性。
- 網路節點： 用於促進兩種環境之間流量的路由器、交換器與負載平衡器。
2. 資產
資產代表部署在節點上的實體軟體組件。範例包括可執行檔、程式庫、設定檔或資料庫結構。請確保資產與其所在的特定節點連結。
- 可執行檔： 在作業系統上執行的二進位檔。
- 資料庫檔案： 存放在儲存體積上的資料儲存。
- 設定 定義執行時期行為的指令碼或檔案。
區分用的視覺慣例 👁️
一致性是可讀性的關鍵。由於無法單獨依賴顏色來確保可及性，請使用形狀、立體標籤和邊框來區分環境。
使用立體標籤
將特定的立體標籤應用於節點形狀，以表示其來源。這是模型標準中表示環境類型最正式的方式。
- 雲端立體標籤： 使用類似於
«雲端»或«公開»作為代表雲端節點方框的標籤。 - 本地部署立體標籤： 使用類似於
«伺服器»或«本地部署»作為代表本地基礎設施方框的標籤。 - 邊界方框： 將雲端節點群組於標示為「雲端環境」的較大邊界內，並將本地部署節點群組於「資料中心」內。
色彩與形狀指南
雖避免使用特定工具，但仍應遵循一般設計原則以建立視覺層次。
- 形狀： 不論位置為何，資料庫一律使用圓柱形，但需在圓柱外加上邊界方框以顯示環境。
- 邊框樣式： 使用實線表示本地部署連接，虛線表示雲端連接，以暗示邏輯上的網路分離。
- 圖示： 結合圖示，例如用機架圖示代表本地硬體，用雲端符號代表遠端服務。
建模連線與協定 📡
連接節點的線條代表通訊路徑。在混合模型中，這些路徑會跨越安全邊界與網路區段。您必須記錄這些連結的協定與安全背景。
網路協定
使用所用的通訊協定標記您的關聯線。這有助於開發人員理解延遲需求和相容性。
- HTTP/HTTPS： 標準網頁流量。請標示是否強制使用 SSL/TLS。
- gRPC/REST： 內部微服務通訊。
- 資料庫協定： SQL、NoSQL 或特定的連接字串。
- 訊息佇列： AMQP、Kafka 或專有訊息系統。
頻寬與延遲
並非所有連接都相同。從本地伺服器到本地交換器的連結，與連接到公開雲端區域的連結不同。建議在圖表中加上性能方面的定性註解。
- 高延遲： 使用註解標示跨越網際網路的連接，以指出可能的延遲。
- 高頻寬： 使用更高的吞吐量指標標示專用線路（如 Direct Connect 或 ExpressRoute 的等效線路）。
- 冗餘： 為關鍵服務顯示多條路徑，以表明故障轉移能力。
安全邊界與區域 🔒
在建模混合系統時，安全至關重要。部署圖不應隱藏邊界。應明確繪製保護敏感資料的邊界。
防火牆與閘道
將防火牆節點放置在網路區段的邊緣。顯示流量在進入內部雲端或本地區段前被檢查的位置。
- 邊界防火牆： 保護本地資料中心免受外部威脅。
- 雲端閘道： 保護雲端環境免受公開網際網路流量的威脅。
- DMZ： 一個非軍事區，公開服務位於此處，與內部資料庫分離。
加密與合規
標示資料加密的位置。這對於合規性審計至關重要。
- 傳輸中： 使用鎖圖示標記線條，以顯示傳輸過程中的加密。
- 靜態： 使用鎖圖示標記儲存節點，以顯示磁碟上的加密。
- 合規區域： 使用虛線將必須遵守特定法規（例如 GDPR、HIPAA）的節點分組。
逐步建模流程 📝
遵循此結構化方法，建立您的圖表，確保不會遺漏關鍵細節。
步驟 1：資產清單
繪圖前，列出所有組件。建立電子試算表或文字清單，列出所有涉及的伺服器、資料庫和服務，並依環境分開。
- 列出所有內部伺服器及其角色。
- 列出所有雲端實例及其服務類型（例如：運算、儲存）。
- 識別所有第三方整合。
步驟 2：定義拓撲
草擬高階網路佈局。決定邊界的位置。將內部系統方框置於左側，雲端方框置於右側，或根據複雜度使用垂直分割。
- 繪製主要網路邊界。
- 繪製雲端的次級網路邊界。
- 標記它們之間的連接點（例如：VPN、對等連接）。
步驟 3：放置節點與物件
將您的資產清單項目拖曳並放置到適當的邊界內。確保物件包含在它們所部署的節點中。
- 將應用程式二進位檔放置於運算節點上。
- 將資料檔案放置於儲存節點上。
- 將設定檔放置於管理節點上。
步驟 4：繪製連接
根據資料流繪製節點之間的線條，並為協定加上標籤。
- 繪製 API 呼叫的線條。
- 繪製資料庫複製的線條。
- 繪製驗證流程的線條。
步驟 5：新增安全註解
審查圖表中的安全漏洞。為加密和防火牆加上標籤。
- 標記所有面向網際網路的連接埠。
- 標記所有僅限內部使用的埠。
- 確認敏感資料路徑已受到保護。
應避免的常見錯誤 ⚠️
即使經驗豐富的架構師在建模混合系統時也會犯錯。請留意這些常見錯誤。
1. 圖表過於擁擠
不要試圖顯示每一台伺服器。將類似的伺服器分組為叢集或邏輯節點。包含50個獨立方框的圖表無法閱讀。
- 分組： 使用一個標示為「Web 伺服器叢集」的單一節點，取代五個獨立節點。
- 抽象化： 除非內部細節與部署環境相關，否則隱藏服務的內部細節。
2. 忽略資料同步
在混合模型中，資料經常需要在不同環境間移動。若未顯示複製，圖表即不完整。
- 以雙向箭頭表示資料同步。
- 標示同步頻率（例如：「即時」、「每小時批次」）。
3. 混合邏輯與物理視圖
部署圖應為實體或虛擬。不要將邏輯元件圖與部署節點混合。專注於硬體與軟體安裝。
- 不要在部署節點內顯示類別圖。
- 除非使用者角色由獨立的硬體終端表示，否則不要顯示使用者角色。
4. 資料過時
雲端基礎架構變動迅速。六個月前的圖表可能已過時。
- 版本控制： 在圖表標題中加入版本號碼或日期。
- 審查週期： 計畫定期審查架構文件。
建模方法比較 📋
不同團隊可能偏好不同細節層級。下表總結了常見的建模方法。
| 方法 | 細節層級 | 適用於 | 限制 |
|---|---|---|---|
| 高階概覽 | 低 | 執行摘要 | 缺乏技術細節 |
| 標準部署 | 中 | 開發團隊 | 可能忽略安全細節 |
| 詳細基礎設施 | 高 | 運營與安全 | 難以長期維護 |
| 邏輯混合 | 混合 | 架構規劃 | 無法反映實際物理限制 |
維護圖表 🔄
部署圖是一份活文件，需要持續維護才能保持實用性。應將其視為程式碼來對待。
自動更新
在可能的情況下，從基礎設施程式碼生成圖表。這可確保視覺呈現與實際狀態一致。
- 基礎設施即程式碼： 使用腳本解析資源定義。
- 監控資料： 與監控工具整合，以顯示活躍節點。
文件標準
建立命名與標籤的標準。一致性可降低任何閱讀圖表者的認知負擔。
- 命名慣例： 使用
env-role-id（例如，prod-web-01). - 圖例： 始終包含一個圖例，用以解釋符號和顏色。
- 資料內容： 請包含最後更新日期和作者。
混合建模總結 🏁
在單一部署圖中建模雲端與本地系統是現代架構所必需的技能。它彌補了實體硬體與虛擬服務之間的差距。透過遵循標準規範、使用明確的樣式，並維持嚴格的安全邊界，您將建立一份同時滿足技術與商業需求的文件。這種方法確保從 CTO 到初級開發人員的每個人，都能理解系統架構。請記得保持圖表更新，並聚焦於您基礎設施的實際物理現實。 🚀
