豬齒魚的微服務之路（四）：深入理解微服務配置中心

• 2022 年 1 月 5 日
• 筆記
• DevOps, 雲原生, 雲計算, 微服務

▌文章的主要內容包括： – 配置是什麼 – 為什麼需要微服務配置中心 – 豬齒魚Choerodon的配置中心

在早期單體應用的時代，監控等系統配置管理可能並不是什麼困難的問題。但是在微服務架構中，和安全、日誌、非功能需求一樣，配置管理也是一種非功能需求。配置中心也是整個微服務架構體系中的一個重要組件，即使它的功能看上去並不起眼，無非就是簡單配置管理和存取，但它是整個微服務架構中不可或缺的一環。

在Choerodon的微服務體系中，如何通過更加高效的配置管理方式，幫助微服務系統進行配置規劃，推動項目的持續交付，動態調整和控制系統的運行狀態，這些問題都值得深入思考和研究。

配置是什麼

在講配置中心之前，首先提到一個核心的概念，就是服務的「配置」。配置可能各位都不陌生，一個配置項大多是key-value的形式，value可能是一個有限值的集合。Choerodon通過這些配置項，來控制系統的運行狀態，可以說，配置其實是獨立於程式的可配變數，同一份程式在不同配置下會有不同的行為。

常見的配置有如下幾種：

• 程式內置的硬編碼：在開發過程中將配置寫死，這種形式幾乎不具備任何的擴展性可動態修改的能力。通常是不建議的！
• 程式配置文件：Springboot提供了一種方式將配置放在application.properties或者application.yaml文件中，系統運行時的大部分配置，都可以通過這種格式進行配置。不同環境會有各自的配置文件。
• 環境變數：將配置預製在作業系統的環境變數中，在程式運行時讀取。尤其在docker容器中，不同容器間相互隔離，環境變數不會受到影響。
• 啟動參數：可以在程式啟動時制定參數，修改時需要重新啟動。
• 資料庫存儲：易變化的配置存儲在資料庫中，這樣在運行期可以靈活的調整。

而微服務的配置中心，將散落在各處的應用系統配置資訊收集起來，進行集中式的統一管理，並且提供額外功能，如動態刷新，版本控制，功能開關等。

舉一個簡單的例子，有這樣的一個配置：logging.level。在生產環境上的日誌級別通常為error級別，但是在一些測試環境，或者當系統出問題時，開發人員會期望日誌的級別為debug，此時則需要一種機制來幫助實現。

為什麼需要微服務配置中心

既然已經有了這麼多種形式來管理配置，又為什麼要引入配置中心呢？

在傳統單體應用中，開發者將系統打成一個包，並在包里提供一些配置，當需要修改配置時，只需要登錄到伺服器上將配置修改，然後reload一下就可以了。

在微服務體系中，服務的數量以及配置資訊日益增多，比如各種伺服器參數配置、各種資料庫訪問參數配置、各種環境下配置資訊的不同、配置資訊修改之後實時生效等等，顯然開發者已經不可能登錄到一台台虛擬機中，對配置進行修改重啟，並且，傳統的配置管理可能會帶來如下的一些問題：

• 配置的格式不一致：有的使用xml，有的使用properties，還有一些存在資料庫中，不同項目對於配置的管理方式五花八門。
• 失效性低：配置大多使用靜態文件的格式，再通過打包放入容器中運行。當實例過多時，需要修改完配置重新打包，周期較長。
• 不安全：配置跟隨源程式碼保存在程式碼庫中，容易造成配置泄漏。同時不同環境的配置不同，稍不注意，可能會將測試環境的配置帶入生產環境，引發事故。
• 功能局限：不支援動態調整。

同時，隨著「微服務+容器化+DevOps」落地，對於服務的配置管理也提出了更高的要求。

• 程式碼與配置分離：遵循「一次打包，多處部署」的原則。將程式碼和配置分離。配置單獨管理。
• 配置抽象：屏蔽後台實現，提供頁面管理功能。
• 跨環境跨集群：支援對多環境和多集群應用配置的集中式管理。
• 實時性：配置更新需要儘快通知到客戶端。
• 可治理：配置審計、版本管理、許可權控制。

所以，一個能夠方便用戶進行自助式的配置管理，標準化的配置中心服務，是Choerodon社區里的開發者急切所需的。

Choerodon的配置中心

配置分類

在Choerodon豬齒魚中，將服務的配置按照不同的功能，大致分為3類。

• 靜態配置：程式打包前一次配置好，一般不會修改。這些配置通常在服務啟動之前生效。如：服務的埠，名稱，配置中心的地址等。
• 部署時配置：程式在部署時添加的配置，一般和環境相關，每個環境不同。如：資料庫配置，其他中間件配置，或者一些服務相關的配置。
• 運行時配置：程式運行時可能會修改的配置，一般用來調整應用的行為和功能。如：日誌級別，功能開關，執行緒池大小等等。

