Ⅰ 微服务架构 | *3.5 Nacos 服务注册与发现的源码分析
参考资料 ：
《Spring Microservices in Action》
《Spring Cloud Alibaba 微服务原理与实战》
《B站 尚硅谷 SpringCloud 框架开发教程 周阳》
为方便理解与表达，这里把 Nacos 控制台和 Nacos 注册中心称为 Nacos 服务器（就是 web 界面那个），我们编写的业务服务称为 Nacso 客户端；
Nacos 客户端将自己注册进 Nacos 服务器。《1. 服务如何注册进 Nacos 注册中心》主要从 Nacos 客户端角度解释如何发送信息给 Nacos 服务器；《2. Nacos 服务器注册服务》主要从 Nacos 服务器角度解释注册原理；
《3. 客户端查询所有服务实例》将从服务消费者和提供者的角度，解释服务消费者如何获取提供者的所有实例。服务消费者和提供者都是 Nacos 的客户端；
《4. 客户端监听 Nacos 服务器以动态获取服务实例》从消费者客户端角度出发监听 Nacos 服务器，以动态获知提供者的变化；
Ⅱ Spring Cloud 整合Grpc-注册中心（Eureka/Consul）
Spring Cloud分布式微服务应用，通常在微服务之间采用的Feign进行通信，实现简单快捷的调用，底层采用的HTTP形式；相对于gRPC或RPC协议调用来说，性能相对低下，因此我们可以采用开源技术框架gRPC来实现。
微服务开发中，服务间的调用一般有两种方式：Feign或RestTemplate，但在实际使用过程中，尤其是Feign，存在各种限制及局限性，如：HTTP请求方式、返回类型等限制等。服务间调用是非常普遍频繁的，其性能也不是特别理想。
为了解决上述问题，我们采用gRPC方式实现服务间调用，其显着特点就是性能之高(通信采用Netty)，通过proto文件定义的接口也是非常清晰而又灵活。
gRPC是谷歌开源的一个高性能的、通用的RPC框架。和其他RPC一样，客户端应用程序可以直接调用远程服务的方法，就好像调用本地方法一样。它隐藏了底层的实现细节，包括序列化（XML、JSON、二进制）、数据传输（TCP、HTTP、UDP）、反序列化等，开发人员只需要关自业务本身，而不需要关注RPC的技术细节。与其他RPC框架一样，gRPC也遵循定义服务(类似于定义接口的思想)。gRPC客户端通过定义方法名、方法参数和返回类型来声明一个可以被远程调用的接口方法。由服务端实现客户端定义的接口方法，并运行一个gRPC服务来处理gPRC 客户端调用，gRPC客户端和服务端共用一个接口方法。
新建common项目，存放proto文件，服务端和客户端都依赖此项目。
* pom依赖
* 新建helloworld.proto文件，放在：src/main/proto/helloworld.proto
* pom.xml依赖
* 新建GrpcServerService
}
* yml配置
* pom.xml依赖配置
* 新建GrpcClientService
* yml配置
Consul和Eureka区别在于替换pom依赖、yml注册地址修改、启动类修改。
源码： 提取码: 28qs
源码：spring-boot-rpc
提取码: 28qs
Ⅲ Kitex 源码解析 —— 将服务注册进入注册中心的细节
Kitex为 字节跳动 内部的 Golang 微服务 RPC 框架，具有 高性能 、 强可扩展 的特点，在字节内部已广泛使用。如果对微服务性能有要求，又希望定制扩展融入自己的治理体系，Kitex 会是一个不错的选择。
这次我们可以从 官方示例 中的 easy_note 这个demo 开始分析，因为它基本展示了 Kitex 的基本使用方法。
下面图例为官方在 demo 中展示的架构图，通过简单的分析可得, note , user 通过 注册中心 (Etcd) 进行注册 ， api 通过 注册中心 来发现 note , user 两个 rpc 服务, 并进行业务处理。
从 kitex-examples/hello 这个最简单示例分析，从 cloudwego/kitex 的快速上手可知，这里用了最简单的 直链 来链接 server 和 client。而这次的 easy_note 中使用了 注册中心 来作为 服务之间的 桥梁 (middleware), 为什么不使用之前的方式而是使用了注册中心？
我们搜索一下注册中心的作用，可知: 服务注册中心的主要作用就是“服务的注册”和“服务的发现”
我们将服务交给注册中心管理，虽然可以避免处理复杂的手动管理，我们也许需要还要考虑更多问题，例如：
这次目标之一就是来解析解析服务是如何在服务启动时进行 注册 ( Register ) 这个操作的, 这次我们从 easy_note/cmd/user 这个服务开始分析, 因为它是被 注册 进入 Etcd 的服务之一。
我们从其中的 main.go 开始下手，以下的内容是经过简化后的文件，是实现配置服务，启动服务的文件
由注释可知 WithRegister() 为配置 注册信息 的函数 ，那为什么直接就看这个函数呢？
一是因为主要配置注册的主要逻辑在其中，二是因为 With... 的函数结构都是大同小异，十分相似的。
再然后我们进入 kitex/server/option.go ，先看看 di.Push(fmt.Sprintf("WithRegistry(%T)", r)) 这一行，
这个 *util.Slice 是什么 ？进去看看？
进入 kitex/pkg/utils/slice.go , 我发现它很简短。但是它好眼熟，它好像是一个非常常见的数据结构 —— Stack (栈) ！
在这个文件之下有它的 slice__test.go 文件 ，看到这里的朋友可以去试验一下是否这个 Slice 和我的想法是否一致，大家看文章是要思考的嘛！最好可以动动手！
我们再进入 o.Registry = r 这一行，可以得知 Options 用于初始化 server， Option 用于配置 Options (我觉得这种命名方式很巧妙，我感觉基本达到了 见名知意 的作用)，里面东西很多，我们今天只看 Register 部分
到了这里我们可以暂停思考一下，到达这一步是怎么个过程呢？是通过 main.go/user.NewServer(） 的方法进来的。
那 NewServer() 的作用是什么？是用于配置初始化服务器的 可选参数 ，
配置完了参数什么时候生效呢 ( Register 是什么时候发生的呢) ？其实配置的实现就在 main.go NewServer() 的下一句， Run() !
进入Run方法的实现，可以得知 register 是发生在 server 启动成功后 的，停止也是会向 Etcd 进行注销操作的 (大家可以在同文件的 Stop() 中查看)
至此 服务完成了向 Etcd 的注册，我忽略了许多其他细节，这些细节也很有意思，希望大家可以自己试着探索
这次文章其实向大家分析了如何配置服务，以及向注册中心进行注册的方法和时机。
虽然省略了许多细节，但是通过这篇文章可以学到什么呢？
Ⅳ Eureka源码浅读---自我保护机制
Eureka源码采用1.7.2版本
本人小白，此文为本人阅读源码笔记，如果您读到本文，您需要自己甄别是否正确，文中的说明只代表本人理解，不一定是正确的！！！
自我保护机制设计的初衷是防止服务注册服务因为本地网络故障，长时间未接受到心跳请求，造成错误的移除大量服务实例，其实调用服务还是可用的
自我保护机制是和自动故障移除联系在一起的，针对的移除实例也是自动故障移除
在服务故障移除的方法中有这样一个判断，当返回false时候，直接返回，不进行故障实例的摘除
进入该方法
关于获取上一分钟心跳总数，Eureka Server内部采用的是定时线程进行统计，使用两个AtomicLong进行保存当前和上一分钟的心跳总数
该方法初始化了运行了定时调度的线程进行统计，默认执行间隔为1min，执行流程：
那么当前的心跳总数是怎么计算的呢，直接看心跳的renew()方法，是否嵌入了计数器累计操作
如上所示，当接收到心跳时，当前心跳计数器进行了递增操作
而getNumOfRenewsInLastMin()获取上一分钟心跳总数就是获取lastBucket数量，再找下该定时任务启动的入口
和自动故障移除的定时同时启动的，那么lastBucket代表了上一分钟的心跳总数
接下来，我们需要看看期望每分钟最小心跳总数的由来：
numberOfRenewsPerMinThreshold最开始的初始化计算是在Eureka Server初始化计算的，使用当前Server拉取到的服务实例总数 * 0.85
在openForTraffic()方法中使用初始化拉取的服务实例总数作为基数标准进行计算，(int) (this.expectedNumberOfRenewsPerMin * serverConfig.getRenewalPercentThreshold()) -> count * 2 * 0.85,
集群模式下，count为其他节点中已注册的服务实例总数，单节点就为0
下面我们看看在注册中心接收到注册，下线等请求执行时，维护numberOfRenewsPerMinThreshold
注册，当前实例数量+2，下线，当前实例数量-2，然后再次*0.85，计算期望每分钟最小心跳数
在Eureka Server中有专门的定时任务进行更新numberOfRenewsPerMinThreshold,默认每15min执行一次
主要流程如下：
注意，自动服务故障移除没有进行numberOfRenewsPerMinThreshold的更新
<font color= 'blue'>服务故障实例的摘除需要判断当前是否处于自我保护模式，而自我保护模式的默认是开启(isSelfPreservationModeEnabled)，需要判断上一分钟的心跳总数是否大于期望每分钟最小心跳数，如果在15分钟内，累计丢失了15%以上的节点心跳，那么Eureka Server就会认为当前所处的网络环境异常，从而处于自动保护模式，故障实例将不会移除，再等待15min后，进行expectedNumberOfRenewsPerMin的基于当前服务实例的重新计算后，自我保护模式才会关闭!</font>
自我保护服务开启模拟：
Ⅳ springboot 2.4.13 无法从nacos获取配置，但是可以注册到nacos
springboot 2.4.13，集成了nacos，启动后，nacos注册中心有服务，但是，发现，配置没有生效。于是，开启了一段源码查找的过程。
首先，是pom引入的nacos配置
然后，application.yml添加nacos配置
启动后，发现注册中心有服务，但是，服务的配置不是从nacos配置中心获取的，而是本地的。
查找一下nacos源码，找到nacos配置自动注入那块儿：
然后发现，是这个NacosPropertySourceLocator实现的配置导入的
查询源码，可以发现，相关的配置，是通过这个方法，加载的，这个方法是总入口。
于是，尝试加断点，查看配置信息，看看为什么没有导入配置。然而，程序根本就没有进入这个方法里面！！！
根据接口实现，可以发现NacosPropertySourceLocator 是PropertySourceLocator的实现类，这个方法的调用执行，不是nacos自己去做的，而是通过spring去做的。
spring cloud 通过BootstrapApplicationListener，以监听器的方式，通过监听springboot启动过程中的事件，通过onApplicationEvent方法处理事件，导入spring cloud相关配置。
通过加断点，可以发现，这里的方法bootstrapEnabled()返回值是false，直接就不执行后续的加载了。
因此，需要保证bootstrapEnabled返回值是true。
查看PropertyUtils源码，可以发现，需要配置项 spring.cloud.bootstrap.enabled=true 并且存在 org.springframework.cloud.bootstrap.marker.Marker 类的时候，spring cloud 才会去加载spring cloud的配置。
因此，pom中需要添加marker所在的组件依赖：
此时，需要在 bootstrap.yml 中添加spring cloud配置：
（至于为什么是bootstrap.yml而不是application.yml，这又是另一个问题了）
有了上面的配置，程序启动后，就能正常的从nacos配置中心获取配置了。
Ⅵ 如何更好地学习bbo源代码
1、Dubbo与Spring的整合 Dubbo在使用上可以做到非常简单，不管是Provider还是Consumer都可以通过Spring的配置文件进行配置，配置完之后，就可以像使用 spring bean一样进行服务暴露和调用了，完全看不到bbo api的存在。这是因为bbo使用了spring提供的可扩展Schema自定义配置支持。在spring配置文件中，可以像、这样进行配置。 META-INF下的spring.handlers文件中指定了bbo的xml解析类：DubboNamespaceHandler。像前面的被解 析成ServiceConfig，被解析成ReferenceConfig等等。 2、jdk spi扩展 由于Dubbo是开源框架，必须要提供很多的可扩展点。Dubbo是通过扩展jdk spi机制来实现可扩展的。具体来说，就是在META-INF目录下，放置文件名为接口全称，文件中为key、value键值对，value为具体实现类 的全类名，key为标志值。由于bbo使用了url总线的设计，即很多参数通过URL对象来传递，在实际中，具体要用到哪个值，可以通过url中的参 数值来指定。 Dubbo对spi的扩展是通过ExtensionLoader来实现的，查看ExtensionLoader的源码，可以看到Dubbo对jdk spi做了三个方面的扩展：
（1）jdk spi仅仅通过接口类名获取所有实现，而ExtensionLoader则通过接口类名和key值获取一个实现；
（2）Adaptive实现，就是生成一个代理类，这样就可以根据实际调用时的一些参数动态决定要调用的类了。
（3）自动包装实现，这种实现的类一般是自动激活的，常用于包装类，比如Protocol的两个实现类：ProtocolFilterWrapper、ProtocolListenerWrapper。 3、url总线设计 Dubbo为了使得各层解耦，采用了url总线的设计。我们通常的设计会把层与层之间的交互参数做成Model，这样层与层之间沟通成本比较大，扩展起来也比较麻烦。因此，Dubbo把各层之间的通信都采用url的形式。比如，注册中心启动时，参数的url为： registry://0.0.0.0:9090?codec=registry&transporter=netty 这就表示当前是注册中心，绑定到所有ip，端口是9090，解析器类型是registry，使用的底层网络通信框架是netty。