Choerodon 的微服務之路（四）：深刻理解微服務配置中心

本文是Choerodon 的微服務系列推文第四篇，上一篇《Choerodon的微服務之路（三）：服務註冊與發現》介紹了Choerodon的註冊中心，並經過代碼的形式介紹了 在Choerodon微服務框架中是如何來實現服務註冊和發現的，本篇將介紹配置中心在微服務架構中的做用。

▌文章的主要內容包括：

• 配置是什麼
• 爲何須要微服務配置中心
• 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

4. 將服務運行中須要的配置添加在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: http://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

5. 開發階段，每一個開發人員本身的本地配置，添加在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

6. 配置的優先級遵循：環境變量>配置文件。經過Chart在部署時根據環境的不一樣，修改具體的環境變量值，來實現不一樣環境配置的不一樣，以下圖所示：

7. 對於緊要的配置修改經過配置中心修改，動態生效。對於實時性要求不高的配置，經過修改部署時的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仍需持續考慮的問題。

更多關於微服務系列的文章，點擊藍字可閱讀 ▼

• Choerodon的微服務之路(一)：如何邁出關鍵的第一步
• Choerodon的微服務之路(二)：微服務網關
• Choerodon 的微服務之路（三）：服務註冊與發現

關於Choerodon豬齒魚

Choerodon豬齒魚是一個開源企業服務平臺，是基於Kubernetes的容器編排和管理能力，整合DevOps工具鏈、微服務和移動應用框架，來幫助企業實現敏捷化的應用交付和自動化的運營管理的開源平臺，同時提供IoT、支付、數據、智能洞察、企業應用市場等業務組件，致力幫助企業聚焦於業務，加速數字化轉型。

你們也能夠經過如下社區途徑瞭解豬齒魚的最新動態、產品特性，以及參與社區貢獻：

• 官網：http://choerodon.io
• 論壇：http://forum.choerodon.io
• Github：https://github.com/choerodon
• 微信：Choerodon豬齒魚
• 微博：Choerodon豬齒魚

歡迎加入Choerodon豬齒魚社區，共同爲企業數字化服務打造一個開放的生態平臺。