dubbo 简介

• 目录

---

dubbo是什么

• dubbo是远程服务调用的分布式框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
• 从传统的架构转向微服务架构后，我们首先要解决的就是微服务之间的通信，可用，健壮等等问题，使其在使用上感觉就如同单体架构一般，而dubbo就是实现这一系列需求的的分布式框架。它为我们提供了通信，微服务注册等一系列的解决方案，依赖spring配置的方式不侵入我们的代码，使之对我们透明，让我们更专注于业务程序的开发。
• Dubbo框架具有极高的扩展性，主要采用{微核 + 插件}体系，并且文档齐全，很方便二次开发，适应性极强。

dubbo的核心功能

• 带着问题寻找答案，要了解dubbo做了什么，我们先要考虑分布式的微服务架构需要什么。

远程通讯

• 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
• 使微服务像调用本地方法一样高效地调用远程方法。

集群容错:

• 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

自动发现

• 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
• 不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址（同springcloud不太一样，是在注册中心绑定调用的接口与ip端口，而springcloud在注册中心绑定是微服务同ip端口），并且能够平滑添加或删除服务提供者。
• Dubbo采用全spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

注册与发现流程图

• dubbo官网中的架构图，用来描述注册与发现的流程，仅做参考
  

dubbo角色

Provider

• 暴露服务的服务提供方

Consumer

• 调用远程服务的服务消费方

Cantainer

• 服务运行容器。
  *Container模块是一个独立的容器，因为服务通常不需要Tomcat/JBoss等Web容器的特性，没必要用Web容器去加载服务。该服务容器只是一个简单的Main方法，并加载一个简单的Spring容器，用于暴露服务。

Provider

• 暴露服务的服务提供方

Registry

• 服务注册与发现的注册中心
• dubbo推荐及通用为zookeeper。zookeeper只是作为存储端记录暴露的微服务接口，具体的注册与发现机制还是由dubbo实现？

Monitor

• 统计计服务的调用次调和调用时间的监控中心
• 非必要模块，删除不影响架构运行

---

• tips: 按理说消费者也应该依赖与dubbo框架才能发现微服务吧？为什么下面没有container?

Dubbo框架设计

• Dubbo在设计实现上是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。dubbo架构一共分为十层，如图所示：
  * 如图示，左半边是提供给消费者调用的，右半边是提供给提供者调用的。中轴上二者都可以使用。

各个层次的设计要点

抄录未做深究

服务接口层（Service）：

• 与实际业务逻辑相关的，根据服务提供方和服务消费方的 业务设计对应的接口和实现。

配置层（Config）：

• 对外配置接口，以ServiceConfig和ReferenceConfig为中心，可以直接new配置类，也可以通过Spring解析配置生成配置类。

服务代理层（Proxy）：

• 服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。

服务注册层（Registry）：

• 封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory、Registry和RegistryService。可能没有服务注册中心，此时服务提供方直接暴露服务。

集群层（Cluster）：

• 封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster、Directory、Router和LoadBalance。将多个服务提供方组合为一个服务提供方，实现对服务消费方来透明，只需要与一个服务提供方进行交互。

监控层（Monitor）：

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

远程调用层（Protocol）：

• 封将RPC调用，以Invocation和Result为中心，扩展接口为Protocol、Invoker和Exporter。Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。Invoker是实体域，它是Dubbo的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。

信息交换层（Exchange）：

• 封装请求响应模式，同步转异步，以Request和Response为中心，扩展接口为Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。

网络传输层（Transport）：

• 抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server和Codec。

数据序列化层（Serialize）：

• 可复用的一些工具，扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool。

---

• 参考 https://www.jianshu.com/p/7399effb192a
• 超级建议参考 Dubbo 一篇文章就够了：从入门到实战

补充

• 不知道还要在这篇中说明什么，待补充吧。边学边记录~