共计 3298 个字符，预计需要花费 9 分钟才能阅读完成。
波及轻微的源码展现，可释怀参考；
一、根底简介
服务注册发现是微服务架构中最根底的能力，上面将从源码层面剖析实现逻辑和原理，在这之前要先来看下依赖工程的根底构造，波及如下几个外围组件：
- commons：服务组件的形象申明，本文只剖析注册发现与负载平衡；
- nacos：当下罕用的注册核心组件，用来进行服务治理；
- feign：服务间通信交互组件，在服务申请时波及负载平衡的策略；
- ribbon：在服务间通信申请时，提供多种负载平衡的策略实现；
在相熟工程依赖之间的构造时，还要明确服务间交互的流程和原理，这样在剖析源码设计时，有一个清晰的思路与轮廓；如何实现上面的服务交互模式，在浏览源码工程时，围绕如下两个外围逻辑：
- 注册发现：注册时如何上报服务的信息数据，这些数据以怎么的形式治理；
- 负载平衡：当申请的服务同时存在多个时，以什么样的策略抉择执行申请的服务；
在这里先简略的聊一下集体在浏览源码工程时的基本思路，比方微服务组件：通常从配置参数作为切入口，察看基于参数构建的外围对象，再重点剖析对象的管理模式，以及适配的扩大能力，最初联合我的项目的利用场景即可：
浏览源码最重要的是耐着情绪缓缓看，并顺手画下外围流程，实际上如果有肯定的编程教训，不论是浏览什么工程的源码，只有用心去剖析单点的实现原理，都算不上适度简单，然而组件通常为了复用能力，会去适配多种简单的场景，这样势必要采纳形象的封装和设计模式，源码工程的复杂度天然就会相应进步，这个话题后续会细聊。
二、服务注册
1、服务配置
首先从 Nacos 配置参数开始，这里只设置服务发现的两个参数：1Nacos 注册核心的服务端地址，2 在服务的元数据中加载分支号；而后来具体的看源码流程：
在配置参数加载的过程中，有很多缺省的默认值，所以须要关注最终会提供的参数信息，来判断是否须要自定义设置，另外 AutoConfig 配置要重点看实例化的对象；断点的流程能够依照如下的形式做设置，这里排列的是在配置加载阶段的几个外围节点：
- 参数：NacosDiscoveryProperties#getNacosProperties
- 配置：NacosServiceAutoConfiguration#nacosServiceManager
- 构建：NacosServiceManager#buildNamingService
NamingService 是 Nacos 服务治理接口，波及注册、查问、撤销、查看等多个办法，即对应的是 Nacos 服务端的相应 API 申请，在注册执行的阶段会细说用法。
2、注册构建
看完服务配置之后再看注册配置，对于配置中简单的设计，须要重点关注两个信息：ConditionalOn 和 matchIfMissing，这样很容易发现默认加载：
- 配置：NacosServiceRegistryAutoConfiguration#nacosServiceRegistry
- 注册：NacosServiceRegistry#register
- 实例：NacosServiceRegistry#getNacosInstanceFromRegistration
在构建服务注册的外围类 NacosServiceRegistry 时，通过服务的注销信息转换为注册的实例化对象，而后通过 NamingService 接口办法，上报实例化对象；须要留神的是，尽管这里只看了 Nacos 中的相干 API，但实际上 API 实现了诸多 spring-cloud-commons 包中申明的接口，比方 Registration、ServiceInstance 等。
3、执行上报
通常微服务的注册核心组件，都是基于 server-client 架构和部署形式，客户端须要依据本身启动状态去上报或者撤销注册，服务端负责对立保护注册数据：
- 实现：NacosNamingService#registerInstance
- 执行：NamingProxy#registerService
- 接口：InstanceController#register
在最终执行服务注册时，其动作实质就是申请 Nacos 服务端的一个 Post 办法，并将配置数据上报，例如：IP 地址、端口、元数据、权重等；这样客户端注册逻辑执行实现，而后再看服务端数据可视化界面，就能够看到注册的客户端服务。
至于 Nacos 服务端是如何治理这些注册数据的，参考部署版本的 nacos-naming 模块源码，浏览上报接口和页面中的列表加载的实现即可；留神在初始的配置文件中，退出的 branch 分支参数也在元数据结构中。
在 NamingService 接口中，波及多个服务治理的办法，在执行原理上基本相同就不在赘述，这样注册核心的 Client 端和 Server 端就造成了通信机制，接下来再看 Client 端之间的通信。
三、服务通信
1、根底配置
Feign 在配置方面比较复杂，提供了多个场景下的适配能力，这里只以两个常见的参数作为切入点：1 通信超时工夫，2Http 选型(采纳默认值)；
- 参数：FeignClientProperties#getConfig
- 注解：FeignClientsRegistrar#registerFeignClients
- 配置：FeignAutoConfiguration#feignContext
- 构建：FeignClientFactoryBean#getTarget
这里要重点关注的是注解的扫描和注册以及容器治理，要了解 Feign 的上下文环境须要明确上文中形容的服务间交互原理，而后参考 FeignClientFactoryBean 工厂类中构建逻辑。
2、通信逻辑
尽管 Feign 注解的形式能够简化开发，然而在具体执行的时候还是 Http 的申请响应模式，这里能够参考 LoadBalancerFeignClient 类中的 execute 办法：
- 配置：FeignRibbonClientAutoConfiguration
- 通信构建：LoadBalancerFeignClient#execute
- 负载平衡：AbstractLoadBalancerAwareClient#executeWithLoadBalancer
不论是 Feign 组件还是 Spring 框架，默认的负载平衡策略都是采纳 Ribbon 的实现形式，在上述流程中配置和负载平衡命令都依赖 Ribbon 组件，接下来看服务抉择策略。
四、负载平衡
1、命令构建
这里构建了调用负载平衡接口的命令，ILoadBalancer 接口中提供服务治理的相干办法，其中最外围的就是 chooseServer 办法，而后联合具体的策略规定实现服务的抉择的性能：
- 命令构建：LoadBalancerCommand.Builder#build
- 负载容器：LoadBalancerContext#getServerFromLoadBalancer
- 抉择接口：ILoadBalancer#chooseServer
2、策略规定
Ribbon 组件中负载平衡的策略有好几种规定，比方随机抉择、Key 匹配、权重歪斜等；在工作中罕用的就是默认规定即 RoundRobinRule，以及基于 Key 设计的灰度模式，简略做法就是服务启动时在元数据中增加的分支号作为匹配的标识；
- 规定设置：BaseLoadBalancer#setRule
- 随机策略：RoundRobinRule#choose
- 过滤策略：PredicateBasedRule#choose
当初回到流程的开始看，通过 Nacos 组件进行服务注册和治理，通过 Feign 组件基于 Ribbon 负载平衡策略做服务通信，如果单看各节点组件的逻辑还比拟容易了解，然而通过 Spring 框架做组件之间的合作调度时，复杂程度明显提高；
如果是刚开始浏览源码的阶段，能够只关注相应流程的外围逻辑，选择性疏忽细节的实现原理，当然重点还是要多读读 Spring 的设计，这样工夫久了天然会有很多播种。
五、参考源码
编程文档：https://gitee.com/cicadasmile/butte-java-note
利用仓库：https://gitee.com/cicadasmile/butte-flyer-parent