現代雲端架構中，基礎設施即程式碼的模組化設計至關重要。如何有效地將基礎設施分解成可管理的元件，同時兼顧彈性和可擴充套件性，是架構師面臨的主要挑戰。本文將探討堆積疊模組化設計的陷阱與挑戰，並提供最佳實踐，包含無分享架構、依賴關係管理、版本控制以及持續交付等導向，以協助團隊構建更穩健的雲端基礎設施。此外，文章也將探討如何根據變更模式和生命週期調整元件邊界，並比較不同專案整合模式的優缺點，提供更全面的雲端資源整合策略。
雲端資源整合與堆積疊模組化挑戰全解析
基礎設施即程式碼：開發模組化與可擴充套件的基礎設施
模組化基礎設施的藝術
在現代雲端架構中，基礎設施程式碼的模組化是一項關鍵挑戰。設計基礎設施時，如何將其分解為可管理的元件，同時保持彈性和可擴充套件性，是每位架構師必須面對的問題。
堆積疊模組的陷阱與挑戰
堆積疊模組和程式函式庫對於程式碼重用非常有價值，但它們在提高堆積疊可變更性方面效果有限。許多團隊試圖透過將程式碼分解為模組來改進單體堆積疊。雖然模組確實使程式碼更容易理解，但每個堆積疊例項的規模和複雜性並未減少。
當模組被整合到堆積疊例項中時，它們實際上增加了堆積疊的複雜性。更重要的是，當一個模組被多個堆積疊使用時，它會在這些堆積疊之間建立耦合關係。為了滿足一個堆積疊的需求而修改模組，可能會影響使用該模組的其他堆積疊，這種耦合會增加變更的阻力。
graph TD
A[模組A] --> D[堆積疊例項1]
B[模組B] --> D
C[模組C] --> D
A --> E[堆積疊例項2]
B --> E
C --> E
圖表翻譯：
此圖表展示了模組如何被整合到堆積疊例項中。雖然模組化看似能夠提高程式碼重用性，但每個堆積疊例項仍然包含所有模組，導致複雜性並未真正降低。當多個堆積疊共用同一模組時，對模組的變更會影響所有相關堆積疊，增加了變更的風險和複雜性。
更有效的方法是將大型堆積疊分解為多個獨立的堆積疊，每個堆積疊都可以獨立於其他堆積疊進行佈建、管理和變更。這種方法遵循「小而簡單的元件」核心實踐原則。
在堆積疊中使用伺服器是堆積疊元件的常見型別
ShopSpinner團隊有一個名為cluster_of_host_nodes的堆積疊，用於建立作為容器主機節點的伺服器叢集：
server_cluster:
name: "cluster_of_host_nodes"
min_size: 1
max_size: 3
each_server_node:
source_image: host_node_image
memory: 8GB
內容解密：
此程式碼定義了一個伺服器叢集，指定了叢集名稱、最小和最大節點數，以及每個節點的設定。source_image引數指定了要使用的伺服器映像，而memory引數設定了每個節點的記憶體大小。這是一個典型的基礎設施即程式碼定義，用於自動化建立和管理伺服器叢集。
團隊使用一個管道來建立和測試伺服器映像的變更，另一個管道則測試cluster_of_host_nodes的變更，將其與透過測試的最新版本host_node_image整合。
graph LR
A[伺服器映像程式碼] --> B[建立映像]
B --> C[測試映像]
C --> D[發布映像]
E[堆積疊程式碼] --> F[整合測試]
D --> F
F --> G[佈署堆積疊]
圖表翻譯：
此圖表展示了兩個平行的管道：一個用於建立和測試伺服器映像，另一個用於整合和佈署使用該映像的堆積疊。這種方法確保了堆積疊使用的是經過測試和驗證的伺服器映像，減少了佈署失敗的風險。
ShopSpinner團隊透過將硬編碼的host_node_image從堆積疊程式碼中提取出來，改用堆積疊引數來解決問題：
server_cluster:
name: "cluster_of_host_nodes"
min_size: 1
max_size: 3
each_server_node:
source_image: ${HOST_NODE_SERVER_IMAGE}
memory: 8GB
內容解密：
這個改進版本使用了引數化方法，將伺服器映像名稱從硬編碼值改為引數${HOST_NODE_SERVER_IMAGE}。這種變更減少了耦合，並遵循了組合規則。團隊現在可以輕鬆地使用不同的伺服器映像建立cluster_of_host_nodes的例項。
無分享基礎設施
在分散式計算領域，無分享架構透過確保新節點可以增加到系統中而不會增加對節點本身之外任何資源的爭用，從而實作擴充套件。
graph TD
A[網路堆積疊1] --> B[應用堆積疊1]
C[網路堆積疊2] --> D[應用堆積疊2]
E[網路堆積疊3] --> F[應用堆積疊3]
圖表翻譯：
此圖表展示了無分享佈署模型中的多個堆積疊。每個應用堆積疊都有自己專用的網路堆積疊，而不是分享一個網路堆積疊。這種方法確保了應用堆積疊之間的獨立性，減少了變更的爆炸半徑，並提高了系統的彈性。
在元件之間繪製邊界
最佳化元件邊界以適應變更的最基本方法是瞭解它們的自然變更模式。檢查歷史變更可以瞭解哪些東西通常一起變更。更細粒度的變更，如程式碼提交，提供最有用的洞察。
根據自然變更模式調整邊界
對於現有系統，可以透過檢查歷史變更來瞭解哪些東西通常一起變更。更細粒度的變更，如程式碼提交，提供最有用的洞察。
根據元件生命週期調整邊界
基礎設施的不同部分可能有不同的生命週期。例如，叢集中的伺服器是動態建立和銷毀的，可能每天多次。資料函式庫儲存卷的變更頻率較低。
graph TD
A[網路堆積疊] --> D[應用伺服器堆積疊]
B[資料函式庫儲存堆積疊] --> D
C[應用伺服器映像] --> D
圖表翻譯：
此圖表展示了不同堆積疊具有不同生命週期的情況。透過將基礎設施分解為具有不同生命週期的多個堆積疊，團隊可以更有效地管理變更和風險。
建立支援彈性的邊界
基礎設施元件需要設計成能夠快速重建和還原。如果根據生命週期將資源組織到元件中，那麼也可以考慮重建和還原使用案例。
建立支援擴充套件的邊界
擴充套件系統的常見策略是建立其某些元件的額外例項。可以佈署產品瀏覽服務堆積疊的多個例項來應對更高的負載。
graph TD
A[前端流量路由堆積疊] --> B[產品瀏覽服務堆積疊1]
A --> C[產品瀏覽服務堆積疊2]
A --> D[產品瀏覽服務堆積疊3]
B --> E[資料函式庫堆積疊]
C --> E
D --> E
圖表翻譯：
此圖表展示了不同堆積疊的例項數量如何擴充套件。前端流量路由堆積疊和資料函式庫堆積疊保持單一例項，而產品瀏覽服務堆積疊則擴充套件為多個例項以處理高峰負載。
偏好垂直分組而非水平分組
傳統上，許多架構師按功能組織系統。網路相關的東西放在一起，資料函式庫相關的東西放在一起，作業系統相關的東西放在一起。
graph TD
subgraph "功能層"
A[網路層]
B[資料函式庫層]
C[伺服器層]
end
subgraph "服務1"
D[服務1網路] --> A
E[服務1資料函式庫] --> B
F[服務1伺服器] --> C
end
subgraph "服務2"
G[服務2網路] --> A
H[服務2資料函式庫] --> B
I[服務2伺服器] --> C
end
圖表翻譯：
此圖表展示了每個服務的基礎設施如何分散在多個功能堆積疊中。這種水平分層方法導致服務變更需要協調多個堆積疅的變更，增加了複雜性和風險。
將系統元素組織成跨切功能的基礎設施堆積疅有兩個缺點。一個是對一個服務的基礎設施進行變更可能涉及對多個堆積疅進行變更。這些變更需要仔細協調，以確保在提供者堆積疅中出現依賴關係之前，不會在消費者堆積疅中引入依賴關係。
功能堆積疅的第二個缺點出現在它們跨服務分享時。當團隊變更其中一個服務的伺服器時，存在破壞其他服務的風險，因為堆積疅邊界代表變更的爆炸半徑。
雲端資源整合與模組化是現代雲端架構中的關鍵挑戰。透過合理的模組化設計和無分享架構，可以提高系統的可擴充套件性和彈性。同時，根據變更模式、生命週期和組織結構調整元件邊界，可以簡化管理和降低風險。最終，合理的基礎設施即程式碼設計將有助於實作更高效、更穩定的雲端服務。
模組化基礎設施：提升重用性與可測試性
模組化基礎設施堆積積疊的價值
良好設計的元件能使基礎設施系統更容易與安全地進行變更。這種設計理念支援了一個核心概念：利用變更速度來持續改善系統品質，同時利用高品質來實作更快速的變更。
模組化基礎設施堆積積疊（Infrastructure Stack）指的是將堆積積疊拆分成較小的程式碼片段。這種做法帶來多重優勢，值得我們探討。
為何要模組化你的基礎設施堆積積疊？
知識重用與標準化 將特定結構的實作知識封裝到元件中，使其能在不同堆積積疊間重複使用。這不僅節省時間，更能確保最佳實踐的一致應用。
# 定義一個基礎設施元件
class NetworkComponent:
def __init__(self, name, cidr_block):
self.name = name
self.cidr_block = cidr_block
def create_vpc(self):
# 建立VPC的邏輯
print(f"Creating VPC: {self.name} with CIDR block: {self.cidr_block}")
內容解密：
此程式碼定義了一個名為NetworkComponent的類別，用於建立網路元件。該類別封裝了VPC的名稱和CIDR區塊，並包含建立VPC的方法。這種模組化設計使得網路元件可以在不同的基礎設施堆積積疊中重複使用，提高了程式碼的可重用性和可維護性。
靈活組合與替換 建立可互換的概念實作，增加堆積積疊建構的彈性。這使團隊能根據特定需求選擇最適合的實作方式，而不必重寫**整個系統。
flowchart TD
A[開始] --> B{選擇網路元件}
B -->|元件1| C[建立VPC]
B -->|元件2| D[建立子網]
C --> E[完成]
D --> E
圖表翻譯：
此圖示展示了根據不同網路元件選擇建立不同網路結構的流程。流程始於「開始」階段，接著根據選擇的網路元件型別進行不同的操作。若選擇元件1，則進入「建立VPC」階段；若選擇元件2，則進入「建立子網」階段。最後，無論選擇哪種元件，流程都會到達「完成」階段。此圖清晰地說明瞭程式中的條件分支邏輯以及不同處理路徑的銜接方式。
提升測試效率 將堆積積疊分解為可獨立測試的片段，大幅提高測試速度與專注度。若元件具備可組合性，還能使用測試替身（Test Doubles）進一步提升測試的隔離性與速度。
# 使用測試替身進行單元測試
import unittest
from unittest.mock import MagicMock
class TestNetworkComponent(unittest.TestCase):
def test_create_vpc(self):
component = NetworkComponent("test_vpc", "10.0.0.0/16")
component.create_vpc = MagicMock()
component.create_vpc()
component.create_vpc.assert_called_once()
內容解密：
此測試程式碼展示瞭如何使用測試替身（MagicMock）對NetworkComponent類別的create_vpc方法進行單元測試。透過模擬create_vpc方法的行為，可以在隔離的環境中驗證其正確性，而無需實際建立VPC資源。這種測試方法提高了測試效率和可靠性。
模組化的潛在風險
將堆積積疊拆分為模組和函式庫雖然簡化了程式碼，但並不會使堆積積疊例項變得更小或更簡單。堆積積疊元件反而可能因為掩蓋了它們為堆積積疊例項增加的資源數量和複雜性，而使情況變得更糟。
模組化實踐的關鍵考量
在實施基礎設施模組化時，需要考慮以下幾個關鍵因素：
- 抽象層級的選擇 - 決定適當的抽象層級，既能提供足夠的彈性，又不會過度複雜化
- 介面設計 - 設計清晰、一致與直觀的元件介面，降低使用者的認知負擔
- 版本管理策略 - 建立有效的版本管理策略，確保元件更新不會破壞現有系統
基礎設施即程式碼：組織與整合堆積積疊元件
基礎設施即程式碼（IaC）的成功實踐不僅在於撰寫優質的程式碼，更在於如何有效地組織這些程式碼。本文將探討如何組織基礎設施程式碼，以及如何將不同堆積積疊元件整合在一起，以建立一個可維護、可擴充套件的基礎設施系統。
單一儲存函式庫還是多個儲存函式庫？
在決定如何組織程式碼時，我們面臨一個基本問題：是將所有專案放在一個儲存函式庫中，還是分散到多個儲存函式庫？這個決策需要考慮以下因素：
- 邊界維護：將專案分散到不同儲存函式庫使程式碼層級的邊界維護更容易
- 團隊協作：多個團隊在單一儲存函式庫中工作可能增加衝突和管理成本
跨堆積積疊依賴關係的發現模式
當系統由多個堆積積疊組成時，堆積積疊之間的整合通常涉及一個堆積積疊管理另一個堆積積疊使用的資源。以下是發現跨堆積積疊依賴關係的幾種模式：
- 資源比對模式：消費者堆積積疊透過比對名稱、標籤或其他識別特徵來發現依賴關係
- 堆積積疊資料查詢模式：堆積積疊資料查詢使用堆積積疊管理工具維護的資料結構來查詢提供者資源
flowchart TD
A[開始] --> B{選擇依賴發現模式}
B -->|資源比對模式| C[比對資源名稱]
B -->|堆積積疊資料查詢模式| D[查詢提供者資源]
C --> E[完成]
D --> E
圖表翻譯：
此圖示展示了在多堆積積疊環境中選擇不同依賴發現模式的流程。流程始於「開始」階段，接著根據選擇的依賴發現模式進行不同的操作。若選擇資源比對模式，則進入「比對資源名稱」階段；若選擇堆積積疊資料查詢模式，則進入「查詢提供者資源」階段。最後，無論選擇哪種模式，流程都會到達「完成」階段。此圖清晰地說明瞭程式中的條件分支邏輯以及不同處理路徑的銜接方式。
相依性注入：解耦依賴與發現
將依賴發現與堆積積疊定義程式碼混合會增加認知負擔，並將堆積積疊與依賴機制耦合。相依性注入（DI）是一種技術，元件接收其依賴項，而不是自行發現它們。
# 使用相依性注入解耦依賴
class Stack:
def __init__(self, environment_name, vlan_id):
self.environment_name = environment_name
self.vlan_id = vlan_id
def create_resources(self):
# 使用注入的VLAN ID建立資源
print(f"Creating resources in VLAN: {self.vlan_id}")
內容解密：
此程式碼展示瞭如何使用相依性注入技術來解耦堆積積疊定義與其依賴關係。Stack類別在其建構函式中接收environment_name和vlan_id作為引數，而不是自行查詢或硬編碼這些值。這種方法提高了程式碼的靈活性，使得在不同環境中使用相同的堆積積疊定義變得更加容易。
專案整合模式
當系統由多個專案組成時，需要考慮如何整合這些專案。以下是三種主要的整合模式：
- 建置時專案整合：在建置階段將多個專案的程式碼組合在一起
- 交付時專案整合：在交付階段將已建置的專案組合在一起
- 應用時專案整合：在應用階段將專案整合在一起
基礎設施設定案的組織方式
在管理不同環境的基礎設施引數時，有兩種主要的組織方式：
- 將設定案存放在相關專案內部
- 建立獨立的設定專案，按環境組織所有堆積積疊的設定
管理基礎設施與應用程式碼
應用程式和基礎設施程式碼應該放在不同的儲存函式庫還是放在一起？這個問題的答案取決於組織結構和所有權分配。
交付基礎設施與應用程式
無論是否將應用程式和基礎設施程式碼放在一起管理，最終都會將它們佈署到同一個系統中。基礎設施程式碼的變更應該在整個應用程式交付流程中與應用程式整合和測試。
flowchart TD
A[開始] --> B{是否整合應用程式與基礎設施程式碼}
B -->|是| C[在同一個儲存函式庫中管理]
B -->|否| D[在不同儲存函式庫中管理]
C --> E[簡化跨專案變更]
D --> F[確保專案間清晰分離]
E --> G[完成]
F --> G
圖表翻譯：
此圖示展示了在決定是否將應用程式與基礎設施程式碼整合時的決策流程。流程始於「開始」階段，接著根據是否整合這兩類別程式碼進行不同的操作。若選擇整合，則進入「在同一個儲存函式庫中管理」階段，可簡化跨專案變更；若選擇不整合，則進入「在不同儲存函式庫中管理」階段，可確保專案間清晰分離。最後，無論選擇哪種方式，流程都會到達「完成」階段。此圖清晰地說明瞭程式中的條件分支邏輯以及不同處理路徑的銜接方式。
基礎設施即程式碼的交付策略
交付基礎設施程式碼的變更需要在所有環境中進行仔細的管理。基礎設施變更流程有多種選擇，每種選擇都有其優缺點。
使用應用程式測試基礎設施
在交付基礎設施變更時，可以利用自動化應用程式測試。這種方法涉及在每個階段應用基礎設施變更後觸發應用程式測試階段。這樣可以確保基礎設施變更不會破壞應用程式的功能。
漸進式測試方法使用應用程式測試進行整合測試。應用程式和基礎設施版本可以繫結在一起，按照交付時間整合模式透過剩餘的交付流程。這種方法確保了應用程式和基礎設施之間的緊密整合。
將基礎設施程式碼應用到分享的應用程式開發和測試環境中存在風險，因為破壞這些環境會影響其他團隊。因此，在將基礎設施程式碼推廣到分享環境之前，最好有專門的交付階段和環境來單獨測試基礎設施程式碼。
使用基礎設施程式碼佈署應用程式
基礎設施程式碼定義了伺服器上的內容。佈署應用程式涉及將內容放到伺服器上。因此，編寫基礎設施程式碼來自動化應用程式的佈署過程似乎是合理的。但是，在實踐中，混合應用程式佈署和基礎設施設定的關注點會變得混亂。
使用專門用於佈署和升級應用程式的工具和指令碼通常更成功。例如，使用Helm或Octopus Deploy這樣的佈署工具來定義應用程式組的佈署，可以強制關注點分離。
交付基礎設施程式碼
管道隱喻描述了基礎設施程式碼的變更如何從做出變更的人員到生產例項。這個交付過程所需的活動影響程式碼函式庫的組織方式。
交付程式碼版本的管道有多種活動型別，包括構建、提升、應用和驗證。管道中的任何給定階段可能涉及多種活動。
構建基礎設施專案
構建基礎設施專案準備程式碼供使用。活動可能包括檢索構建時依賴項、解析構建時設定、編譯或轉換程式碼、執行測試、準備程式碼供使用以及使程式碼可用。
對於某些工具，“準備程式碼供使用"涉及將檔案組裝成特定格式的包檔案，即工件。一些團隊為基礎設施工件構建自己的工件，將堆積疊程式碼或伺服器程式碼捆綁到ZIP檔案或"tarballs"中。
使用儲存函式庫交付基礎設施程式碼
團隊使用原始碼儲存函式庫來儲存和管理其基礎設施原始碼的變更。他們通常使用單獨的儲存函式庫來儲存準備好交付到環境和例項的程式碼。
交付儲存函式庫通常儲存給定專案程式碼的多個版本。提升階段標記專案程式碼的版本，以顯示它們已進展到哪個階段。
專案整合模式
程式碼函式庫中的專案通常彼此之間有依賴關係。下一個問題是何時以及如何組合相互依賴的不同版本專案。
構建時間專案整合模式在多個專案之間執行構建活動。這涉及整合它們之間的依賴關係並設定跨專案的程式碼版本。
flowchart TD
A[開始構建] --> B[檢索依賴項]
B --> C[解析設定]
C --> D[編譯程式碼]
D --> E[執行測試]
E --> F[準備工件]
F --> G[結束構建]
圖表翻譯：
此圖示展示了一個基本的構建流程。流程始於「開始構建」階段，接著檢索依賴項、解析設定、編譯程式碼、執行測試、準備工件，最後結束構建。這個流程清晰地說明瞭構建過程中各個階段的順序和邏輯關係。
交付時間專案整合
給定多個相互依賴的專案，交付時間專案整合在組合它們之前單獨構建和測試每個專案。這種方法比構建時間整合更晚地整合程式碼版本。
# 示範專案整合的Python程式碼
def integrate_projects(project1, project2):
"""整合兩個專案"""
# 單獨構建和測試每個專案
build_and_test(project1)
build_and_test(project2)
# 組合專案
combined_project = combine_projects(project1, project2)
return combined_project
def build_and_test(project):
"""構建和測試專案"""
# 構建專案
build_project(project)
# 測試專案
test_project(project)
def combine_projects(project1, project2):
"""組合兩個專案"""
# 組合邏輯
return combined_project
內容解密：
此程式碼定義了一個名為integrate_projects的函式，用於整合兩個相互依賴的專案。函式首先單獨構建和測試每個專案，然後組合它們。build_and_test函式負責構建和測試單個專案，而combine_projects函式負責組合兩個專案。這種方法確保了每個專案在組合前都是可用的，並且可以獨立測試。
應用時間專案整合
應用時間專案整合涉及將多個專案分別推播透過交付階段。當有人更改專案的程式碼時，管道將更新的程式碼應用到該專案交付路徑中的每個環境。
flowchart TD
A[開始交付] --> B[推播變更]
B --> C[應用到環境1]
C --> D[應用到環境2]
D --> E[結束交付]
圖表翻譯：
此圖示展示了一個基本的應用時間專案整合流程。流程始於「開始交付」階段，接著推播變更到不同的環境，最後結束交付。這個流程清晰地說明瞭變更如何在不同環境中被應用。
在組織基礎設施程式碼時，需要考慮多個因素，包括組態管理、團隊結構、交付流程以及專案整合策略。選擇適合組織需求和團隊結構的方法，可以提高基礎設施管理的效率和可靠性。最終，穩健的基礎設施即程式碼實踐需要結合適當的工具、流程和文化變革。
