組態管理概述#

組態是軟體系統中容易被忽視但又至關重要的部分。良好的組態管理可以提升系統的靈活性和可維護性，但組態過多或管理不當也可能成為系統的負擔。

組態是一把雙刃劍：合理的組態可以讓系統更靈活；過度的組態則會增加複雜度，成為維運的負擔。

什麼需要組態化#

適合組態化的內容：

• 環境相關的參數（資料庫連接、服務地址）
• 可能需要動態調整的閾值（超時時間、重試次數）
• 功能開關（Feature Toggle）
• 業務規則參數（折扣率、限額）

不適合組態化的內容：

• 核心業務邏輯
• 很少變更的固定值
• 可以透過程式碼推導的值

組態管理的挑戰#

組態的三個階段#

根據組態生效的時機，可以將組態分為三個階段：

建構時組態（Build-time）#

建構時組態在程式碼編譯打包階段確定，打包完成後無法修改。

實作方式：Maven Profile

<profiles>
    <profile>
        <id>dev</id>
        <properties>
            <db.url>jdbc:mysql://localhost:3306/dev</db.url>
            <log.level>DEBUG</log.level>
        </properties>
    </profile>
    <profile>
        <id>prod</id>
        <properties>
            <db.url>jdbc:mysql://db.prod:3306/prod</db.url>
            <log.level>INFO</log.level>
        </properties>
    </profile>
</profiles>

建構指令：

# 開發環境建構
mvn package -P dev

# 生產環境建構
mvn package -P prod

優點：

• 組態在建構時確定，執行期行為可預測
• 組態與程式碼一起版本控制

缺點：

• 不同環境需要不同的製品（artifact）
• 組態變更需要重新建構

建構時組態會導致「一份程式碼，多份製品」的問題，與持續交付的「一次建構，到處部署」原則衝突。應該盡量避免使用。

打包時組態（Package-time）#

打包時組態在部署階段注入，同一份製品可以部署到不同環境。

實作方式：組態生成工具

flowchart LR
    A["通用製品<br/>app.jar"] --> C["最終部署包"]
    B["環境組態<br/>config.yml"] --> C

    style A fill:#e3f2fd
    style B fill:#fff3e0
    style C fill:#e8f5e9

範例流程：

1. 建構產生通用製品：app.jar
2. 部署時根據目標環境生成組態
3. 將製品和組態一起部署

# config-template.yml（組態模板）
database:
  url: ${DB_URL}
  username: ${DB_USERNAME}
  password: ${DB_PASSWORD}

server:
  port: ${SERVER_PORT:8080} # 預設值

# 部署腳本
envsubst < config-template.yml > config.yml
java -jar app.jar --spring.config.location=config.yml

優點：

• 一次建構，多環境部署
• 組態與製品分離

缺點：

• 部署流程變複雜
• 需要組態管理工具支援

執行時組態（Runtime）#

執行時組態可以在應用運行過程中動態變更，無需重啟服務。

使用場景：

• 功能開關的快速切換
• 業務參數的即時調整
• 限流閾值的動態變更
• 日誌等級的臨時調整

實作方式：組態中心

flowchart TB
    subgraph 組態中心
        CC["Apollo / Nacos / Consul"]
    end

    subgraph 管理端
        UI["管理介面<br/>(Web UI)"]
    end

    subgraph 應用端
        APP["應用實例"]
        L["監聽器"]
    end

    UI -->|管理| CC
    CC -->|推送/拉取| APP
    APP --- L

    style CC fill:#e3f2fd
    style UI fill:#fff3e0
    style APP fill:#e8f5e9

執行時組態的即時生效能力非常強大，但也要謹慎使用。錯誤的組態變更可能導致線上故障。應該建立組態變更的審核和回滾機制。

組態中心實踐#

組態中心是管理分散式系統組態的核心基礎設施。

Apollo 組態中心#

Apollo 是攜程開源的組態管理平台，是業界廣泛使用的組態中心解決方案。

核心功能：

架構組件：

flowchart TB
    Portal["Portal<br/>(Web 管理介面)"]
    Admin["Admin Service<br/>(組態管理服務)"]
    Config["Config Service<br/>(組態獲取服務)"]
    A["Client A"]
    B["Client B"]
    C["Client C"]

    Portal --> Admin
    Admin --> Config
    A --> Config
    B --> Config
    C --> Config

    style Portal fill:#e3f2fd
    style Admin fill:#fff3e0
    style Config fill:#e8f5e9

使用範例（Spring Boot 整合）：

@Configuration
@EnableApolloConfig
public class AppConfig {

