Java架构直通车——Dubbo总结

之前对于Dubbo只做了点初步的了解，具体参考：Dubbo。主要是关于用法的，没有怎么去深究。

今天由于面试的需要，做一份总结吧。

什么是 Dubbo?

Apache Dubbo是一款高性能、轻量级的开源Java RPC 框架，它提供了三大核心能力： 面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现 。

简单来说 Dubbo 是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

Dubbo 的诞生和 SOA 分布式架构的流行有着莫大的关系。SOA 面向服务的架构（Service Oriented Architecture），也就是把工程按照业务逻辑拆分成 服务层、表现层 两个工程。服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。
SOA架构中有两个主要角色：服务提供者（Provider）和服务使用者（Consumer）。

RPC的原理是什么？

1. 服务消费方（client）调用以本地调用方式调用服务。客户端存根（client stub）接收到调用后负责将方法、参数等编码成能在网络中传输的消息体。然后，客户端存根找到服务地址后，将消息发送给服务端。
2. 服务提供方（server）收到序列化后的消息，就按照解码该消息。然后，根据解码结果调用本地服务，执行完毕后，将结果打包发送给消费方。
3. 服务消费方收到执行结果后，也是进行解码后得到结果。
   

既有 HTTP ,为啥用 RPC 进行服务调用?

RPC(远端过程调用)的出现就是为了解决 服务之间的调用问题，它一般会包含传输协议 和 编码协议 这两个部分。

• RPC的传输协议可以是基于Http的，也可以是基于TCP的，使用不同的传输协议一般也是为了适应不同的场景。
• 编码协议包含: 如基于文本编码的 xml json，也有二进制编码的 protobuf binpack 等。

另外，成熟的 RPC框架还提供好了“服务自动注册与发现”、“负载均衡”、“可视化的服务治理和运维”、“运行期流量调度”等等功能。

既有 HTTP ,为什么要使用自定义 tcp 协议的 rpc 做后端进程通信？

要解决这个问题就应该搞清楚 http 使用的 tcp 协议，和我们自定义的 tcp 协议在报文上的区别。

首先要否认一点 http 协议相较于自定义tcp报文协议，增加的开销在于连接的建立与断开。http协议是支持连接池复用的，也就是建立一定数量的连接不断开，并不会频繁的创建和销毁连接。另外，要说的是http也可以使用protobuf这种二进制编码协议对内容进行编码，因此二者最大的区别还是在传输内容上：

• 传输http或者tpc，就像讲普通话，好处就是谁都听得懂，谁都会讲。
• 而传输自定义的tpc，就像讲黑话，好处是可以更精简、更加保密、更加可定制，坏处就是要求“说”黑话的那一方（client端）也要懂，而且一旦大家都说一种黑话了，换黑话就困难了。

通用定义的http1.1协议的tcp报文包含太多废信息，，一个POST协议的格式大致如下：
HTTP/1.0 200 OK Content-Type: text/plainContent-Length: 137582Expires: Thu, 05 Dec 1997 16:00:00 GMTLast-Modified: Wed, 5 August 1996 15:55:28 GMTServer: Apache 0.84 Hello World
即使编码协议也就是body是使用二进制编码协议，报文元数据也就是header头的键值对却用了文本编码，非常占字节数。如上图所使用的报文中有效字节数仅仅占约 30%，也就是70%的时间用于传输元数据废编码。当然实际情况下报文内容可能会比这个长，但是报头所占的比例也是非常可观的。

为什么要用Dubbo?

如果你要开发分布式程序，你也可以直接基于 HTTP 接口进行通信，但是为什么要用 Dubbo呢？

我觉得主要可以从 Dubbo 提供的下面四点特性来说为什么要用 Dubbo：

• 负载均衡——同一个服务部署在不同的机器时该调用那一台机器上的服务。
• 服务调用链路生成——随着系统的发展，服务越来越多，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。Dubbo 可以为我们解决服务之间互相是如何调用的。
• 服务访问压力以及时长统计、资源调度和治理——基于访问压力实时管理集群容量，提高集群利用率。
• 服务降级——某个服务挂掉之后调用备用服务。

另外，Dubbo 除了能够应用在分布式系统中，也可以应用在现在比较火的微服务系统中。不过，由于 Spring Cloud 在微服务中应用更加广泛，所以，我觉得一般我们提 Dubbo 的话，大部分是分布式系统的情况。

Dubbo 的架构

• Provider： 暴露服务的服务提供方
• Consumer： 调用远程服务的服务消费方
• Registry： 服务注册与发现的注册中心
• Monitor： 统计服务的调用次数和调用时间的监控中心
• Container： 服务运行容器

使用Registry好处

Dubbo的注册中心一般使用zookeeper实现。

1. 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。
2. 注册中心，服务提供者，服务消费者三者之间均为长连接。注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者。
3. 假如注册中心宕掉，一段时间内服务消费方还是能够调用提供方的服务的，实际上它使用的本地缓存进行通讯，这只是dubbo健壮性的一种体现。
4. 服务提供者无状态，任意一台宕掉后，不影响使用。服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复。

另外，注册中心和监控中心都是可选的，服务消费者可以直连服务提供者。

Dubbo 提供的负载均衡策略

• Random LoadBalance(默认，基于权重的随机负载均衡机制)
• RoundRobin LoadBalance(不推荐，基于权重的轮询负载均衡机制)
  存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
• LeastActive LoadBalance
  使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
• ConsistentHash LoadBalance（一致性Hash）
  相同参数的请求总是发到同一提供者，当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。