Dubbo

• 
  • 调用过程解释：首先消费者启动会向注册中心拉取服务提供者的元信息，然后调用流程也是从 Proxy 开始，毕竟都需要代理才能无感知。Proxy 持有一个 Invoker 对象，调用 invoke 之后需要通过 Cluster 先从 Directory 获取所有可调用的远程服务的 Invoker 列表，如果配置了某些路由规则，比如某个接口只能调用某个节点的那就再过滤一遍 Invoker 列表。剩下的 Invoker 再通过 LoadBalance 做负载均衡选取一个。然后再经过 Filter 做一些统计什么的，再通过 Client 做数据传输，比如用 Netty 来传输。传输需要经过 Codec 接口做协议构造，再序列化。最终发往对应的服务提供者。服务提供者接收到之后也会进行 Codec 协议处理，然后反序列化后将请求扔到线程池处理。某个线程会根据请求找到对应的 Exporter ，而找到 Exporter 其实就是找到了 Invoker，但是还会有一层层 Filter，经过一层层过滤链之后最终调用实现类然后原路返回结果。

• 

  • Container:服务运行容器
  • Provider:暴露服务的服务提供方
  • Registry:服务注册与发现的注册中心
  • Consumer:调用远程服务的服务消费方
  • Monitor: 监控，统计服务的调用次数、调用时间等信息的日志服务，服务监控中心

四大组件

三大领域模型

• 是Invoker暴露和引用的主功能入口,它负责Invoker的生命周期管理

Invoker 实体域

• 是Dubbo的核心模型，其他模型都向它靠拢，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地实现，也有可能是一个远程的实现，也可能是一个集群实现。

Invocatoin 会话域

• 它持有调用过程的变量，比如方法名，参数等

两大设计原则

• 采用Microkernel（微内核）+Plugin模式，Microkernel只负责组装Plugin,Dubbo自身的功能也是通过扩展点去实现的，也就是Dubbo的所有功能点都可被用户自定义扩展所替换
• 采用URL作为配置信息的统一格式，所有扩展点都通过URL携带配置信息

声明式缓存

• 可以应用在结果不变的场景

三种结果缓存机制

• lru：服务级别的缓存，默认，默认缓存1000个结果，当缓存池满时，采用最少使用的缓存被排除的方式来更新缓存池
• threadlocal : 当前线程缓存，当多个线程对当前线程j进行某一操作时首先要查询当前线程的某个不变的信息，通过线程缓存，可有校的调高性能
• jchche ：用来桥街各种缓存实现，即第三方缓存

服务暴露延迟

• delay

服务注册中心

同一个服务注册到不同的注册中心

+

不同服务注册到不同的注册中心

同一个服务引用自不同的中心

多协议支持