Nacos神秘面紗揭曉:微服務時代的配置之王
一、前言
隨著微服務架構的興起,服務的規模不斷增長,對于服務的發現、配置和管理變得越來越復雜。
在這個背景下,Nacos應運而生,以其強大的功能和靈活性成為云原生領域的瑞士軍刀之一。
「Nacos是一個由阿里巴巴開源的項目,它提供了服務注冊與發現、動態配置管理、服務和配置的實時監聽等功能,使得開發者可以更加輕松地構建和管理微服務架構。」
在Euerka不維護的時候,Nacos站出來挑扛起了大旗。不得不說是真的好用,完美適配SpringCloud,使得微服務更加完善!
當然免費版可能會有些問題,聽說企業收費的是難以想象的好用!有得賺就不會停止維護,就會越來越好,我們一起期待,它給我們帶來更好的功能!
「文章比較長,還請耐心看完,先收藏慢慢看,后面有源碼部門!」
話不多說,我們一起來深入了解一下吧!
二、Nacos發展史
「2018年3月:首次開源」
在2018年3月,Nacos首次以開源的形式亮相。作為一個全功能的服務發現和配置管理平臺,Nacos的目標是幫助開發者構建和管理微服務架構。
「2018年8月:成為Apache孵化項目」
由于其強大的功能和快速的社區發展,Nacos于2018年8月進入了Apache軟件基金會的孵化階段,成為Apache的孵化項目。
「2019年3月:成為Apache頂級項目」
在經過孵化期的發展和審查后,Nacos于2019年3月正式成為Apache頂級項目。這意味著 Nacos 的社區達到了一定的規模和貢獻度,得到了廣泛認可。
「2019年4月:發布Nacos 1.0.0 GA」
同時支持 AP 和 CP 一致性,可以大規模地生產環境中使用,新版本不僅針對社區的需求和集群的穩定性相應地增加了一些新特性,而且還發布了服務發現模塊的性能測試報告,以及完整的 API 列表和架構設計文檔。「快速增長期!」
「2021年03月:發布Nacos 2.0」
對于服務注冊和發現使用 gRPC 框架,Nacos 2.0 注冊性能相、注銷實例性能比較 Nacos 1.x 總體提升至少 2 倍;Nacos 2.0 查詢性能相比較 Nacos 1.x 總體提升至少 3 倍,單機多線程甚至提升了 10 倍;「這一時期基本沒有對手!」
三、Nacos介紹和特性
1、介紹
Nacos 是 Dynamic Naming and Configuration Service的首字母簡稱,「一個更易于構建云原生應用的動態服務發現、配置管理和服務管理平臺。」
Nacos 致力于幫助您發現、配置和管理微服務。Nacos 提供了一組簡單易用的特性集,幫助您快速實現動態服務發現、服務配置、服務元數據及流量管理。
Nacos 幫助您更敏捷和容易地構建、交付和管理微服務平臺。Nacos 是構建以“服務”為中心的現代應用架構 (例如微服務范式、云原生范式) 的服務基礎設施。
我們看一下Nacos 生態圖:
2、核心特性
「動態配置服務」
動態配置服務讓您能夠以中心化、外部化和動態化的方式管理所有環境的配置。動態配置消除了配置變更時重新部署應用和服務的需要。配置中心化管理讓實現無狀態服務更簡單,也讓按需彈性擴展服務更容易。
把Yaml文件放到Nacos上統一管理和切換。
「服務發現及管理」
動態服務發現對以服務為中心的(例如微服務和云原生)應用架構方式非常關鍵。Nacos支持DNS-Based和RPC-Based(Dubbo、gRPC)模式的服務發現。Nacos也提供實時健康檢查,以防止將請求發往不健康的主機或服務實例。借助Nacos,您可以更容易地為您的服務實現斷路器。
2.0以后采用gRPC進行服務的注冊!
「動態DNS服務」
通過支持權重路由,動態DNS服務能讓您輕松實現中間層負載均衡、更靈活的路由策略、流量控制以及簡單數據中心內網的簡單DNS解析服務。動態DNS服務還能讓您更容易地實現以DNS協議為基礎的服務發現,以消除耦合到廠商私有服務發現API上的風險。
「服務及其元數據管理」
Nacos 能讓您從微服務平臺建設的視角管理數據中心的所有服務及元數據,包括管理服務的描述、生命周期、服務的靜態依賴分析、服務的健康狀態、服務的流量管理、路由及安全策略、服務的 SLA 以及最首要的 metrics 統計數據。
灰度發布的配置就是元數據的一些參數!
四、Nacos安裝與配置
1、下載
我們根據對照表來下載哈!由于我們使用的Springboot版本是3.0之前的,所以要引入SpringCloudAlibaba 2021.0.5版本的,這個版本的Nacos只能安裝2.2.0的。所以我們不能安裝最新版的Nacos2.2.3,當然你也可以試一下,看看是不是向下兼容。
對照表地址:https://github.com/alibaba/spring-cloud-alibaba/wiki/%E7%89%88%E6%9C%AC%E8%AF%B4%E6%98%8E#%E6%AF%95%E4%B8%9A%E7%89%88%E6%9C%AC%E4%BE%9D%E8%B5%96%E5%85%B3%E7%B3%BB%E6%8E%A8%E8%8D%90%E4%BD%BF%E7%94%A8。
經過對照表我們本次使用的就是:
- SpringCloud 2021.0.5
- SpringCloud Alibaba 2021.0.5.0
- SpringBoot 2.6.13
經過對照表我們本次下載客戶端版本為2.2.0。
下載慢的可以使用迅雷!本次以Windows為例,Linux可以下載上面的,想看源碼的也可以下載下面的源碼!
Nacos2.2.0下載:https://github.com/alibaba/nacos/releases/tag/2.2.0。
這是綠色軟件,不需要安裝,盡量放到沒有中文目錄下,防止不必要的麻煩!
2、啟動訪問
「啟動這里有個坑:」
對于Nacos2.0以上版本默認啟動是以集群的方式啟動,需要你指定成單機啟動,當然你可以使用集群哈,這里就不帶大家搭集群了!
對于1.X直接雙擊啟動即可!
找到bin目錄,我們在上方輸入cmd回車。
由于公司項目啟動著nacos,咱的nacos改了端口為:18848。
輸入啟動命令:
startup.cmd -m standalone
啟動成功,我們可以進行訪問了!
http://192.168.50.108:18848/nacos/index.html。
用戶名和密碼都是nacos。
啟動完美結束!
3、修改持久化
我們一般要把Nacos的配置信息進行持久化,默認是使用嵌入式數據庫Derby數據庫。
可以發現nacos的pom里引入了:
<dependency>
<groupId>org.apache.derby</groupId>
<artifactId>derby</artifactId>
<version>${derby.version}</version>
</dependency>
這個數據庫咱也不熟,為了方便查看和管理,通常會選擇一個外部的數據庫。
在nacos0.7版本之后增加了支持MySQL數據源能力。
官方比較推薦使用MySQL來進行持久化的!配置文件里已經給我們準備好了配置的東西,解開注釋修改成自己的MySQL地址就好了!
先到conf目錄下拿到SQL文件,然后再數據庫中執行一下就可以了!
這里以Navicat為例哈:
導入conf下的SQL文件:
導入成功:
我們開始修改Nacos的配置文件:application.properties。
解開注釋,配置自己的數據庫用戶和密碼就行了!
「一定要重啟一下Nacos!」
五、Nacos配置中心
1、概念
我們來講一下Nacos的核心——配置中心功能吧。
這個對標的是Spring Cloud Config,需要單獨引依賴!
「配置中心是分布式系統中一種用于集中管理和動態配置應用程序配置信息的服務。」
在微服務架構中,配置管理是一個重要的問題,因為不同的服務可能需要不同的配置,并且這些配置可能會隨時發生變化。配置中心的目標是使配置更加集中、易管理。
2、核心
命名空間(Namespace)
命名空間是 Nacos 中的一個重要概念,它用于隔離不同環境或應用的配置信息。通過使用命名空間,可以在同一個 Nacos 集群中管理多個環境(如開發、測試、生產)的配置信息,從而實現配置的多租戶管理。
配置集(Data ID)
配置集是 Nacos 中用于存儲配置信息的基本單元。每個配置集都有一個唯一的標識符,稱為 Data ID。Data ID 通常由配置的業務模塊和應用名組成,用于唯一標識一個配置集。「(對標我們一個個的微服務)」
分組(Group)
分組是配置集的另一個維度,用于將不同用途或維度的配置集歸類到同一個組中。通過分組,可以更好地組織和管理配置信息。
3、優點
動態更新:配置信息放到yml文件中,防止硬編碼在程序里,動態更新配置(無需重啟)。多環境配置:不同的配置創建版本,并在需要時切換配置版本。這有助于在不同環境(例如開發、測試、生產)之間輕松管理配置。集中管理:配置中心允許開發者將應用程序的配置信息集中存儲在一個地方,而不是分散存儲在各個微服務中。這樣可以更方便地管理和維護配置。可視化管理:一些配置中心提供了可視化的配置管理界面,方便用戶直觀地查看和管理配置信息。歷史配置查看:一些配置中心提供了歷史配置查看功能,可以方便用戶查看歷史版本的配置信息,對于問題追溯和回滾配置是有幫助的。
配置的監聽和推送。
4、bootstrap.yml
在使用之前需要了解一下bootstrap.yml(properties )。
「bootstrap 是 Spring Boot 中一個特殊的配置文件,用于在應用程序啟動時配置一些系統級別的屬性,通常用于一些在應用程序上下文創建之前就需要加載的配置。」
我們把配置文件放到Nacos上,你把Nacos的地址再放在application.yml中,會加載不到,從而拿不到Nacos中的配置文件,項目無法啟動。所以需要把項目中的application.yml命名為:bootstrap.yml。
讓程序先去加載bootstrap.yml,拿到Nacos信息,再從Nacos里拿到配置信息,然后就可以加載了,連接數據庫等等!
六、Nacos服務注冊和發現
1、服務的注冊
我們在項目中使用Nacos后,就會在啟動項目成功后,在控制臺輸出:
2023-11-16 14:02:08.490 INFO 24660 ---
[ main] c.a.c.n.registry.NacosServiceRegistry :
nacos registry, DEFAULT_GROUP service-message 192.168.50.108:2002 register finished
代表我們的服務注冊到Nacos上了!
我們發現日志打印的類是NacosServiceRegistry,所以說這個類就是注冊核心類!
我們一起看看這個類到底發生了什么!
我們打斷點開看一下是誰調用的這個方法:
「這是SpringBoot思想約定大于配置,在NacosServiceRegistryAutoConfiguration配置生效后,當Spring容器初始化完成后,會發送 WebServerInitializedEvent 事件!」
「我們從調用鏈中發現:AbstractAutoServiceRegistration通過實現ApplicationListener<WebServerInitializedEvent> 來實現程序的監聽,從而執行到register方法!」
AbstractAutoServiceRegistration UML圖。
我們繼續看這個注冊方法,直接找到核心方法:namingService.registerInstance(serviceId, group, instance);一直點,直到出現三個實現方法,讓自己選擇。
至于源碼中怎么選擇的,我們一起看一下:
三個實現會先執行NamingClientProxyDelegate來獲取具體使用那種方式,類里的方法:
private boolean ephemeral = true;
private NamingClientProxy getExecuteClientProxy(Instance instance) {
return instance.isEphemeral() ? grpcClientProxy : httpClientProxy;
}
此時在Nacos2.0之前默認注冊是采用Http來發送的,2.0之后采用了效率更高的gRPC進行發送的!
此時我們來到gRpc的代理類中:
我們進去就可以看到gRpc的調用,具體內部就帶大家看了,關于gRpc的事情,大家可以搜一下,是Google開發的!
此時我們已經完成一半了,請求發送成功了,我們開始移步Nacos源碼了,需要的自行下載哈!
Nacos源碼下載地址:https://github.com/alibaba/nacos/tree/2.2.0。
此時需要找到官網的服務注冊地址,也就是剛剛我們發送gRpc的地址:
curl -X POST 'http://127.0.0.1:8848/nacos/v1/ns/instance?serviceName=nacos.naming.serviceName&ip=20.18.7.10&port=8080'
找到源碼從這里為入口往下走,這里就不帶大家跟了,NamingApp起不來,找了很多,沒有說的,大家可以試一下,跑個測試就行了。
不能Debug,小編這里只能跟到這里,給大家提供一個思路:
getInstanceOperator().registerInstance(namespaceId, serviceName, instance);
com.alibaba.nacos.naming.core.InstanceOperatorClientImpl#registerInstance中:
clientOperationService.registerInstance(service, instance, clientId);
來到這個實現類:
com.alibaba.nacos.naming.core.v2.service.impl.EphemeralClientOperationServiceImpl#registerInstance
NotifyCenter.publishEvent(new ClientOperationEvent.ClientRegisterServiceEvent(singleton, clientId));
點擊:
ClientRegisterServiceEvent,
來到類:
com.alibaba.nacos.naming.core.v2.event.client.ClientOperationEvent.ClientRegisterServiceEvent
查看有哪些引用,找到這個類,他來監聽然后繼續執行:
com.alibaba.nacos.naming.core.v2.index.ClientServiceIndexesManager#onEvent
這個類里:
handleClientOperation((ClientOperationEvent) event);
addPublisherIndexes(service, clientId);
NotifyCenter.publishEvent(new ServiceEvent.ServiceChangedEvent(service, true))
這里繼續發布另一個事件,點擊ServiceChangedEvent
來到這個類:
com.alibaba.nacos.naming.core.v2.event.service.ServiceEvent.ServiceChangedEvent
查看引用,來到這個類方法:
com.alibaba.nacos.naming.push.v2.NamingSubscriberServiceV2Impl#onEvent
里面會整上一個延時隊列:
delayTaskEngine.addTask(service, new PushDelayTask(service, PushConfig.getInstance().getPushTaskDelay()));
delayTaskEngine是我們后面的方向:PushDelayTaskExecuteEngine
先去構造方法看,發現先調用的父類,就先去看父類:
NacosDelayTaskExecuteEngine
先要看構造方法:
public NacosDelayTaskExecuteEngine(String name, int initCapacity, Logger logger, long processInterval) {
super(logger);
// 初始化待處理任務
tasks = new ConcurrentHashMap<>(initCapacity);
// 一個單線程的處理任務線程池
processingExecutor = ExecutorFactory.newSingleScheduledExecutorService(new NameThreadFactory(name));
// 開啟線程池,放里面添加上面說的task
processingExecutor
.scheduleWithFixedDelay(new ProcessRunnable(), processInterval, processInterval, TimeUnit.MILLISECONDS);
}
會執行:com.alibaba.nacos.common.task.engine.NacosDelayTaskExecuteEngine#processTasks。
「這一段主要是:通過定義一個延時執行的線程池定時去掃描task緩存,執行任務。」
可以看看PushDelayTaskExecuteEngine的UML圖:
從新回到PushDelayTaskExecuteEngine的構造方法:
setDefaultTaskProcessor(new PushDelayTaskProcessor(this));
點擊:
PushDelayTaskProcessor
來到這個類:
com.alibaba.nacos.naming.push.v2.task.PushDelayTaskExecuteEngine.PushDelayTaskProcessor
來到執行的process方法:
NamingExecuteTaskDispatcher.getInstance() .dispatchAndExecuteTask(service, new PushExecuteTask(service, executeEngine, pushDelayTask));
點擊:
dispatchAndExecuteTask
看到放里面添加任務:
executeEngine.addTask(dispatchTag, task);
來到這個類:
NacosExecuteTaskExecuteEngine
構造方法往里看:
在給TaskExecuteWorker[]添加元素,我們在看這個數組:
TaskExecuteWorker
然后繼續看構造方法:
realWorker = new InnerWorker(this.name);
然后realWorker.start(); 啟動:
會來到:
com.alibaba.nacos.common.task.engine.TaskExecuteWorker.InnerWorker#run
來執行任務:
task.run();
現在一臉懵了,一直在解耦,沒發打斷點,太難了,有大佬懂的NamingApp啟動的可以交流一下。
之前看過2.0之前的源碼,和這個完全不一樣,懵逼了。
不過思想應該沒變,注冊表本質還是一個Map。
看了之前的筆記是:
private final Map<String, Map<String, Service>> serviceMap = new ConcurrentHashMap<>();
不過現在可能變了,后面專門整一期文章看看源碼,有點跑偏了。還是以實戰為主,源碼我們后面單獨看哈!
「還有就是延遲單線程思想,你會發現Nacos的注冊是單線程的,都會放在阻塞隊列里一個個的去執行。大家不需要擔心這個效率會不會慢,一般用這個的就算有幾百個服務,一起注冊也是很快的,這種發布大家還是可以忍受的。成熟的程序后,不會一次注冊很多!」
2、服務發現
這里就先不寫了,上面一個注冊,花了好幾天時間。
我們先暫時跳過:
后面搞懂了,把注冊和發現的源碼單獨寫一篇。
有興趣的可以跟一下:
curl -X GET 'http://127.0.0.1:8848/nacos/v1/ns/instance/list?serviceName=nacos.naming.serviceName'
這個無疑也是從注冊表Map中那信息!
七、Nacos實戰
自己可以建一個聚合項目,然后體會一下,這里不就帶大家建了!
1、導入依賴
版本的對照,上面已經說了,大家可以去官網查看!
父模塊:
<spring.boot.version>2.6.13</spring.boot.version>
<spring.cloud.dependencies.version>2021.0.5</spring.cloud.dependencies.version>
<spring.cloud.alibaba.version>2021.0.5.0</spring.cloud.alibaba.version>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring.cloud.dependencies.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${spring.boot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-dependencies</artifactId>
<version>${spring.cloud.alibaba.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
子模塊:
「要有bootstrap的依賴」,默認2020以上版本把bootstrap禁用了,需要自己單獨引,不然會報錯!
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
<!-- bootstrap 啟動器 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>
結構如下:
2、配置文件
三份除了端口和服務名不一樣,其余都是相同的!
server:
port: 2000
spring:
application:
# 應用名稱
name: service-order
cloud:
nacos:
discovery:
# 服務注冊地址
server-addr: localhost:18848
config:
# 配置中心地址
server-addr: ${spring.cloud.nacos.discovery.server-addr}
username: nacos
password: nacos
3、測試服務注冊
啟動服務,我們看看能否注冊到Nacos上!
我們發現是沒有任何問題的,我們后面測試把配置信息放在Nacos上!
4、測試配置中心
在之前我們可以新建命名空間,來進行開發、測試、生產環境的配置隔離!
我們創建了三個:
上面概念時已經講過了,有三種維度,實際常用的一般就是前兩種,分組的話取默認的即可!
我們來創建配置:
隨便新建個配置,加點東西,方便我們后面訪問!
這里有個Data Id命名的規范,
一般是服務名+環境名+后綴
例子:service-stock-dev.yml
我們三個配置創建完成:
把程序里加上這些信息:
server:
port: 2001
spring:
profiles:
active: dev
application:
# 應用名稱
name: service-stock
cloud:
nacos:
discovery:
# 服務注冊地址
server-addr: localhost:18848
config:
# 命名空間
namespace: 03a31fa6-f665-40f2-9886-20b4c60498c5
# 配置中心地址
server-addr: ${spring.cloud.nacos.discovery.server-addr}
# 指定yml格式的配置 默認properties
file-extension: yml
# 配置文件prefix
prefix: ${spring.application.name}
# 共享配置
shared-configs:
- dataId: ${spring.application.name}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}
group: ${spring.cloud.nacos.config.group}
group: DEFAULT_GROUP
username: nacos
password: nacos
讀取配置類:
// 要交給spring容器,不然獲取不到值
@Component
// 配置讀取yml文件中前綴
@ConfigurationProperties(prefix = "product")
// 要有get方法,不然無法獲取值
@Data
public class Product {
private String name;
private BigDecimal price;
private String num;
}
下面我們寫一個測試類,來獲取Nacos上配置文件的信息:
配置文件里的信息:
八、總結
經過幾天的總結、梳理,斷斷續續的,Nacos還是有點東西的,源碼設計還是耐人尋味!
我們來總結一下吧!
本篇主要從Nacos的前世今生講起,介紹了核心點。下載安裝配置了Nacos,進行持久化的修改。
介紹Nacos的兩個核心功能:服務的注冊和發現、配置中心。簡單的從服務的注冊源碼進行查看,還是要自己debug看一下核心流程。「基本全是發布訂閱來解耦,單線程阻塞隊列來防止并發問題。」
最后實戰了一下,完成的服務的注冊和發現,并把application.yml的信息放到Nacos上統一管理。
Nacos的市場占用率還是挺高的,基本除了老項目還再用Eureka,除了自研都是這個了!