實施以應用程式為中心 第 3 部分：宣告式合約與平台抽象化的力量

繼續我們的以應用程式為中心的基礎架構 (ACI) 系列

在第 1 部分中，我們介紹了以應用程式為中心的基礎架構 (ACI) 的概念，以及為何它對管理現代分散式系統至關重要。在第 2 部分中，我們探討了傳統以基礎架構為中心的方法的常見陷阱，以及簡單 GitOps 模型的局限性。現在，在第 3 部分，我們將深入探討「如何做」：ONDEMANDENV 如何透過其核心元件，特別是 contractsLib 以及獨立、可比較環境 (Envers) 的概念，來實現真正的 ACI？

傳統的僵局：孤島、靜態環境與範圍盲點

在理解 ONDEMANDENV 的解決方案之前，讓我們先回顧一下傳統設定中的典型挑戰：

• 團隊孤島化與範圍局部化： 開發團隊通常只專注於其特定的微服務或應用程式。他們可能缺乏對其變更對下游或上游服務的需求和影響的了解，甚至會忽略這些。正如在「複雜性的糾纏」中所討論的，這種「範圍局部化」意味著關鍵的相依性和整合點往往很晚才被發現，從而導致摩擦和不穩定。
• 單體式、靜態環境： 系統通常部署到少數共享的、長生命週期的環境中（例如，開發、QA、預備、生產）。在每個環境中，一個服務通常作為單一執行個體存在，與部署在那裡的所有其他服務緊密耦合。更新單一服務通常需要複雜的協調，或冒著破壞整個共享環境穩定性的風險。
• 營運距離： 這些共享環境經常由獨立的營運或 DevOps 團隊管理。雖然這些團隊技術嫻熟，但他們可能對特定的應用程式相互依賴性或特定開發團隊變更的直接利害關係缺乏深入的了解。
• 無法比較： 對跨越多個服務的複雜、間歇性問題進行偵錯變成一場噩夢。為什麼？因為沒有實用的方法來建立和比較系統或其子元件的略有不同、隔離的執行狀態。您只能分析單體部署中的日誌和指標，試圖推斷跨服務邊界的因果關係。

contractsLib：分散式系統的程式碼化議會

ONDEMANDENV 引入 contractsLib 作為其 ACI 實作的基石。不要僅將其視為組態，而應將其視為一個**程式碼化、宣告式的議會**，其中每個應用程式和服務都必須明確說明其需求、相依性和提供的介面。

contractsLib 的主要面向：

• 宣告式事實來源： 應用程式合約定義了應用程式*需要*什麼，而不是*如何*佈建它。這包括：
  • 對其他服務特定版本的相依性（消費者）。
  • 所需的平台功能（例如，資料庫類型、訊息佇列、快取層）。
  • 特定的組態或環境變數。
  • 資源需求（CPU、記憶體）。
  • 公開的介面或端點（產品）。
• 強制早期可見性： 透過要求在程式碼中明確宣告，contractsLib 在開發週期的*早期*就突顯了潛在的衝突、不相容性和整合挑戰。孤島化的團隊再也無法對其對更廣泛系統的影響視而不見；他們的「真實面貌」和假設都在合約中暴露無遺。
• 架構即程式碼： contractsLib 提供了系統架構和元件互動的高階、版本控制的表示。它不僅僅是基礎架構程式碼；它是一個關於服務如何相互關聯以及與平台關聯的動態藍圖。
• 平台維護/強制執行： 這些合約不僅僅是文件；它們是 ONDEMANDENV 平台不可或缺的一部分。平台讀取、驗證並使用這些合約來協調部署和強制執行約束。在平台權限之外宣告的合約無效。

# contractsLib 定義的概念性範例（語法僅供說明）
AppContract(appName='order-service', version='1.2.0') {
  dependencies: [
    ServiceDependency(name='payment-service', version='~>2.1'), # 取用 payment-service v2.1.x
    ServiceDependency(name='inventory-service', tag='stable'),   # 取用標記為 'stable' 的 inventory-service
  ],
  platformNeeds: [
    Database(type='postgres', size='medium'),
    MessageQueue(name='order-events'),
  ],
  configuration: {
    API_TIMEOUT_MS: 500,
    FEATURE_FLAG_X: true,
  },
  provides: [
    ApiEndpoint(path='/orders', port=8080), # 供其他產品使用
  ]
}
    