    @Value("${timeout:1000}")
    private int timeout;

    @ApolloConfigChangeListener
    private void onChange(ConfigChangeEvent event) {
        // 組態變更時的處理邏輯
        for (String key : event.changedKeys()) {
            ConfigChange change = event.getChange(key);
            log.info("Config changed - key: {}, old: {}, new: {}",
                key, change.getOldValue(), change.getNewValue());
        }
    }
}

敏感組態管理#

資料庫密碼、API 金鑰等敏感組態需要特殊處理。

常見錯誤做法#

以下做法可能導致敏感資訊洩漏：

• 將密碼明文寫在組態檔中
• 將含有敏感資訊的組態檔提交到 Git
• 在日誌中輸出敏感組態
• 將敏感資訊寫入環境變數但未做保護

最佳實踐#

1. 敏感組態加密

使用加密工具對敏感組態進行加密存儲：

# 加密前
database:
  password: MySecretPassword

# 加密後
database:
  password: ENC(dGhpcyBpcyBhbiBlbmNyeXB0ZWQgdmFsdWU=)

2. 使用 Secret 管理工具

3. 環境變數 + 權限控制

# 從 Vault 獲取密鑰並設為環境變數
export DB_PASSWORD=$(vault read -field=password secret/db)
java -jar app.jar

4. 應用啟動時注入

@Configuration
public class SecretConfig {

    @Bean
    public DataSource dataSource(VaultTemplate vault) {
        String password = vault.read("secret/db")
            .getData().get("password");

        HikariConfig config = new HikariConfig();
        config.setPassword(password);
        return new HikariDataSource(config);
    }
}

組態變更管理#

組態變更可能和程式碼變更一樣影響系統行為，需要同樣嚴謹的管理流程。

組態變更流程#

flowchart LR
    A[提交變更] --> B[審核]
    B --> C[灰度發布]
    C --> D[全量發布]

    B -.->|拒絕/修改| A
    C -.->|驗證失敗| B
    D -.->|回滾| C

    style A fill:#e3f2fd
    style B fill:#fff3e0
    style C fill:#e8f5e9
    style D fill:#f3e5f5

組態變更檢查清單#

• 變更目的和影響範圍是否清楚
• 是否在測試環境驗證過
• 是否有回滾方案
• 是否通知了相關團隊
• 是否選擇了合適的變更時間窗口

組態回滾策略#

即時回滾（執行時組態）：

• 在組態中心直接回退到上一版本
• 變更即時生效

部署回滾（打包時組態）：

• 重新部署使用舊組態的版本
• 需要經過完整的部署流程

建議在組態中心設定自動快照，每次變更前自動保存當前組態狀態，方便快速回滾。

組態管理原則#

1. 組態與程式碼分離#

組態不應該硬編碼在程式碼中，應該外部化管理。

// 錯誤示範
private static final String DB_URL = "jdbc:mysql://localhost:3306/db";

// 正確做法
@Value("${database.url}")
private String dbUrl;

2. 環境無關的製品#

同一份建構製品應該可以部署到任何環境，環境差異透過組態注入。

3. 敏感組態特殊處理#

密碼、金鑰等敏感組態必須加密存儲，訪問需要授權。

4. 組態變更可追溯#

所有組態變更都應該記錄：誰、在什麼時間、改了什麼、為什麼改。

5. 合理的預設值#

組態應該有合理的預設值，減少必要組態項的數量。

@Value("${http.timeout:3000}")  // 預設 3000ms
private int httpTimeout;

6. 組態驗證#

應用啟動時應該驗證組態的有效性，避免執行期錯誤。

@PostConstruct
public void validateConfig() {
    if (timeout <= 0) {
        throw new IllegalArgumentException("timeout must be positive");
    }
    if (StringUtils.isEmpty(serviceUrl)) {
        throw new IllegalArgumentException("serviceUrl is required");
    }
}

總結#

組態管理是持續交付中容易被忽視但影響深遠的環節。

關鍵要點：

1. 理解三個組態階段的適用場景

   • 建構時組態：盡量避免
   • 打包時組態：環境相關的靜態組態
   • 執行時組態：需要動態調整的參數

2. 使用組態中心統一管理分散式系統的組態

3. 敏感組態需要特殊保護

   • 加密存儲
   • 權限控制
   • 審計追蹤

4. 組態變更需要和程式碼變更一樣嚴謹

   • 審核流程
   • 灰度發布
   • 回滾方案

組態管理的終極目標是讓組態「隱形」——開發人員專注於業務邏輯，組態由平台自動處理；維運人員可以安全、方便地調整系統行為，而不需要重新部署。