你應該知道的 Nacos 接入和避坑指南

良許 本文轉載自微信公衆號「Java極客技術」，做者鴨血粉絲 。轉載本文請聯繫Java極客技術公衆號。

Hello 你們好，我是阿粉，今天給你們分享微服務環境下必需要使用的一個強大的組件 Nacos。自從使用了 Nacos，阿粉的服務再也沒有擔憂過服務註冊和發現以及配置管理混亂的問題了。

背景

Nacos 致力於幫助開發人員發現、配置和管理微服務，Nacos 提供了一組簡單易用的特性集，快速實現動態服務發現、服務配置、服務元數據及流量管理。

目前主流的互聯網服務都是基於微服務架構的，那服務與服務之間的交互是必不可少的，並且各個服務的上下線都是相互獨立的，並且服務的配置信息也是會動態調整的，這就須要咱們的服務更加靈活。Nacos 的出現就是幫助咱們實現這些繁瑣的功能。

詳細的 Nacos 介紹和部署能夠參考官方網站 Nacos.io。這裏只介紹一下在 SpringBoot 項目中如何快速接入以及接入和使用過程當中可能會遇到的坑。

接入

加入依賴

第一步在 pom 配置文件中加入下面的依賴，用於實現服務註冊發現和配置中心功能。

<!-- nacos 配置中心 --> 
<dependency> 
  <groupId>com.alibaba.cloud</groupId> 
  <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> 
</dependency> 
<!-- nacos 註冊發現 --> 
<dependency> 
  <groupId>com.alibaba.cloud</groupId> 
  <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> 
</dependency>

增長配置

1.第二步在 SpringBoot 項目的啓動類上增長以下註解 @EnableDiscoveryClient 用於啓動服務註冊發現功能。

2.增長配置文件，對應的配置信息須要修改爲適合本身的，爲了方便管理，應用的分組名稱，命名空間以及相關的配置都須要合理的設置。多個業務使用同一個 nacos 集羣的時候，須要根據各個的業務設定各自的命名空間。全部的配置文件都須要在對應的命名空間下設置，避免多個業務混用，另外業務須要根據用到的組件或者配置，設定獨立的配置文件，例如數據庫的配置，Redis 的配置等都須要單獨設定，這樣是爲了同一個應用其餘的其餘服務也可使用，並且再有地址變動的時候能夠只修改一個文件就好，不會忘記。

# 應用服務名稱 
spring.application.name=application-name 
# 應用分組名稱 
spring.cloud.nacos.config.group=GROUP-NAME 
# 配置文件的後綴名 
spring.cloud.nacos.config.file-extension=properties 
# nacos 對應的命名空間，在後臺建立好命名空間後會自動生成 
spring.cloud.nacos.config.namespace=xxxxxxxxxxxxxxxxxxxxxxxxx 
# 對應的配置文件 
# MySQL 相關配置 
spring.cloud.nacos.config.ext-config[0].data-id=mysql.properties 
spring.cloud.nacos.config.ext-config[0].group=GROUP-NAME 
# Redis 相關配置 
spring.cloud.nacos.config.ext-config[1].data-id=redis.properties 
spring.cloud.nacos.config.ext-config[1].group=GROUP-NAME 
# 其餘配置等 
spring.cloud.nacos.config.ext-config[2].data-id=other.properties 
spring.cloud.nacos.config.ext-config[2].group=GROUP-NAME 
# 配置中心地址，多個逗號分隔 
spring.cloud.nacos.config.server-addr=xxx.xx.xx.xx:xxxx 
# 服務註冊發現地址，多個逗號分隔 
spring.cloud.nacos.discovery.server-addr=xxx.xx.xx.xx:xxxx 
# 集羣名稱 
spring.cloud.nacos.discovery.cluster-name=CLUSTER-NAME

3.代碼中可使用註解 @Value() 來直接讀取 Nacos 配置中的屬性參數，也可使用 @ConfigurationProperties(prefix = "spring.datasource") 讀取批量參數。