服務配置設計原則

對配置進行分類之後，還需要一種設計原則，來指導開發者對服務的配置進行劃分。在Choerodon豬齒魚中，開發者遵循下面的一些原則。

1. 所有可能要修改的配置，都不應該採取硬編碼的方式。
2. 程式中的配置文件，均使用yaml文件進行管理。
3. 引入spring-cloud-config-client，將服務名，埠號，管理埠，等不會修改的配置，添加在src/main/resources/bootstrap.yml，如下所示：

# bootstrap.yml
server:
  port: 8080
spring:
  application:
    name: iam-service
  cloud:
    config:
      failFast: true
      retry:
        maxAttempts: 6
        multiplier: 1.5
        maxInterval: 2000
      uri: localhost:8010
      enabled: false
management:
  port: 80381
  security:
    enabled: false
security:
  basic:
    enabled: false

1. 將服務運行中需要的配置添加在src/main/resources/application.yml。包括註冊中心的地址，資料庫連接，並為這些配置添加默認值，如下所示：

# application.yml
spring:
  datasource:
    url: jdbc:mysql://localhost/iam_service?useUnicode=true&characterEncoding=utf-8&useSSL=false
    username: choerodon
    password: 123456
eureka:
  instance:
    preferIpAddress: true
    leaseRenewalIntervalInSeconds: 10
    leaseExpirationDurationInSeconds: 30
    metadata-map:
      VERSION: v1
  client:
    serviceUrl:
      defaultZone: //localhost:8000/eureka/
    registryFetchIntervalSeconds: 10
hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 15000
ribbon:
  ReadTimeout: 5000
  ConnectTimeout: 5000
mybatis:
  mapperLocations: classpath*:/mapper/*.xml
  configuration: # 資料庫下劃線轉駝峰配置
    mapUnderscoreToCamelCase: true

1. 開發階段，每個開發人員自己的本地配置，添加在src/main/resources/application-default.yml文件中，並且該文件不應該上傳到程式碼庫中，例如本地的資料庫連接配置。

# application-default.yml
spring:
  datasource:
    url: jdbc:mysql://127.0.0.1:3307/iam_service?useUnicode=true&characterEncoding=utf-8&useSSL=false
    username: username
    password: pwd

1. 配置的優先順序遵循：環境變數>配置文件。通過Chart在部署時根據環境的不同，修改具體的環境變數值，來實現不同環境配置的不同，如下圖所示：

1. 對於緊要的配置修改通過配置中心修改，動態生效。對於實時性要求不高的配置，通過修改部署時的values重新部署生效。

配置中心實現

首先來看Spring Cloud自帶的配置中心是怎麼樣的，如下圖所示：

Spring Cloud Config將不同環境的所有配置存放在git 倉庫中，服務啟動時通過介面拉取配置。遵循{ServiceID}-{profile}.properties的結構，按照profile拉取自己所需的配置。

當開發者修改了配置項之後，需要結合spring config bus將配置通知到對應的服務，實現配置的動態更新。

可以看到，Spring Cloud Config已經具備了一個配置中心的雛形，可以滿足小型項目對配置的管理，但仍然有著很多局限性。配置使用git庫進行管理，那麼git庫的許可權如何來判斷？不同環境的安全性也得不到保障。配置的添加和刪除，配置項的匯總，也只能通過git命令來實現，對運維人員也並不友好。

Choerodon豬齒魚在Spring Cloud Config的基礎上，將配置由git庫存儲改為由db存儲。並且添加單獨的manager-service來對配置進行管理。config-server則專註於將配置傳遞給服務。

同時，服務在部署的時候，通過豬齒魚提供的工具包choerodon-tool-config將服務中的application.yml文件初始化到資料庫中。在服務運行時通過前端來對配置進行操作，及時更新配置到各服務上，流程如下圖所示：

同時可以在頁面上依據已有的配置創建新的配置，並將配置應用給正在運行的服務實例。對於失效的配置文件，也可以在頁面中刪除。如下圖所示：

Choerodon豬齒魚通過配置中心管理服務配置的創建，生效，乃至銷毀，並結合Chart來管理服務部署時的配置，通過這樣的一種機制，滿足了對服務配置整個生命周期管理的基本要求和配置版本、動態生效等進一步的需求。

總結

回顧一下這篇文章，整體介紹了配置中心在微服務架構中的作用，並提出了Choerodon對於配置管理的一些心得和規範。服務配置是服務運行起來的基礎，而配置中心是整個微服務技術體系中的關鍵基礎保障，如何做好服務配置規劃，並推動項目的持續交付，則是Choerodon仍需持續考慮的問題。

本文由豬齒魚技術團隊原創，轉載請註明出處