nacos客户端服务注册源码分析

1. nacos官网以及提供的接口

1.1 官网地址

https://nacos.io/zh-cn/docs/open-api.html

1.2 常用的接口

nacos常用接口

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

配置注意事项:

  1. 配置了group,则服务只有在同一个group下才能相互调用,
  2. cluster-name,是一个跨机房容灾部署的概念,如:北京集群,南京集群,跨集群是可以互相调用的,但一般要同集群优先调用,减少网络开销。
  3. Metadata.creent-version:指定版本,只有版本号相同才能互相调用。“金丝雀发布”就用到这个配置。如:A,B两个服务,个部署了1000台服务器,在一次升级中,为了确保服务的正确性,一般A,B先各发300台或者500台,指定他们的版本后,等到已发布的能够稳定运行,再升级剩余的服务器。

2.4 nacos数据模型

nacos官网数据模型图

带集群的模型图

带集群的模型图

3. 寻找源码入口

  1. 导入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

哈哈,正确的。

客户端发起的注册流程,到这就结束了,服务端接收到注册请求后具体是如何处理的,需要到服务端去查看。

你可能感兴趣的:(nacos客户端服务注册源码分析)