大家好，我是mikechen。

Dubbo是非常重要的分布式中间件，也是微服务的核心框架，而且大厂也特别喜欢考察Dubbo，下面我就全面来详解Dubbo@mikechen

本篇已收于mikechen原创超30万字《阿里架构师进阶专题合集》里面。

Dubbo

Dubbo是一个Java RPC框架，致力于分布式、高性能、透明化的远程服务调用方案。

Dubbo核心功能，主要提供了：远程方法调用、智能容错和负载均衡、提供服务自动注册、自动发现等高效服务治理功能。

为什么需要Dubbo

比如早期一个应用Java War包，将所有功能都打包，部署在一个单机服务器，调用接口也比较方便，不涉及到任何分布式场景。

随着业务的快速发展，业务越来越多、子系统也越来越多时。比如：淘宝的交易系统、商品系统、用户系统、评价系统…上百个系统的出现。

系统变得越来越复杂，业务代码依然耦合在一起。比如最早期的淘宝denali工程，包含所有业务系统的代码，就仅打包部署都需要很长的时间。

并且，随着每个业务线的快速发展，业务代码耦合在一起，上线后出现问题急需要回滚代码，拉分支、大量的代码merge工作，这个过程极其痛苦。

这个时候，你会发现技术已经成了业务的瓶颈，急需把业务单独抽离出来，各自单独部署。

应用系统一旦涉及到拆分部署，问题就来了，急需一种高效的应用程序间的通讯手段来完成这种需求，这就会涉及到分布式远程调用。

所以，RPC的框架来了，比如：Dubbo为代表的分布式远程通信RPC框架。

Dubbo核心组件

Dubbo组件如下图所示，主要包含了Dubbo框架组件：

1)服务提供者（Server）

对外提供后台服务，将自己的服务信息，注册到注册中心。

一句话总结服务提供在：暴露服务的服务提供方，称之为"服务提供者"。

2)注册中心（Registry）

注册中心：用于服务端注册远程服务以及客户端发现服务。

在微服务时代，我们所有的服务都被劲量拆分成最小的粒度，原先所有的服务都在混在1个server里，现在就被按照功能或者对象拆分成N个服务模块。

这样做的好处是深度解耦，1个模块只负责自己的事情就好，能够实现快速的迭代更新，但是坏处就是服务的管理和控制变得异常的复杂和繁琐，人工维护难度变大。

所以，这个时候急需一个组件来管控所有的服务，注册中心就出现了。

目前主要的注册中心可以借由 ：zookeeper，eureka，consul，etcd 等开源框架实现,Dubbo就是采用zookeeper注册中心。

3)服务消费者（Client）

调用远程服务的服务消费方，称之为"服务消费者"。

4)容器（container）

服务容器负责启动，加载，运行服务提供者，dubbo服务运行，也就是让生产服务的进程一直启动。

5)监控(Monitor)

为了更好的调试，发现问题，需要监控，这就需要监控中心，主要监控服务的健康情况。

Dubbo实现原理

Dubbo工作原理，主要就是分为如下几步：

第一步：启动并注册服务

服务启动的时候，Provider和Consumer根据配置信息，连接到注册中心Register，分别向注册中心注册和订阅服务。

第二步：获取服务信息

消费端从注册中心获取远程服务的注册信息，同时消费端会把服务端Provider信息缓存到本地，如果信息有变更，Consumer会收到来自注册中心的的推送。

第三步：服务消费

Consumer生成代理对象，同时根据负载均衡策略，选择一台Provider，拿到代理对象之后，Consumer通过代理对象发起接口调用。

第四步：调用接口

Provider收到请求后对数据进行反序列化，然后通过代理调用具体的接口实现。

完整的Dubbo调用流程流程，如下图所示：

Dubbo架构设计

Dubbo架构图，如下所示：

Dubbo整个架构，包含如下10层：

1. 接口层：根据服务提供方和服务消费方的业务设计对应的接口和实现；
2. 配置层：通过Spring解析配置生成配置类；
3. 代理层：主要就是生成服务的客户端代理；
4. 注册层：主要就是封装服务地址的注册与发现；
5. 集群层：主要实现多个提供者的路由、及服务负载均衡等；
6. 监控层：主要就是RPC调用次数和调用时间监控；
7. 调用层：主要就是封将RPC调用；
8. 交换层：主要就是封装请求响应模式，比如：同步转异步等；
9. 传输层：网络数据传输；
10. 序列化层：把对象序列化才能在网络进行传输。

本篇已收于mikechen原创超30万字《阿里架构师进阶专题合集》里面。

Dubbo协议

Dubbo支持dubbo、rmi、http、hessian等协议：

dubbo： 单一长连接和NIO异步通讯，适合大并发小数据量的服务调用，以及消费者远大于提供者。

rmi： 采用JDK标准的rmi协议实现，传输参数和返回参数对象需要实现Serializable接口，使用java标准序列化机制，传输协议TCP。

http： 基于Http表单提交的远程调用协议，使用Spring的HttpInvoke实现，多个短连接，传输协议HTTP。

hessian： 集成Hessian服务，基于HTTP通讯，采用Servlet暴露服务，Dubbo内嵌Jetty作为服务器时默认实现，提供与Hession服务互操作。

Dubbo官网是推荐我们使用Dubbo协议，如果没有特别的需求，也建议使用Dubbo默认协议。

Dubbo协议格式，如下图所示：

Dubbo注册中心

Dubbo有如下注册中心；

1. Multicast注册中心： Multicast注册中心不需要任何中心节点，只要广播地址，就能进行服务注册和发现。基于网络中组播传输实现；
2. Zookeeper注册中心： 基于分布式协调系统Zookeeper实现，采用Zookeeper的watch机制实现数据变更；
3. redis注册中心： 基于redis实现，采用key/Map存储，住key存储服务名和类型，Map中key存储服务URL，value服务过期时间。基于redis的发布/订阅模式通知数据变更；
4. Simple注册中心

Dubbo集群负载均衡策略

Dubbo集群提供了如下负载均衡：

1. Random LoadBalance: 随机选取提供者策略，调用次数越多，分布越均匀；
2. RoundRobin LoadBalance: 轮循选取提供者策略，平均分布，但是存在请求累积的问题；
3. LeastActive LoadBalance: 最少活跃调用策略，解决慢提供者接收更少的请求；
4. ConstantHash LoadBalance: 一致性Hash策略，使相同参数请求总是发到同一提供者；

Dubbo应用场景

1.RPC分布式服务

当网站变大后，不可避免的需要拆分应用进行服务化，这就会涉及到分布式RPC服务。

2.配置管理

当服务越来越多时，服务的URL地址信息就会爆炸式增长，配置管理变得非常困难。

3.服务依赖

当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，这个时候可以利用dubbo来梳理服务依赖。

4.服务扩容

接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？在遇到这些问题时，都可以用Dubbo来解决。

以上

本篇已收于mikechen原创超30万字《阿里架构师进阶专题合集》里面。