配置中心簡介

背景分析

我們知道，除了代碼之外，軟體還有一些配置資訊，比如資料庫的用戶名和密碼，還有一些我們不想寫死在代碼里的東西，例如像執行緒池大小、佇列長度等運行引數，以及日志級別、演算法策略等，還有一些是軟體運行環境的引數，如Java 的記憶體大小，應用啟動的引數，包括作業系統的一些引數配置…… 所有這些東西，我們都叫做軟體配置，以前，我們把軟體配置寫在一個組態檔中，就像 Windows 下的 ini 檔案，或是 Linux 下的 conf 檔案，然而，在分布式系統下，這樣的方式就變得非常不好管理，并容易出錯，假如生產環境下，專案現在正在運行，此時修改了組態檔，我們需要讓這些配置生效，通常的做法是不是要重啟服務，但重啟是不是會帶來系統服務短時間的暫停，從而影響用戶體驗呢，還有可能會帶來經濟上的很大損失（例如雙11重啟下服務），基于這樣的背景，配置中心誕生了，

配置中心概述

配置中心最基礎的功能就是存盤一個鍵值對，用戶發布一個配置（configKey），然后客戶端獲取這個配置項（configValue）；進階的功能就是當某個配置項發生變更時，不停機就可以動態重繪服務內部的配置項，例如，在生產環境上我們可能把我們的日志級別調整為 error 級別，但是，在系統出問題我們希望對它 debug 的時候，我們需要動態的調整系統的行為的能力，把日志級別調整為 debug 級別，還有，當你設計一個電商系統時，設計大促預案一定會考慮，同時涌進來超過一億人并發訪問的時候，假如系統是扛不住的，你會怎么辦，在這個程序中我們一般會采用限流，降級，系統的限流和降級本質上來講就是從日常的運行態切換到大促態的一個行為的動態調整，這個本身天然就是配置起到作用的一個相應的場景，

配置中心的選型

