Spring Cloud Alibaba基礎教程：Nacos配置的多環境管理

時間 2019-11-06

標籤 spring cloud alibaba 基礎教程 nacos 配置環境管理欄目 Spring 简体版

原文原文鏈接

前情回顧：html

經過以前兩篇對Nacos配置管理功能的介紹，已經學會了在Nacos中如何加入配置以及Spring Cloud應用如何經過配置來加載到對應的內容。接下來，咱們討論一個在使用配置中心時，都須要關注的一個問題：多環境的配置如何實現與管理？git

多環境管理

在Nacos中，自己有多個不一樣管理級別的概念，包括：Data ID、Group、Namespace。只要利用好這些層級概念的關係，就能夠根據本身的須要來實現多環境的管理。github

下面，我就來介紹一下，可使用的幾種實現方式：spring

使用`Data ID`與`profiles`實現

Data ID在Nacos中，咱們能夠理解爲就是一個Spring Cloud應用的配置文件名。經過上一篇《Spring Cloud Alibaba基礎教程：Nacos配置的加載規則詳解》，咱們知道默認狀況下Data ID的名稱格式是這樣的：${spring.application.name}.properties，即：以Spring Cloud應用命名的properties文件。bootstrap

實際上，Data ID的規則中，還包含了環境邏輯，這一點與Spring Cloud Config的設計相似。咱們在應用啓動時，能夠經過spring.profiles.active來指定具體的環境名稱，此時客戶端就會把要獲取配置的Data ID組織爲：${spring.application.name}-${spring.profiles.active}.properties。bash

實際上，更原始且最通用的匹配規則，是這樣的：${spring.cloud.nacos.config.prefix}-${spring.profile.active}.${spring.cloud.nacos.config.file-extension}。而上面的結果是由於${spring.cloud.nacos.config.prefix}和${spring.cloud.nacos.config.file-extension}都使用了默認值。架構

動手試一試app

咱們能夠用《Spring Cloud Alibaba基礎教程：使用Nacos做爲配置中心》一文中的列子（可在文末倉庫中獲取）爲基礎，體驗一下這種區分環境的配置方式。運維

第一步：先在Nacos中，根據這個規則，建立兩個不一樣環境的配置內容。好比：測試

如上圖，咱們爲alibaba-nacos-config-client應用，定義了DEV和TEST的兩個獨立的環境配置。咱們能夠在裏面定義不一樣的內容值，以便後續驗證是否真實加載到了正確的配置。

第二步：在alibaba-nacos-config-client應用的配置文件中，增長環境配置：spring.profiles.active=DEV

第三步：啓動應用，咱們能夠看到日誌中打印了，加載的配置文件：

2019-01-30 15:25:18.216  INFO 96958 --- [           main] o.s.c.a.n.c.NacosPropertySourceBuilder   : Loading nacos data, dataId: 'alibaba-nacos-config-client-DEV.properties', group: 'DEFAULT_GROUP'

使用`Group`實現

Group在Nacos中是用來對Data ID作集合管理的重要概念。因此，若是咱們把一個環境的配置視爲一個集合，那麼也就能夠實現不一樣環境的配置管理。對於Group的用法並無固定的規定，因此咱們在實際使用的時候，須要根據咱們的具體需求，能夠是架構運維上對多環境的管理，也能夠是業務上對不一樣模塊的參數管理。爲了不衝突，咱們須要在架構設計之初，作好必定的規劃。這裏，咱們先來講說如何用Group來實現多環境配置管理的具體實現方式。

動手試一試

第一步：先在Nacos中，經過區分Group來建立兩個不一樣環境的配置內容。好比：

如上圖，咱們爲alibaba-nacos-config-client應用，定義了DEV環境和TEST環境的兩個獨立的配置，這兩個匹配與上一種方法不一樣，它們的Data ID是徹底相同的，只是GROUP不一樣。

