1. nacos官网以及提供的接口
1.1 官网地址
https://nacos.io/zh-cn/docs/open-api.html
1.2 常用的接口
2. 使用方式
2.1 添加依赖
com.alibaba.cloud
spring-cloud-alibaba-nacos-discovery
2.2 启动类上添加注解
@EnableDiscoveryClient
// 注:在新版的nacos中,可不用手动添加这个注解,而是通过spring.factories中读取配置,自动配置
2.3 配置yml文件
spring:
application:
name: base-data
cloud:
nacos:
discovery:
server-addr: localhost:8848
group: base-data
cluster-name: xxx
metadata:
current-version: V2
配置注意事项:
- 配置了group,则服务只有在同一个group下才能相互调用,
- cluster-name,是一个跨机房容灾部署的概念,如:北京集群,南京集群,跨集群是可以互相调用的,但一般要同集群优先调用,减少网络开销。
- Metadata.creent-version:指定版本,只有版本号相同才能互相调用。“金丝雀发布”就用到这个配置。如:A,B两个服务,个部署了1000台服务器,在一次升级中,为了确保服务的正确性,一般A,B先各发300台或者500台,指定他们的版本后,等到已发布的能够稳定运行,再升级剩余的服务器。
2.4 nacos数据模型
带集群的模型图
3. 寻找源码入口
-
导入nacos服务发现的包后,可以看到其层级结构如下:
对于这种引入的jar包,应该找其入口呢?spring.factories就是关键了。
打开这个文件
很明显其中,BootstrapConfiguration是在项目启动时自动加载的配置:
org.springframework.cloud.bootstrap.BootstrapConfiguration=\
com.alibaba.cloud.nacos.discovery.configclient.NacosDiscoveryClientConfigServiceBootstrapConfiguration
打开这个文件:
打开这个文件,发现它其实就做了一件事,引入了两个自动配置的类,
NacosDiscoveryClientAutoConfiguration.class,
NacosDiscoveryAutoConfiguration.class
这两个类都是包含在spring.factories中的。哪个才是服务注册相关的配置呢?
打开这两个类:
NacosDiscoveryClientAutoConfiguration
4.NacosDiscoveryAutoConfiguration 客户端服务注册入口
NacosDiscoveryAutoConfiguration
在NacosDiscoveryAutoConfiguration 文件中终于看到了几个与注册相关的词,那应该就是它,没错了。
这个自动化配置类,初始化了3个bean,仔细看看应该不难发现,自动注册的功能应该就在NacosAutoServiceRegistration中了。
打开这个类的类图,好像并不能发现什么线索。
这种情况,只有去它的父类找找了,NacosDiscoveryAutoConfiguration的父类实现了一个特殊的接口,值得注意一下,那就是ApplicationListener,这是一个事件监听器。
监听的事件是:WebServerInitializedEvent
这个事件是干嘛的呢?打开这个事件的源码,发现了下面这样一段注释。
大致意思是:这个事件会在上下文刷新后和WebServer已经准备好之后被发布。对于获取一个运行的服务的端口非常有用。
* Event to be published after the application context is refreshed and the
* {@link WebServer} is ready. Useful for obtaining the local port of a running server.
看看监听这个事件后究竟做了些什么?
经过,这一连串的调用,似乎终于找到正主了。看看getRegistration()去,发现是一个抽象方法
这应该算一个经典的模板设计模式了
真正的实现在其子类中,也就是:NacosAutoServiceRegistration中
[图片上传失败...(image-681e06-1584276360368)]
NacosRegistration也就是用于读取用户的一些配置,这些细枝末节先放过,还是回到主流程中
也就是
5. 注册和心跳
看看register究竟做了些什么
其中:instance.isEphemeral()这个实例是否是‘临时’的,默认是true
这里涉及到nacos的AP和CP模式,这是后话了
beatReactor.addBeatInfo(NamingUtils.getGroupedName(serviceName, groupName), beatInfo);
这里发起了一个http请求 ,想必你已经从它的名字看出来它是干嘛的了,没错,它就是一个心跳
完整的地址是:
/nacos/v1/ns/instance/beat
如何验证,是否正确呢?去官网看一下就知道了。
没有问题,它就是心跳
6.服务注册
下面这一行才是真正的发起注册的地方
serverProxy.registerService(NamingUtils.getGroupedName(serviceName, groupName), groupName, instance);
先拼接了一堆参数,然后发起了一个http请求,地址是:
拼接好后的地址就是:
/nacos//v1/ns/instance
怎么知道是否正确呢?去官方文档看一下就知道了
哈哈,正确的。
客户端发起的注册流程,到这就结束了,服务端接收到注册请求后具体是如何处理的,需要到服务端去查看。