1. nacos官网以及提供的接口
1.1 官网地址
https://nacos.io/zh-cn/docs/open-api.html
1.2 常用的接口
nacos常用接口
2. 使用方式
2.1 添加依赖
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-nacos-discovery</artifactId>
</dependency>
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数据模型
nacos官网数据模型图
带集群的模型图
带集群的模型图
3. 寻找源码入口
-
导入nacos服务发现的包后，可以看到其层级结构如下:
image-20200315194032861
对于这种引入的jar包，应该找其入口呢？spring.factories就是关键了。
打开这个文件
image-20200315194618390
很明显其中，BootstrapConfiguration是在项目启动时自动加载的配置:
org.springframework.cloud.bootstrap.BootstrapConfiguration=\
com.alibaba.cloud.nacos.discovery.configclient.NacosDiscoveryClientConfigServiceBootstrapConfiguration
打开这个文件：
image-20200315195027295
打开这个文件，发现它其实就做了一件事，引入了两个自动配置的类，
NacosDiscoveryClientAutoConfiguration.class,
NacosDiscoveryAutoConfiguration.class
这两个类都是包含在spring.factories中的。哪个才是服务注册相关的配置呢？
打开这两个类：
NacosDiscoveryClientAutoConfiguration
image-20200315195524925
4.NacosDiscoveryAutoConfiguration 客户端服务注册入口
NacosDiscoveryAutoConfiguration
image-20200315195725398
在NacosDiscoveryAutoConfiguration 文件中终于看到了几个与注册相关的词，那应该就是它，没错了。
这个自动化配置类，初始化了3个bean,仔细看看应该不难发现，自动注册的功能应该就在NacosAutoServiceRegistration中了。
打开这个类的类图，好像并不能发现什么线索。
image-20200315200212461
这种情况，只有去它的父类找找了，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.
image-20200315200325358
看看监听这个事件后究竟做了些什么？
image-20200315200826713
image-20200315201006727
image-20200315201030942
经过，这一连串的调用，似乎终于找到正主了。看看getRegistration()去，发现是一个抽象方法
这应该算一个经典的模板设计模式了
image-20200315201317105
真正的实现在其子类中，也就是：NacosAutoServiceRegistration中
[图片上传失败...(image-681e06-1584276360368)]
NacosRegistration也就是用于读取用户的一些配置，这些细枝末节先放过，还是回到主流程中
也就是
image-20200315201801335
5. 注册和心跳
看看register究竟做了些什么
image-20200315201852206
image-20200315201946120
其中：instance.isEphemeral()这个实例是否是‘临时’的，默认是true
这里涉及到nacos的AP和CP模式，这是后话了
beatReactor.addBeatInfo(NamingUtils.getGroupedName(serviceName, groupName), beatInfo);
image-20200315202336622
image-20200315203518721
image-20200315203552977
这里发起了一个http请求 ，想必你已经从它的名字看出来它是干嘛的了，没错，它就是一个心跳
image-20200315203630563
完整的地址是：
/nacos/v1/ns/instance/beat
如何验证，是否正确呢？去官网看一下就知道了。
image-20200315203926099
没有问题，它就是心跳
6.服务注册
下面这一行才是真正的发起注册的地方
serverProxy.registerService(NamingUtils.getGroupedName(serviceName, groupName), groupName, instance);
image-20200315202851557
先拼接了一堆参数，然后发起了一个http请求，地址是：
image-20200315202945748
拼接好后的地址就是:
/nacos//v1/ns/instance
怎么知道是否正确呢？去官方文档看一下就知道了
image-20200315203149301
哈哈，正确的。
客户端发起的注册流程，到这就结束了，服务端接收到注册请求后具体是如何处理的，需要到服务端去查看。
网友评论