第二步：在alibaba-nacos-config-client應用的配置文件中，增長Group的指定配置：spring.cloud.nacos.config.group=DEV_GROUP

第三步：啓動應用，咱們能夠看到日誌中打印了，加載的配置文件：

2019-01-30 15:55:23.718  INFO 3216 --- [main] o.s.c.a.n.c.NacosPropertySourceBuilder   : Loading nacos data, dataId: 'alibaba-nacos-config-client.properties', group: 'DEV_GROUP'

使用`Namespace`實現

Namespace在本系列教程中，應該仍是第一次出現。先來看看官方的概念說明：用於進行租戶粒度的配置隔離。不一樣的命名空間下，能夠存在相同的Group或Data ID的配置。Namespace的經常使用場景之一是不一樣環境的配置的區分隔離，例如：開發測試環境和生產環境的資源（如配置、服務）隔離等。

在官方的介紹中，就介紹了利用其能夠做爲環境的隔離使用，下面咱們就來試一下吧！

動手試一試

第一步：先在Nacos中，根據環境名稱來建立多個Namespace。好比：

第二步：在配置列表的最上方，能夠看到除了Public以外，多了幾個剛纔建立的Namepsace。分別在DEV和TEST空間下爲alibaba-nacos-config-client應用建立配置內容：

第三步：在alibaba-nacos-config-client應用的配置文件中，增長Namespace的指定配置，好比：spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a。

這裏須要注意namespace的配置不是使用名稱，而是使用Namespace的ID。

第四步：啓動應用，經過訪問localhost:8001/test接口，驗證一下返回內容是否正確。這種方式下，目前版本的日誌並不會輸出與Namespace相關的信息，因此還沒法以此做爲加載內容的判斷依據。

深刻思考

上面咱們分別利用Nacos配置管理功能中的幾個不一樣緯度來實現多環境的配置管理。從結果上而言，不論用哪種方式，都可以勝任需求，可是哪種最好呢？

第一種：經過Data ID與profile實現。

優勢：這種方式與Spring Cloud Config的實現很是像，用過Spring Cloud Config的用戶，能夠毫無違和感的過渡過來，因爲命名規則相似，因此要從Spring Cloud Config中作遷移也很是簡單。
缺點：這種方式在項目與環境多的時候，配置內容就會顯得很是混亂。配置列表中會看到各類不一樣應用，不一樣環境的配置交織在一塊兒，很是不利於管理。
建議：項目很少時使用，或者能夠結合Group對項目根據業務或者組織架構作一些拆分規劃。

第二種：經過Group實現。

優勢：經過Group按環境講各個應用的配置隔離開。能夠很是方便的利用Data ID和Group的搜索功能，分別從應用緯度和環境緯度來查看配置。
缺點：因爲會佔用Group緯度，因此須要對Group的使用作好規劃，畢竟與業務上的一些配置分組起衝突等問題。
建議：這種方式雖然結構上比上一種更好一些，可是依然可能會有一些混亂，主要是在Group的管理上要作好規劃和控制。

第三種：經過Namespace實現。

優勢：官方建議的方式，經過Namespace來區分不一樣的環境，釋放了Group的自由度，這樣可讓Group的使用專一於作業務層面的分組管理。同時，Nacos控制頁面上對於Namespace也作了分組展現，不須要搜索，就能夠隔離開不一樣的環境配置，很是易用。
缺點：沒有啥缺點，可能就是多引入一個概念，須要用戶去理解吧。
建議：直接用這種方式長遠上來講會比較省心。雖然可能對小團隊而言，項目很少，第一第二方式也夠了，可是萬一後面作大了呢？

注意：不論用哪種方式實現。對於指定環境的配置（spring.profiles.active=DEV、spring.cloud.nacos.config.group=DEV_GROUP、spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a），都不要配置在應用的bootstrap.properties中。而是在發佈腳本的啓動命令中，用-Dspring.profiles.active=DEV的方式來動態指定，會更加靈活！。