一個合格的CloudNative應用：程序當開源軟件編寫，應用配置外置
整個端到端CloudNative產品落地，計劃分為六個階段展開：
Cloud Native Phase 1 - 云上微服務開發端到端
Cloud Native Phase 2 - 云上DevOps
Cloud Native Phase 3 - 云原生應用AutoConfig
Cloud Native Phase 4 – 如何實現云上彈性伸縮和熔斷限流
Cloud Native Phase 5 - 云上權限管理和網絡安全
Cloud Native Phase 6 – 如何申請外網域名和SSL證書
本文為第三章即Cloud Native Phase 3 - 云原生應用AutoConfig。
題記：
在前面一陣摸索以后，我們的應用已經可以在云上運行起來的，但還很原始，雖然用了spring.prifles.active來區分不同環境的配置，但還是和代碼在一起。
對于一個合格的CloudNative應用，應該把自己的程序當做開源軟件來編寫的，不該將數據庫連接信息和密碼放在代碼里，一定要將配置外置。
因此我試著在華為云上落地這套標準，期間嘗試了從ServiceStage、CCE、CSE這三個入口進行配置注入，最終實現能夠在應用啟動時，主動拉取配置，覆蓋本地配置文件里的調試配置，并能夠在線配置并生效。
打法是：CCE配置啟動參數，制定SpringProfiles；配合CSE做應用配置，將資源外置后的配置記錄于此，并可以動態更新，最終實現了配置外置的訴求。
另外，通過這次增加的多版本管理，嘗試梳理了一下ServiceStage的組件、CCE的workload、CSE的應用和微服務之間，錯綜復雜的概念之間的關系，個人淺見，歡迎指正：
1. 初始化配置
在系統初始化的時候，不可能一點配置都沒有，所以保留一些基礎配置在配置文件里是有必要的。配置外置并不意味著100%的配置都要外置，而是把外部依賴資源的配置，特別是容易變化配置外置。
在代碼層面，首先要進行基礎配置。先看代碼結構，這里除了最基本的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的微服務配置中心里，而不必在本地配置文件里存在，另外就是本地配置里存在的，也可以通過二次設置在微服務的配置中心里，進行覆蓋，比如數據庫連接池的大小，而不需要修改代碼，至于改完以后，要不要重啟，那就得看生效的邏輯了。
CSE配置中心引入，需要先引入依賴包，然后在bootstrap.yaml中配置CSE配置中心的地址、認證信息等。
這里可以參考官方文檔，主要關注bootstrap.yaml的配置參數：使用分布式配置中心
參考地址：huaweicloud/spring-cloud-huawei
可以參考現有的SpringCloud基線版本，選擇SpringCloud-Huawei的版本
微服務引擎提供了分層次的配置機制。按照優先級從高到低，分為：
配置中心（動態配置）
Java System Property（-D參數）
環境變量
配置文件
參考官方文檔：配置微服務
2. 本地CSE配置中心能力驗證
前提條件，本地得安裝一個Local-CSE并啟動，這部分參考云上DevOps：2.1-本地環境準備
原始文件可以參考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
關于如上參數的定義，參考官方文檔：使用分布式注冊中心和官方文檔：使用分布式配置中心。
直接上代碼
為了驗證CSE配置中心的參數，是否能覆蓋application.yaml中的參數配置，我選了一個很特別的參數：spring.datasource.password，如果能夠覆蓋成功，那么啟動后，創建數據庫連接池一定會報錯。
首先，打開本地CSE配置中心，地址為：http://localhost:30106/#/cse/services/config，創建一個配置項，作用域選VodMgrService@CabgOne#1.0.0，關于application的作用域后面再解釋。
重啟本地微服務，啟動后創建數據庫連接池就報錯了，符合預期。
結論：CSE配置中心的參數，能夠覆蓋application.yaml中的參數配置
為了驗證CSE配置中心的參數動態生效，需要使用注解@RefreshScope，同時也引入ConfigRefreshEvent來監聽事件變化，這樣就會得到一個效果，對于動態生效的參數，可能需要一些重建或刷新，比如連接池、緩存、Client等。
首先，增加一個配置項config.value
然后很快可以看到后臺日志打印出來，包括自己的-，也響應了日志
查看一下數據，已經響應為TryMe
具體的配置，在后臺是輪詢的，響應周期配置參數為cloud.servicecomb.config.watch.delay，目前是10秒一次
修改一下配置，為TryMeAgain
再看后臺日志，有新的觸發器發生
再次請求API，數據已經更新
再深入去看，這里的getChange()返回是一個Set
結論：本地CSE配置中心的參數能夠動態刷新，并開放了ConfigRefreshEvent，以擴展配置更新后的業務動作。
目前CSE的配置中心提供兩級作用域限制，一個是全域，一個是私域，即微服務內部（不同版本有區分）。
增加一個作用域為application的全域參數，一個作用域為VodMgrService@CabgOne#1.0.0的私域同名參數
驗證一下，生效的作用域是VodMgrService@CabgOne#1.0.0
刪除私域參數后，生效的作用域是application
結論：本地CSE配置中心的全域配置的優先級，低于微服務內部配置，即私域配置可以覆蓋全域配置。
3. 云上配合外置落地
代碼提交，推送到CodeHub上，流水線在CloudPipeline自動驅動起來，開始執行，打包、制作鏡像、推送SWR，并且展開了代碼質量檢查。這些得益于前面的WIKI：Phase2 - 云上DevOps
由于ServiceStage的自動部署能力還不滿足，所以手工將DockerImage升級到環境上，這里直接使用CCE進行操作，原因在題記里介紹了，ServiceStage的參數配置不太好用
選擇升級版本，點高級配置，CCE的核心配置入口都在這里了
在啟動時，注入最核心的一個參數-Dspring.profiles.active=uat
此處的命令是Docker啟動是的ENTRYPOINT，下面那個是CMD，會覆蓋Dockerfile里的命令
點擊右下角的提交，會看到實例列表中已經有一個新的pod在啟動
回到AOM服務，查看日志，會發現The following profiles are active: uat，符合預期
首先回退上面那一步的配置，進入高級設置->環境變量
增加環境變量JAVA_TOOL_OPTIONS，值設置為-Dspring.profiles.active=uat
提交以后查看日志，符合預期
至于為啥JAVA_TOOL_OPTIONS能用，因為JVM原生就包含這個參數，可以用來在啟動時寫入配置，可以參考Oracle的官方文檔
CCE的配置中心包含了兩個大類，配置項ConfigMap和秘鑰Secret，前面介紹的CCE環境變量，支持從配置中心導入參數，比如我可以在ConfigMap里寫入這個參數，然后在CCE的環境變量中引入。
首先創建一個配置項，這里的配置項是按照集群、命名空間區分的
然后創建一套配置項，輸入一套KV
回到CCE升級的步驟，修改環境變量，增加一項配置項寫入的變量，可以選到剛才輸入的KEY，就不用輸入VALUE了
然后再看看秘鑰，玩兒法類似，但是有一點很“有趣”：這里的秘鑰是要主動用BASE64轉碼過才能保存，不過在使用的時候，會解密的，因此不必關心轉碼回來的問題。
無論是配置項ConfigMap還是秘鑰Secret，都可以支持利用CCE的數據存儲掛載能力寫入參數到容器里，簡單理解，就是會自動幫你把配置下載到一個容器的存儲位置上，文件名是KEY，內容是VALUE，可以在代碼里讀取這個配置。
配置方式很簡單，選擇配置項，然后寫一個掛載目錄即可
這里是另一個核心，線下驗證過，云上的CSE類似，但是配置模型更復雜，增加了server.env維度，并且全域和私域參數配置位置不一樣。
首先，從ServiceStage->微服務CSE->配置管理，進入全域配置頁面，選擇環境為yaml里配置的server.env參數
返回結果為，生效
PS：如果這里不選環境，則參數無法讀取，即環境為空也是一類環境，不同環境之間隔離
然后，從ServiceStage->微服務CSE->微服務目錄，進入私域頁面
進而選擇動態配置，在配置作用域時，選擇不帶version的，環境是固定值，
返回結果為，生效
同樣的頁面下，在配置作用域時，選擇帶version的，
返回結果為，生效
P1：微服務私域，帶Version
P2：微服務私域，無Version
P3：全域，帶環境
其余參數都不生效，包括全域無環境、全域不同環境、微服務私域不同Version
總結
綜上，基于華為云ServiceStage、CCE、CSE的配置外置能力，可以支撐微服務在不同環境中靈活部署，而無需修改代碼。目前的總結打法是：
利用CCE的容器啟動參數，或環境變量，寫入profiles.active參數
利用CSE的配置中心，寫入業務參數，如MySQL連接串、連接池配置、GES引擎地址、VOD服務Endpoint地址等
云原生 容器 微服務
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
相關文章
