dubbo

在Dubbo中，将网络通讯分为了网络传输层和信息交换层。 对应的接口分别是Transporter，Exchanger，对应的使用的是SPI自适应扩展机制在代码中进行使用。 在网络传输层和信息交换层主要

Dubbo中的负载均衡分为四类，如下图： Dubbo提供了四种负载均衡： RandomLoadBalance---基于权重随机的选择一个。是Dubbo的默认负载均衡策略。 RoundRobinLoad

服务目录的用途在于查找Invoker以及服务提供者变更的时候进行刷新Invoker。 这点我们可以从它的父类接口的方法看出来。 这里同样的还有一个通用套路，就是一个抽象类AbstractDirecto

在我们日常微服务使用中，调用的服务一般都会有多个节点，那么这个时候就会涉及到多个服务可能其中有一或者多个服务不可用，我们要保证我们的服务尽可能调用返回一个正确的响应结果。再或者说我们的多个服务节点在被

在Dubbo中，代理被分为两类，一个是服务提供方使用Wrapper生成的代理，一个是服务消费者使用Proxy生成的代理。 1.服务消费者的代理源码 在服务启动时，服务被实例化时会调用Reference

原理呢我们得从服务向Nacos注册时的源码开始分析，这里在向nacos发送http请求注册的时候会开启一个线程进行死循环从阻塞队列中获取事件。 1.NacosRegistry 2.NacosNamin

Dubbo的远程调用是基于代理，也就是我们@DubboServie注入对象是一个代理对象。代理对象会调用到InvocationHandler的invoke方法。 1.InvokerInvocation

Dubbo代理对象的过程是在注入Dubbo的Service过程中实现的，比如我们的Controller中注入了一个Dubbo服务，如下 源码中，起点的位置是在ReferenceConfig中， 1 R

服务发布订阅的起点是在ReferenceConfig类的get方法。 1.ReferenceConfig 2.RegistryProtocol 3.RegistryDirectory 4.Failba

整体流程如下 1.RegistryProtocol类 2.FailbackRegistry类 3.NacosRegistry类（我使用的是Nacos注册中心，所以这里走到这里） 4.NacosNami

流程如下 1.RegistryProtocol类 2.DubboProtocol类 3.Exchangers类 4.HeaderExchanger类 5.Transporters类 6.NettyTr

@Adaptive:为生成Adaptive实例提供参数，作用域在类或方法上； Adatpive，字面意思是个适配，但其实是个代理，它的意思是适配合适的对象处理请求。类似jdk的动态代理，因为dubbo

SPI核心机制主要依赖于ExtensionLoader类，在3.0版本中获取扩展点的方式跟2版本是有区别的，已经废弃了原本的方式，而是采用以下方式 ExtensionLoader的核心功能点： 扩展点

层次名 作用 Service 业务层。包括业务代码的接口与实现，即开发者实现的业务代码 config 配置层。主要围绕ServiceConfig （暴露的服务配置）和ReferenceConfig （

因为 Dubbo 线程池总数默认是固定的，200 个，假设系统在单位时间内可以处理 500 个请 求，一旦 queryOrderById 的请求流量上来了，极端情况下，可能会出现 200 个线程都在处