在面向分布式的微服務系統中，如何通過更高效的配置管理方式，實作微服務系統架構持續“無痛”的演進，并動態調整和控制系統的運行時態，配置中心的選型和設計起著舉足輕重的作用，市場上主流配置中心有Apollo(攜程開源)，nacos(阿里開源)，Spring Cloud Config(Spring Cloud 全家桶成員），我們在對這些配置中心進行選型時重點要從產品功能、使用體驗、實施程序和性能等方面進行綜合考量，本次課程我們選擇nacos，此組件不僅提供了注冊中心，還具備配置中心的功能，

小節面試分析

什么是配置中心？（存盤專案配置資訊的一個服務）
為什么要使用配置中心？(集中管理配置資訊，動態發布配置資訊)
市場上有哪些主流的配置中心？(Apollo,nacos,……)

Nacos配置快速入門

添加依賴

在已有的sca-provider專案中添加如配置依賴,例如:

  <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
  </dependency>

修改組態檔

將專案中的application.yml的名字修改為bootstrap.yml組態檔（啟動優先級最高），代碼如下：

spring:
  application:
    name: sca-provider
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
      config:
        server-addr: 127.0.0.1:8848
        group: DEFAULT_GROUP # Group, default is DEFAULT_GROUP
        file-extension: yml # Configure the data format of the content, default to properties

Nacos基本配置

打開nacos配置中心，新建配置，如圖所示：

在這里插入圖片描述

其中Data IDs的值要與bootstrap.yml中定義的spring.application.name的值相同(服務名-假如有多個服務一般會創建多個配置實體，不同服務對應不同的配置實體)，

Controller處理器操作

在ProviderController中添加一個獲取日志級別(debug<info<warn<error)的方法,代碼如下:

@RefreshScope //動態重繪配置
@RestController
public class ProviderController{
    private static final Logger log= LoggerFactory.getLogger(ProviderApplication.class);
    @Value("${logging.level.com.cy:error}")
    private String logLevel;
    @GetMapping("/provider/doGetLogLevel")
    public String doGetLogLevel(){
       log.trace("==log.trace==");//跟蹤
       log.debug("==log.debug==");//除錯
       log.info("==log.info==");//常規資訊
       log.warn("==log.warn==");//警告
       log.error("==log.error==");//錯誤資訊
        return "log level is "+logLevel;
    }
    ……
}

其中,@RefreshScope的作用是在配置中心的相關配置發生變化以后，能夠及時看到更新(底層是通過重新創建Controller物件的方式,對屬性進行了重新初始化),Controller撰寫好以后，啟動配置中心服務，然后進行訪問測驗，，打開瀏覽器直接在地址欄輸入http://localhost:8081/provider/doGetLogLevel，檢測輸出結果是否為我們配置中配置的資訊，如圖所示，

在這里插入圖片描述

說明,假如對配置的資訊訪問不到,請檢測專案組態檔的名字是否為bootstrap.yml,檢查組態檔中spring.application.name屬性的值是否與配置中心的data-id名相同,還有你讀取的配置資訊縮進以及空格寫的格式是否正確.

Nacos配置動態更新實作

修改Nacos的日志級別配置并重新重新發布，如圖所示：
在這里插入圖片描述

重繪瀏覽器url，檢測其配置輸出，

在這里插入圖片描述

小節面試分析

配置中心一般都會配置什么內容？(可能會經常變化的配置資訊，例如連接池，日志、執行緒池、限流熔斷規則)
什么資訊一般不會寫到配置中心?(服務埠，服務名，服務的注冊地址，配置中心)
專案中為什么要定義bootstrap.yml檔案？(此檔案被讀取的優先級比較高，可以在服務啟動時讀取配置中心的資料)
Nacos配置中心宕機了，我們的服務還可以讀取到配置資訊嗎？(可以從記憶體,客戶端獲取了配置中心的配置資訊以后,會將配置資訊在本地記憶體中存盤一份.)
微服務應用中我們的客戶端如何獲取配置中心的資訊?(為了考慮性能我們的服務一般首先會從記憶體讀取配置資訊，同時我們的微服務還可以定時向nacos配置中心發請求拉取(pull)更新的配置資訊，但是在一定時間間隔內還可能會出現不一致的配置，所以nacos服務端而言，當配置變化時,會通知客戶端然后更新客戶端.)
微服務應用中客戶端如何感知配置中心資料變化？(當資料發生變化時,nacos找到它維護的客戶端，然后通知客戶端去獲取更新的資料，客戶端獲取資料以后更新本地記憶體,并在下次訪問資源時,重繪@Value注解描述的屬性值，但是需要借助@RefreshScope注解對屬性所在的類進行描述)
服務啟動后沒有從配置中心獲取我們的配置資料是什么原因?(依賴,組態檔名字bootstrap.yml,配置中心的dataId名字是否正確,分組是否正確,配置的名字是否正確,縮進關系是否正確,假如是動態發布,類上是否有@RefreshScope注解)
你專案中使用的日志規范是什么?(SLF4J)
你了解專案中的日志級別嗎?(debug,info,error,…,可以基于日志級別控制日志的輸出)

Nacos配置管理模型

概述

Nacos 配置管理模型由三部分構成，如圖所示：
在這里插入圖片描述
其中：

Namespace：命名空間，對不同的環境進?隔離，?如隔離開發環境和?產環境，
Group：分組，將若?個服務或者若?個配置集歸為?組，
Service/DataId：某?個服務或配置集，一般對應一個組態檔，

命名空間設計

Nacos中的命名空間一般用于配置隔離，這種命名空間的定義一般會按斬訓境（開發，生產等環境）進行設計和實作.我們默認創建的配置都存盤到了public命名空間，如圖所示：
在這里插入圖片描述

創建新的開發環境并定義其配置，然后從開發環境的配置中讀取配置資訊，該如何實作呢？

第一步：創建新命名空間，如圖所示：
在這里插入圖片描述

命名空間成功創建以后，會在如下串列進行呈現，
在這里插入圖片描述

在指定命名空間下添加配置，也可以直接取配置串列中克隆，例如：
在這里插入圖片描述

克隆成功以后，我們會發現在指定的命名空間中有了我們克隆的配置，如圖所示：

此時我們修改dev命名空間中Data Id的sca-provider配置，如圖所示：
在這里插入圖片描述
修改專案module中的組態檔bootstrap.yml,添加如下配置，關鍵代碼如下：

spring:
  cloud:
    nacos:
      config:
        namespace: 6058fd3f-0d4d-44f2-85d6-5fc7d2348046
        ……

其中，namespace后面的字串為命名空間的id，可直接從命名空間串列中進行拷貝.
重啟服務，繼續重繪http://localhost:8081/config/doGetLogLevel地址，檢測輸出，看看輸出的內容是什么，是否為dev命名空間下配置的內容，如圖所示：

在這里插入圖片描述
我們還可以創建生產環境，依次類推進行設計和實作即可，

分組設計及實作

當我們在指定命名空間下，按環境或服務做好了配置以后，有時還需要基于服務做分組配置，例如，一個服務在不同時間節點(節假日，活動等)切換不同的配置，可以在新建配置時指定分組名稱，如圖所示：
在這里插入圖片描述

配置發布以后，修改boostrap.yml配置類，在其內部指定我們剛剛創建的分組，代碼如下：

server:
  port: 8070
spring:
  application:
    name: nacos-config
  cloud:
    nacos:
      config:
        server-addr: 127.0.0.1:8848
        group: DEV_GROUP_51 # Group, default is DEFAULT_GROUP
        file-extension: yml # Configure the data format of the content, default to properties
        namespace: 5c27fe4a-1141-4836-a14e-cbac77fb2130

在NacosConfigController類中添加屬性和方法用于獲取和輸出DEV_GROUP_51配置中設定的執行緒數，代碼如下：

@Value("${server.tomcat.threads.max:200}")
private Integer maxThread;

@RequestMapping("/provider/doGetMaxThread")
public String doGetMaxThread(){
    return "server.threads.max is  "+maxThread;
}

然后重啟服務，進行測驗，檢測內容輸出，如圖所示:
在這里插入圖片描述

共享配置設計及讀取

當同一個namespace的多個組態檔中都有相同配置時，可以對這些配置進行提取，然后存盤到nacos配置中心的一個或多個指定組態檔，哪個微服務需要，就在服務的配置中設定讀取即可，例如：

第一步：在nacos中創建一個共享組態檔，例如：

在這里插入圖片描述

第二步：在指定的微服務組態檔(bootstrap.yml)中設定對共享組態檔的讀取，例如：
見紅色區域內容，

spring:
  application:
    name: nacos-config
  cloud:
    nacos:
      config:
        server-addr: localhost:8848
        # 命名空間
        namespace: 83ed55a5-1dd9-4b84-a5fe-a734e4a6ec6d
        # 分組名
        # group: DEFAULT_GROUP
        # 配置中心檔案擴展名
        file-extension: yml
        # 共享配置
        shared-configs[0]:
                data-id: app-public-dev.yml
                group: DEFAULT_GROUP
                refresh: true #默認false

第三步：在指定的業務類中讀取和應用共享配置即可，例如：

@Value("${page.pageSize:10}")
private Integer pageSize;
@GetMapping("/provider/doGetPageSize")
public String doGetPageSize(){
    //return String.format()
    return "page size is "+pageSize;
}

第四步：啟動服務進行訪問測驗，
在這里插入圖片描述

小節面試分析

Nacos配置管理模型的背景？(環境不同配置不同)
Nacos配置中的管理模型是怎樣的？（namespace,group,service/data-id）
Nacos客戶端(微服務)是否可以讀取共享配置?(可以)

總結(Summary)

重難點分析

配置中心的選型，(市場活躍度、穩定性、性能、易用)
Nacos配置中心基本應用，(新建，修改、洗掉配置以后，在Nacos客戶端應用配置)
配置管理模型應用，(namespace,group,service/dataId)
Nacos配置變更的動態感知，(底層原理分析)

FAQ分析

為什么需要配置中心？(動態管理發布配置，無需重啟服務，更好保證服務的可用)
配置中一般要配置什么內容？(經常變化的配置資料-日志級別，執行緒池、連接池、…)
市面上有哪些主流配置中心？(Nacos,….)
配置中心選型時要重點考慮哪些因素？(市場活躍度、穩定性、性能、易用)
Nacos客戶端(微服務業務)如何動態感知配置中心資料變化的？(nacos2.0之前nacos客戶端采用長輪詢機制拉取nacos服務的配置資訊，pull（每隔30秒）+“push(是在服務端的配置資訊變更以后，通知服務端中處于等待狀態的客戶端佇列中的客戶端物件，并更新客戶端對應的回應資料，然后回傳回應)”)
Nacos配置管理模型是怎樣的？（命名空間-namespace,分組-group,服務實體-dataId）

Bug分析

? ，，，，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/291089.html

標籤：其他

上一篇：聊聊百度搜索背后的故事

下一篇：我給鴻星爾克寫了一個720°看鞋展廳

08-服務配置中心Nacos應用實踐

配置中心簡介

背景分析

配置中心概述

配置中心的選型

小節面試分析

Nacos配置快速入門

添加依賴

修改組態檔

Nacos基本配置

Controller處理器操作

Nacos配置動態更新實作

小節面試分析

Nacos配置管理模型

概述

命名空間設計

分組設計及實作

共享配置設計及讀取

小節面試分析

總結(Summary)

重難點分析

FAQ分析

Bug分析