4.spring.cloud.nacos.config.ext-config[0].refresh=true 該參數表示是否開啓自動更新，根據是否須要自動更新以爲是否配置，若是須要自動更新，加上這個配置後還須要在須要自動更新配置的 Bean 上面增長@RefreshScop 註解。而後對應的 Bean 內部的屬性就能夠實現自動更新了。增長了spring.cloud.nacos.config.ext-config[0].refresh=true 配置後在修改了 Nacos 中的配置事後日誌會出現下面信息，會從新加載配置，而且輸出變動的 key 信息。

5.

服務調用

當全部的服務都接入 Nacos 事後，咱們在 Nacos 的後臺就能夠看到每一個服務的狀況，以下圖，能夠看到服務狀態。

而後咱們在服務 A 裏面若是要調用服務 B 的時候，就能夠直接在 FeginClient 中配置服務 B 的名稱，不須要填寫 URL 了。這樣咱們就不用考慮服務 B 是否地址和端口會不會變。服務 B 的實例增長仍是減小，端口是否變了，對服務 A 來講都不關心，只要有個服務名稱就能夠了。

避坑

命名空間

Nacos 有一個默認的名爲 public 的命名空間，這個命名空間是沒法刪除的，全部未指定命名空間的配置都會放在該命名空間下;一樣的 Nacos 有一個默認的名爲 DEFAULT_GROUP 的分組，在沒有指定分組名稱的時候默認的配置都是在該分組下。

對於咱們應用程序來講，因爲不少狀況下一個 Nacos 集羣是多個團隊共同使用的，因此爲了方便管理，咱們須要根據本身的業務設置本身的命名空間，用於存放本業務的配置文件。本命名空間下的配置文件，根據各個的模塊決定是否須要從新分組。

要知道在沒有清晰的命名空間劃分的時候，要想修改一個配置的內容，是很難受的一件事情。線上的配置調整，一個不當心就是事故。若是仍是自動更新配置的話，那連後悔的機會都沒有。

精細配置

配置文件應該專注，一個配置文件就設置一個內容，好比 MySQL 的數據源單獨一個配置，Redis 的數據源單獨一個配置，若是多個 Redis 服務，根據功能建議分開配置，由於並非全部的服務都須要每一個 Redis 的連接配置。各自的服務根據須要單獨引用對應的配置文件便可。

將全部的配置獨立成一個配置文件方便後續修改配置，只要修改一個配置文件就好，不用擔憂其餘還有未修改的地方。

合理的規劃配置文件的內容，每每不少時候能夠事半功倍，極大的節約時間和減小出錯的機率。

自動刷新

前面介紹瞭如何設置配置自動刷新，不過服務是否須要自動更新配置，這個根據自身的業務去決定。

我這裏通常不建議設置自動更新，由於如今都是微服務部署，有時候咱們上線一個新功能的時候都是灰度發佈，若是配置自動更新，再調整配置事後，所有實例都會生效，這樣會有風險。不設置自動更新的話，咱們能夠單獨重啓個別實例，觀察線上狀況，等穩定了再發布全部服務，這樣會安全不少。

固然對於沒有那麼多服務，不須要灰度，影響不大的場景下，配置自動更新會方便不少，再修改配置後不須要重啓服務。

總結

Nacos 做爲服務的註冊發現和配置的統一管理確實十分出色，除了能快速接入 SpringBoot 項目以外，其餘的框架都能快速的接入，更多使用能夠參考官網。

最後但願你們都能解放雙手快速接入玩起來!

寫在最後

最後邀請你加入咱們的知識星球，這裏有 1800+ 優秀的人與你一塊兒進步，若是你是小白那你是穩賺了，不少業內經驗和乾貨分享給你;若是你是大佬，那能夠進來咱們一塊兒交流分享你的經驗，說不定往後咱們還能夠有合做，給你的人生多一個可能。

【編輯推薦】

1. 爲何選用Nacos？虎牙直播微服務改造實踐
2. ZooKeeper、Eureka、Consul 、Nacos微服務註冊中心對比
3. 微服務，Java目前很火熱的系統架構
4. 用容器與微服務安全來加持DevSecOps
5. 十年架構師耗盡心血帶你如何進行微服務的單元、集成和系統測試？

【責任編輯：武曉燕 TEL：（010）68476606】