摘要：對於一個合格的CloudNative應用，應該把自己的程序當做開源軟件來編寫的，不該將數據庫連接信息和密碼放在代碼里，一定要將配置外置。
對於一個合格的CloudNative應用，應該把自己的程序當做開源軟件來編寫的，不該將數據庫連接信息和密碼放在代碼里，一定要將配置外置。
因此我試着在華為雲上落地這套標准，期間嘗試了從ServiceStage、CCE、CSE這三個入口進行配置注入，最終實現能夠在應用啟動時，主動拉取配置，覆蓋本地配置文件里的調試配置，並能夠在線配置並生效。
打法是：CCE配置啟動參數，制定SpringProfiles；配合CSE做應用配置，將資源外置后的配置記錄於此，並可以動態更新，最終實現了配置外置的訴求。
另外，通過這次增加的多版本管理，嘗試梳理了一下ServiceStage的組件、CCE的workload、CSE的應用和微服務之間，錯綜復雜的概念之間的關系，個人淺見，歡迎指正：
1. 初始化配置
在系統初始化的時候，不可能一點配置都沒有，所以保留一些基礎配置在配置文件里是有必要的。配置外置並不意味着100%的配置都要外置，而是把外部依賴資源的配置，特別是容易變化配置外置。
1.1 啟用Bootstrap和Spring profile
在代碼層面，首先要進行基礎配置。先看代碼結構，這里除了最基本的application.yaml，增加了bootstrap.yaml和*-dev.yml等帶后綴的文件。
介紹一下原理：
- 首先介紹Bootstrap Application Context：
它是Spring Cloud Context的父Context，所以從外部配置源里加載配置一般從這里來，且優先級高於其他一切配置文件。於是，我們也利用這個能力，借助CSE的微服務配置中心能力，進行Spring的外部參數寫入。
- 然后介紹Spring profiles：
為了把通用配置和環境相關的配置區分開，比如DEV環境沒有AK/SK認證，而線上環境都有認證，這種配置項上的區別，引入了Spring profiles的概念，當Springboot啟動的時候，會根據profiles.active參數判斷應該啟用那個環境配置
PS：參考SpringCloud官方解釋
另外，就是哪些配置應該放在配置文件里，理論上除了最基礎的配置，在啟動時使用的，其余的配置都可以放在CSE的微服務配置中心里，而不必在本地配置文件里存在，另外就是本地配置里存在的，也可以通過二次設置在微服務的配置中心里，進行覆蓋，比如數據庫連接池的大小，而不需要修改代碼，至於改完以后，要不要重啟，那就得看生效的邏輯了。
1.2 引入CSE配置中心
CSE配置中心引入，需要先引入依賴包，然后在bootstrap.yaml中配置CSE配置中心的地址、認證信息等。
這里可以參考官方文檔，主要關注bootstrap.yaml的配置參數：使用分布式配置中心
補充：獲取spring-cloud-starter-huawei-config的版本
參考地址：huaweicloud/spring-cloud-huawei
可以參考現有的SpringCloud基線版本，選擇SpringCloud-Huawei的版本
補充：關於配置中心的優先級
微服務引擎提供了分層次的配置機制。按照優先級從高到低，分為：
- 配置中心（動態配置）
- Java System Property（-D參數）
- 環境變量
- 配置文件
參考官方文檔：配置微服務
2. 本地CSE配置中心能力驗證
前提條件，本地得安裝一個Local-CSE並啟動，這部分參考雲上DevOps：2.1-本地環境准備
2.1 配置application.yaml和bootstrap.yml
原始文件可以參考Github的Demo，配置文件入口，我這里進行了修改，因為bootstrap.yaml優先級高於application.yaml，參數只要在bootstrap.yaml中出現過，就不會使用application.yaml中的配置了。
上代碼，application.yaml，可以看到配置很少，因為大部分bootstrap.yml中已經包含，就都去掉了
這是bootstrap.yml，注意這里的spring.application.name、spring.cloud.servicecomb.discovery.appName和spring.cloud.servicecomb.discovery.version會組成一個微服務私有的參數作用域，這里的優先級高於全局作用域application。特別注意，雲上的CSE環境，除了上面提到的，還需要增加server.env參數。另外，server.env有四個參數可以選development、testing、acceptance、production
關於如上參數的定義，參考官方文檔：使用分布式注冊中心和官方文檔：使用分布式配置中心。
2.2 准備驗證代碼
直接上代碼
2.3 靜態配置能力
為了驗證CSE配置中心的參數，是否能覆蓋application.yaml中的參數配置，我選了一個很特別的參數：spring.datasource.password，如果能夠覆蓋成功，那么啟動后，創建數據庫連接池一定會報錯。
- 首先，打開本地CSE配置中心，地址為：http://localhost:30106/#/cse/services/config，創建一個配置項，作用域選VodMgrService@CabgOne#1.0.0，關於application的作用域后面再解釋。
- 重啟本地微服務，啟動后創建數據庫連接池就報錯了，符合預期。
結論：CSE配置中心的參數，能夠覆蓋application.yaml中的參數配置
2.4 動態配置能力
為了驗證CSE配置中心的參數動態生效，需要使用注解@RefreshScope，同時也引入ConfigRefreshEvent來監聽事件變化，這樣就會得到一個效果，對於動態生效的參數，可能需要一些重建或刷新，比如連接池、緩存、Client等。
- 首先，增加一個配置項config.value
- 然后很快可以看到后台日志打印出來，包括自己的監聽器，也響應了日志
- 查看一下數據，已經響應為TryMe
- 具體的配置，在后台是輪詢的，響應周期配置參數為cloud.servicecomb.config.watch.delay，目前是10秒一次
- 修改一下配置，為TryMeAgain
- 再看后台日志，有新的觸發器發生
- 再次請求API，數據已經更新
- 再深入去看，這里的getChange()返回是一個Set<String>，因此可以針對特定的參數做文章。
結論：本地CSE配置中心的參數能夠動態刷新，並開放了ConfigRefreshEvent，以擴展配置更新后的業務動作。
2.5 配置的作用域限制
目前CSE的配置中心提供兩級作用域限制，一個是全域，一個是私域，即微服務內部（不同版本有區分）。
- 增加一個作用域為application的全域參數，一個作用域為VodMgrService@CabgOne#1.0.0的私域同名參數
- 驗證一下，生效的作用域是VodMgrService@CabgOne#1.0.0
- 刪除私域參數后，生效的作用域是application
結論：本地CSE配置中心的全域配置的優先級，低於微服務內部配置，即私域配置可以覆蓋全域配置。
3. 雲上配合外置落地
3.1 代碼提交並自動打包推送SWR
代碼提交，推送到CodeHub上，流水線在CloudPipeline自動驅動起來，開始執行，打包、制作鏡像、推送SWR，並且展開了代碼質量檢查。這些得益於前面的WIKI：Phase2 - 雲上DevOps
3.2 CCE啟動參數配置
由於ServiceStage的自動部署能力還不滿足，所以手工將DockerImage升級到環境上，這里直接使用CCE進行操作，原因在題記里介紹了，ServiceStage的參數配置不太好用
3.2.1 利用CCE的容器啟動命令寫入參數
- 選擇升級版本，點高級配置，CCE的核心配置入口都在這里了
- 在啟動時，注入最核心的一個參數-Dspring.profiles.active=uat
- 此處的命令是Docker啟動是的ENTRYPOINT，下面那個是CMD，會覆蓋Dockerfile里的命令
- 點擊右下角的提交，會看到實例列表中已經有一個新的pod在啟動
- 回到AOM服務，查看日志，會發現The following profiles are active: uat，符合預期
3.3 CCE環境變量配置
3.3.1 利用CCE的環境變量寫入參數
- 首先回退上面那一步的配置，進入高級設置->環境變量
- 增加環境變量JAVA_TOOL_OPTIONS，值設置為-Dspring.profiles.active=uat
- 提交以后查看日志，符合預期
至於為啥JAVA_TOOL_OPTIONS能用，因為JVM原生就包含這個參數，可以用來在啟動時寫入配置，可以參考Oracle的官方文檔
3.4 CCE配置中心
3.4.1 利用CCE的配置中心 + 環境變量寫入參數
CCE的配置中心包含了兩個大類，配置項ConfigMap和秘鑰Secret，前面介紹的CCE環境變量，支持從配置中心導入參數，比如我可以在ConfigMap里寫入這個參數，然后在CCE的環境變量中引入。
- 首先創建一個配置項，這里的配置項是按照集群、命名空間區分的
- 然后創建一套配置項，輸入一套KV
- 回到CCE升級的步驟，修改環境變量，增加一項配置項寫入的變量，可以選到剛才輸入的KEY，就不用輸入VALUE了
然后再看看秘鑰，玩兒法類似，但是有一點很“有趣”：這里的秘鑰是要主動用BASE64轉碼過才能保存，不過在使用的時候，會解密的，因此不必關心轉碼回來的問題。
3.4.2 利用CCE的配置中心 + 數據存儲寫入參數
無論是配置項ConfigMap還是秘鑰Secret，都可以支持利用CCE的數據存儲掛載能力寫入參數到容器里，簡單理解，就是會自動幫你把配置下載到一個容器的存儲位置上，文件名是KEY，內容是VALUE，可以在代碼里讀取這個配置。
配置方式很簡單，選擇配置項，然后寫一個掛載目錄即可
3.5 雲上CSE配置中心
這里是另一個核心，線下驗證過，雲上的CSE類似，但是配置模型更復雜，增加了server.env維度，並且全域和私域參數配置位置不一樣。
- 首先，從ServiceStage->微服務CSE->配置管理，進入全域配置頁面，選擇環境為yaml里配置的server.env參數
返回結果為，生效
PS：如果這里不選環境，則參數無法讀取，即環境為空也是一類環境，不同環境之間隔離
- 然后，從ServiceStage->微服務CSE->微服務目錄，進入私域頁面
進而選擇動態配置，在配置作用域時，選擇不帶version的，環境是固定值，
返回結果為，生效
- 同樣的頁面下，在配置作用域時，選擇帶version的，
返回結果為，生效
總結：雲上CSE配置中心參數加載優先級
- P1：微服務私域，帶Version
- P2：微服務私域，無Version
- P3：全域，帶環境
其余參數都不生效，包括全域無環境、全域不同環境、微服務私域不同Version
總結
綜上，基於華為雲ServiceStage、CCE、CSE的配置外置能力，可以支撐微服務在不同環境中靈活部署，而無需修改代碼。目前的總結打法是：
- 利用CCE的容器啟動參數，或環境變量，寫入profiles.active參數
- 利用CSE的配置中心，寫入業務參數，如MySQL連接串、連接池配置、GES引擎地址、VOD服務Endpoint地址等
本文分享自華為雲社區《[CloudNative] 企業應用上雲實踐手記-Cloud Native Phase 3 - 雲原生應用AutoConfig》，作者：關耳山石