一、SpringCloud 简介
Spring Cloud 是一系列框架的有序集合如服务发现注册、配置中心、消息总线、负载均衡、熔断器、数据监控等。
SpringCloud 将多个服务框架组合起来,通过Spring Boot进行再封装,屏蔽掉了复杂的配置和实现原理,最终给开发者提供了一套简单易懂、易部署和易维护的分布式系统开发工具包。
Spring Cloud是一个基于SpringBoot实现的微服务开发方案,Spring boot 是 Spring 的一套快速配置框架。可以基于spring boot 快速开发单个微服务。
二、NACOS简介
一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。
1、Nacos中的概念
地域
物理的数据中心,资源创建成功后不能更换。
可用区
同一地域内,电力和网络互相独立的物理区域。同一可用区内,实例的网络延迟较低。
接入点
地域的某个服务的入口域名。
命名空间
用于进行租户粒度的配置隔离。不同的命名空间下,可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离,例如开发测试环境和生产环境的资源(如配置、服务)隔离等。
配置
在系统开发过程中,开发者通常会将一些需要变更的参数、变量等从代码中分离出来独立管理,以独立的配置文件的形式存在。目的是让静态的系统工件或者交付物(如 WAR,JAR 包等)更好地和实际的物理运行环境进行适配。配置管理一般包含在系统部署的过程中,由系统管理员或者运维人员完成。配置变更是调整系统运行时的行为的有效手段。
配置管理
系统配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动。
配置项
一个具体的可配置的参数与其值域,通常以 param-key=param-value 的形式存在。例如我们常配置系统的日志输出级别(logLevel=INFO|WARN|ERROR) 就是一个配置项。
配置集
一组相关或者不相关的配置项的集合称为配置集。在系统中,一个配置文件通常就是一个配置集,包含了系统各个方面的配置。例如,一个配置集可能包含了数据源、线程池、日志级别等配置项。
配置集 ID
Nacos 中的某个配置集的 ID。配置集 ID 是组织划分配置的维度之一。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集,每个配置集都可以被一个有意义的名称标识。Data ID 通常采用类 Java 包(如 com.taobao.tc.refund.log.level)的命名规则保证全局唯一性。此命名规则非强制。
配置分组
Nacos 中的一组配置集,是组织配置的维度之一。通过一个有意义的字符串(如 Buy 或 Trade )对配置集进行分组,从而区分 Data ID 相同的配置集。当您在 Nacos 上创建一个配置时,如果未填写配置分组的名称,则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景:不同的应用或组件使用了相同的配置类型,如 database_url 配置和 MQ_topic 配置。
配置快照
Nacos 的客户端 SDK 会在本地生成配置的快照。当客户端无法连接到 Nacos Server 时,可以使用配置快照显示系统的整体容灾能力。配置快照类似于 Git 中的本地 commit,也类似于缓存,会在适当的时机更新,但是并没有缓存过期(expiration)的概念。
服务
通过预定义接口网络访问的提供给客户端的软件功能。
服务名
服务提供的标识,通过该标识可以唯一确定其指代的服务。
服务注册中心
存储服务实例和服务负载均衡策略的数据库。
服务发现
在计算机网络上,(通常使用服务名)对服务下的实例的地址和元数据进行探测,并以预先定义的接口提供给客户端进行查询。
元信息
Nacos数据(如配置和服务)描述信息,如服务版本、权重、容灾策略、负载均衡策略、鉴权配置、各种自定义标签 (label),从作用范围来看,分为服务级别的元信息、集群的元信息及实例的元信息。
应用
用于标识服务提供方的服务的属性。
服务分组
不同的服务可以归类到同一分组。
虚拟集群
同一个服务下的所有服务实例组成一个默认集群, 集群可以被进一步按需求划分,划分的单位可以是虚拟集群。
实例
提供一个或多个服务的具有可访问网络地址(IP:Port)的进程。
权重
实例级别的配置。权重为浮点数。权重越大,分配给该实例的流量越大。
健康检查
以指定方式检查服务下挂载的实例 (Instance) 的健康度,从而确认该实例 (Instance) 是否能提供服务。根据检查结果,实例 (Instance) 会被判断为健康或不健康。对服务发起解析请求时,不健康的实例 (Instance) 不会返回给客户端。
健康保护阈值
为了防止因过多实例 (Instance) 不健康导致流量全部流向健康实例 (Instance) ,继而造成流量压力把健康实例 (Instance) 压垮并形成雪崩效应,应将健康保护阈值定义为一个 0 到 1 之间的浮点数。当域名健康实例数 (Instance) 占总服务实例数 (Instance) 的比例小于该值时,无论实例 (Instance) 是否健康,都会将这个实例 (Instance) 返回给客户端。这样做虽然损失了一部分流量,但是保证了集群中剩余健康实例 (Instance) 能正常工作。
2、Nacos 架构
基础架构如下:
逻辑架构及组件如下:
- 服务管理:实现服务CRUD,域名CRUD,服务健康状态检查,服务权重管理等功能
- 配置管理:实现配置管CRUD,版本管理,灰度管理,监听管理,推送轨迹,聚合数据等功能
- 元数据管理:提供元数据CURD 和打标能力
- 插件机制:实现三个模块可分可合能力,实现扩展点SPI机制
- 事件机制:实现异步化事件通知,sdk数据变化异步通知等逻辑
- 日志模块:管理日志分类,日志级别,日志可移植性(尤其避免冲突),日志格式,异常码+帮助文档
- 回调机制:sdk通知数据,通过统一的模式回调用户处理。接口和数据结构需要具备可扩展性
- 寻址模式:解决ip,域名,nameserver、广播等多种寻址模式,需要可扩展
- 推送通道:解决server与存储、server间、server与sdk间推送性能问题
- 容量管理:管理每个租户,分组下的容量,防止存储被写爆,影响服务可用性
- 流量管理:按照租户,分组等多个维度对请求频率,长链接个数,报文大小,请求流控进行控制
- 缓存机制:容灾目录,本地缓存,server缓存机制。容灾目录使用需要工具
- 启动模式:按照单机模式,配置模式,服务模式,dns模式,或者all模式,启动不同的程序+UI
- 一致性协议:解决不同数据,不同一致性要求情况下,不同一致性机制
- 存储模块:解决数据持久化、非持久化存储,解决数据分片问题
- Nameserver:解决namespace到clusterid的路由问题,解决用户环境与nacos物理环境映射问题
- CMDB:解决元数据存储,与三方cmdb系统对接问题,解决应用,人,资源关系
- Metrics:暴露标准metrics数据,方便与三方监控系统打通
- Trace:暴露标准trace,方便与SLA系统打通,日志白平化,推送轨迹等能力,并且可以和计量计费系统打通
- 接入管理:相当于阿里云开通服务,分配身份、容量、权限过程
- 用户管理:解决用户管理,登录,sso等问题
- 权限管理:解决身份识别,访问控制,角色管理等问题
- 审计系统:扩展接口方便与不同公司审计系统打通
- 通知系统:核心数据变更,或者操作,方便通过SMS系统打通,通知到对应人数据变更
- OpenAPI:暴露标准Rest风格HTTP接口,简单易用,方便多语言集成
- Console:易用控制台,做服务管理、配置管理等操作
- SDK:多语言sdk
- Agent:dns-f类似模式,或者与mesh等方案集成
- CLI:命令行对产品进行轻量化管理,像git一样好用
部署架构如下:
nacos 官网以及帮助文档和部署手册:https://nacos.io/zh-cn/index.html
nacos github: https://github.com/alibaba/nacos
三、NACOS源码分析
1、Nacos注册源码分析-Clinet端
cosumer启动的时候,从nacos server上读取指定服务名称的实例列表,缓存到本地内存中。
开启一个定时任务,每隔10s去nacos server上拉取服务列表
nacos的push机制:
通过心跳检测发现服务提供者出现心态超时的时候,推送一个push消息到consumer,更新本地的缓存数据。
客户端Client
我们自己的项目在配置了nacos作为注册中心后,至少要配置这么一个属性
这个属性会让应用找到nacos的server地址去注册。如果不配置的话,会一直报错
springboot的@EnableAutoConfiguration这里就不再讲解了。都到nacos的源码了,springboot默认是熟悉的。
我们再去打开NacosServiceRegistryAutoConfiguration这个类。
其中第三个类NacosAutoServiceRegistration
实现了一个抽象类AbstractAutoServiceRegistration
.
这里有实现一个ApplicationListener<WebServerInitializedEvent>的类,这个类是spring的一个监听事件(观察者模式),而这个事件就是webserver初始化的时候去触发的。onApplicationEvent方法调用了bind()方法。而bind()中又调用了start().
start()中有一个register()。而这个register就是NacosServiceRegistry中的register()。
- getNacosInstanceFromRegistration 获取注册的实例信息。
- namingService.registerInstance(serviceId, group, instance);
clientProxy有3个实现类,NamingClientProxyDelegate、NamingGrpcClientProxy、NamingHttpClientProxy。
这个类的构造方法中有个init(properties)方法,这个方法中给clientProxy赋值了。走的是NamingClientProxyDelegate方法。一般情况下,带有delegate的方法都是委派模式。
基于http1.x协议注册
- NamingClientProxyDelegate.registerService
委派这里做了一个可执行的判断
NamingClientProxyDelegate.getExecuteClientProxy
做了一个判断,配置ephemeral=false就走http,否则grpc。这里请注意,如果nacos-server还是用的1.x.x版本的话,会报错的。因为2.x.x增加一个grpc的支持,会额外的多增加一个端口,默认对外提供端口为8848和9848
- NamingHttpClientProxy.registerService
这里的clientProxy=NamingHttpClientProxy
NamingHttpClientProxy.reqApi
serverListManager.isDomain()这个判断是配置了几个nacos server的值,如果是一个的话,走if逻辑,如果多余1个的话,走else逻辑。
else中的servers就是nacos server服务列表,通过Ramdom拿到一个随机数,然后去callServer(),如果发现其中的一个失败,那么index+1 获取下一个服务节点再去callServer。如果所有的都失败的话,则抛出错误。
NamingHttpClientProxy.callServer
前边的判断支线省略,拼接url,拼好了后,进入try逻辑块中,这里封装了一个nacosRestTemplate类。请求完成后,返回一个restResult,拿到了请求结果后,把请求结果code放入了一个交MetricsMonitor的类中了,从代码上看很明显是监控相关的类,点击进去果然发现是prometheus相关的。这里我们不扩展了,继续回到主线。
如果返回结果是200的话,把result.content返回去。
- NacosRestTemplate.exchangeForm
关键方法:this.requestClient().execute()
HttpClientBeanHolder.getNacosRestTemplate
典型的双重检查锁。
而NamingHttpClientFactory是一个AbstractHttpClientFactory的实现类,由于NamingHttpClientProxy没有重写createNacosRestTemplate方法。所以最终引用的也就是AbstractHttpClientFactory的createNacosRestTemplate方法。
AbstractHttpClientFactory.createNacosRestTemplate
JdkHttpClientRequest clientRequest = new JdkHttpClientRequest(httpClientConfig);
可以看到这里定义了一个JdkHttpClientRequest 。
再往下跟就到java.net.HttpURLConnection的调用,去请求nacos-server的地址,再往下的就不做分析了,进入了http的通讯层了。
最终返回了一个结果,如果是200的话,就注册成功了。失败了就会抛出异常。
基于gRPC http2.0的注册
这里同样的从gRPC和http的委派来进行分析
NamingClientProxyDelegate.registerService
代码上边已经分析过,我们直接进入gRPC的实现。
- NamingGrpcClientProxy.registerService
redoService.cacheInstanceForRedo 这个从名称上看应该是重试机制,
- NamingGrpcRedoService.cacheInstanceForRedo
这里看起来只是给ConcurrentMap中存放一个redoData,并没有其他的逻辑,后续可能会用到这个。回到主线,继续往下走。
- NamingGrpcClientProxy.doRegisterService
request是根据构造函数封装的一个实例,requestToServer去进行注册。
NamingGrpcClientProxy.requestToServer
request.putAllHeader推测是跟权限校验相关的,我搭建的没有设置鉴权,所以都是空的。
然后根据rpcClient去调用request方法。根据超时时间判断的,这2个分支最终都会进入一个方法,默认是3s的超时时间。
最终返回一个response结果。
- RpcClient.request
这里的校验暂且不看,直切主线, response = this.currentConnection.request(request, timeoutMills);
再进入到request方法。
- GrpcConnection.request
这里的就是封装的rpc请求,和服务端进行交互的逻辑。在这里封装了一个PayLoad类
2、Nacos注册源码分析-Server端
接收注册
客户端和服务端之间进行交互的话,一定需要建立一个网络连接。这里的grpc的源码相对来说比较复杂,就简单分析nacos相关的。
工程名称是nacos-console。
BaseGrpcServer在启动的时候会绑定很多的Handler。
而基于grpc的通信,会进入server端的InstanceRequestHandler
InstanceRequestHandler.handle
从handle方法中可以根据type走到registerInstance中。
最终进入到EphemeralClientOperationServiceImpl.registerInstance
EphemeralClientOperationServiceImpl.registerInstance
这里的clientManager.getClient(client)说明跳转到下边的建立长连接
AbstractClient.addServiceInstance
ClientServiceIndexesManager
建立长连接(这里的过程比较难一些,还在持续学习中)
GrpcBiStreamRequestAcceptor这个类是建立连接的。
每一个grpc请求过来后,都会进入到GrpcBiStreamRequestAcceptor.requestBiStream的方法中。
而会话的长连接id就是这里的ConnectionId。
- ConnectionManager.register
这里的connections是用来管理所有的长连接的