掙脫束縛：隨需應變、隔離的 Envers

基於 contractsLib，ONDEMANDENV 徹底改變了環境管理。它不再強迫所有服務進入少數單體環境，而是允許**每個應用程式/服務團隊建立多個獨立的、隨需應變的 Envers**（環境版本）。

一個 Enver 是一個基於特定版本的程式碼及其在 contractsLib 中宣告的合約（包括其精確的相依性）的、完全佈建的、可執行的應用程式執行個體。至關重要的是：

• 隔離： 每個 Enver 獨立執行，不受其他 Envers 或傳統共享環境的影響。
• 獨立性： 團隊可以根據功能分支、特定提交或不同的相依性版本建立 Envers，而無需等待環境空位或協調複雜的共享部署。
• 真正的 ACI： 環境*屬於*合約中定義的應用程式版本，而不是反過來。

偵錯的超能力：比較隔離的環境

這種獨立性釋放了傳統設定中缺失的一項關鍵功能：**直接比較不同執行環境的能力。** 這對於偵錯分散式系統中的複雜問題非常強大：

• 程式碼差異： 錯誤是由您最新的程式碼變更引起的嗎？為您的功能分支 (feature-xyz) 啟動一個 Enver，再為 main 分支啟動另一個 Enver。將它們部署，對兩者執行相同的測試，並在完全隔離的情況下直接比較行為、日誌和資源使用情況。差異*必定*與程式碼變更相關。
• 相依性問題： 升級相依性（例如，payment-service 從 v2.1 到 v2.2）會導致問題嗎？為您的 order-service 建立兩個 Envers：一個簽訂 payment-service v2.1 合約，另一個簽訂 v2.2 合約。並排比較它們的行為，以找出由相依性變更引起的整合問題。
• 組態漂移： 懷疑組態差異導致問題嗎？建立兩個在其合約中定義了略微不同組態的 Envers。比較它們以隔離特定設定的影響。
• 重現錯誤： 透過啟動相應的 Enver，輕鬆重現發生錯誤的確切條件（程式碼版本、相依性、組態），從而大幅加快診斷速度。

這種比較隔離的、功能齊全的環境的能力，將偵錯從基於共享環境中分散日誌的猜測，轉變為確定性的排除過程。

平台抽象化：使其成真

contractsLib 中的宣告式合約如何變成一個執行中的、隔離的 Enver？這就是 ONDEMANDENV 中**平台抽象層**的角色。

• 解譯與協調： 平台讀取應用程式合約，理解宣告的相依性和平台需求，並協調底層基礎架構的佈建（在目前的實作中使用 AWS CDK 等工具）。
• 處理複雜性： 它根據合約和平台策略管理橫切關注點——設定網路、安全邊界、服務探索、秘密管理、基本可觀察性——從而使應用程式開發人員免於這種複雜性。
• 確保一致性： 透過從合約驅動佈建，平台確保產生的 Enver 忠實地代表應用程式宣告的狀態。
• 可移植性： 雖然目前的實作可能使用 AWS CDK，但 contractsLib 定義本身與工具無關。平台抽象層允許底層實作在不強制變更應用程式合約的情況下進行演進。

結論：透過 ACI 實現真正的敏捷性

實施以應用程式為中心的基礎架構不僅僅是採用新工具；它需要觀念的轉變。ONDEMANDENV 透過提供以下功能來促進這種轉變：

1. contractsLib： 一個程式碼化的議會，強制明確宣告相依性和需求，從而實現架構即程式碼和早期整合可見性。
2. 獨立的 Envers： 與特定應用程式合約版本綁定的隔離的、隨需應變的環境，使團隊擺脫單體環境的限制。
3. 可比較性： 並排啟動和比較不同環境狀態的關鍵能力，徹底改變了偵錯和驗證。
4. 平台抽象化： 一個智慧層，將宣告式合約轉換為執行中的現實，並管理底層的複雜性。

透過結合這些元素，ONDEMANDENV 超越了傳統方法的局限性，最終實現了微服務敏捷性的承諾，並馴服了分散式系統的複雜性。