扒一扒Nacos、OpenFeign、Ribbon、loadbalancer、Dubbo 组件协调工作的原理(自编总结)

Nacos：

1. Nacos是一个注册中心和配置中心
2. 客户端和服务端：
   1. 服务端需要单独部署，用来保存服务实例数据的
   2. 客户端就是用来跟服务端通信的SDK，支持不同语言
3. 服务注册到Nacos服务端的时候，在服务端内部会有一个集合去存储服务的信息，服务注册表。
4. 如何进行服务自动注册？
   
   1. 服务实例数据封装--Registration：Registration是SpringCloud提供的一个接口，继承了ServiceInstance接口。从ServiceInstance的接口定义方法可以看出，这是一个服务实例数据的封装，比如这个服务的ip是多少，端口号是多少。
   2. ServiceRegistry也是个接口，泛型就是上面提到的服务实例数据封装的接口。这个接口的作用就是把上面封装的当前服务的数据Registration注册通过register方法注册到注册中心中。
   3. 服务自动注册--AutoServiceRegistration，AutoServiceRegistration是一个标记接口，所以本身没有实际的意义，仅仅代表了自动注册的意思。AutoServiceRegistration有个抽象实现AbstractAutoServiceRegistration。AbstractAutoServiceRegistration实现了ApplicationListener，监听了WebServerInitializedEvent事件。SpringBoot项目启动，最终就会调用ServiceRegistry注册Registration，实现服务自动注册。

   4. 

   5. 

      

      

      

       

Ribbon：

1. Ribbon是负载均衡组件，他的作用就是从众多的服务实例中根据一定的算法选择一个服务实例。
2. Ribbon提供了一个获取服务实例的接口，叫ServerList，会基于这些数据来做负载均衡的。Nacos自然而然也实现了ServerList接口，为Ribbon提供Nacos注册中心中的服务数据。
3. Ribbon的缺点：
   1. SpringCloud和Ribbon的耦合问题：Ribbon本身是一个具体的负载均衡组件，注册中心要想整合SpringCloud，还得需要单独去适配Ribbon。SpringCloud本身就是一套约束、规范，只要遵守这套规范，那么就可以实现各个组件的替换，这就是为什么换个注册中心只需要换个依赖，改个配置文件就行。就类似mybatis一样，mybatis依靠jdbc，但是mybatis根本不关心哪个数据库实现的jdbc。
   2. Ribbon已经不维护了
   3. 解决：而SpringCloud实际上是提供了这么一个获取服务实例的api，DiscoveryClient，随着Ribbon等组件停止维护之后，SpringCloud官方自己也搞了一个负载均衡组件loadbalancer，用来平替Ribbon。

OpenFeign：

1. OpenFeign是一个rpc框架，当我们需要调用远程服务的时候，只需要声明个接口就可以远程调用了。其实本质上就是后面会为接口创建一个动态代理对象，解析类上，方法上的注解。
2. 当调用方法的时候，会根据方法上面的参数拼接一个http请求地址，这个地址的格式是这样的http://服务名/接口路径。
3. Ribbon就会从注册中心获取到的服务实例中根据负载均衡策略选择一个服务实例返回给OpenFeign。OpenFeign拿到了服务实例，此时就获取到了服务所在的ip和端口，接下来就会重新构建请求路径，将路径中的服务名替换成ip和端口。
4. loadbalancer，其实也是一样的，他也会根据负载均衡算法，从DiscoveryClient获取到的服务实例中选择一个服务实例给OpenFeign，后面也会根据服务实例重构url，再发送http请求。
   

   

    

Dubbo 的整体架构设计?

1. 分层
   1. 接口服务层（Service）：该层与业务逻辑相关，根据 provider 和 consumer 的业务设计对应的接口和实现

      配置层（Config）：对外配置接口，以 ServiceConfig 和 ReferenceConfig 为 中心

      服务代理层（Proxy）：服务接口透明代理，生成服务的客户端 Stub 和 服务端 的 Skeleton，以 ServiceProxy 为中心，扩展接口为ProxyFactory

      服务注册层（Registry）：封装服务地址的注册和发现，以服务 URL 为中心， 扩展接口为 RegistryFactory、Registry、RegistryService

      路由层（Cluster）：封装多个提供者的路由和负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为 Cluster、Directory、Router 和 LoadBlancce

      监控层（Monitor）：RPC 调用次数和调用时间监控，以 Statistics 为中心， 扩展接口为 MonitorFactory、Monitor 和 MonitorService

      远程调用层（Protocal）：封装 RPC 调用，以 Invocation 和 Result 为中心， 扩展接口为 Protocal、Invoker 和 Exporter

      信息交换层（Exchange）：封装请求响应模式，同步转异步。以 Request 和 Response 为中心，扩展接口为 Exchanger、ExchangeChannel、 ExchangeClient 和 ExchangeServer

      网络传输层（Transport）：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel、Transporter、Client、Server 和 Codec

      数据序列化层（Serialize）：可复用的一些工具，扩展接口为 Serialization、 ObjectInput、ObjectOutput 和 ThreadPool Dubbo