SpringCloud Alibaba系列——4Dubbo简介与应用（一）

作者 | 一起撸Java
来源 |今日头条

学习目标

1. Dubbo是什么以及它的作用
2. Dubbo与springcloud的区别
3. Dubbo与Feign的区别
4. Dubbo的使用
5. Dubbo的高级应用
6. Dubbo的集群容错机制有哪几种，默认的是什么
7. Dubbo的负载均衡算法有哪几种，默认是什么
   第1章 Dubbo简介

官网
https://dubbo.apache.org/zh/

1.1 出现的背景
当企业开始大规模的服务化以后，远程通信带来的弊端就越来越明显了。比如说

1. 服务链路变长了，如何实现对服务链路的跟踪和监控呢？
2. 服务的大规模集群使得服务之间需要依赖第三方注册中心来解决服务的发现和服务的感知问题
3. 服务通信之间的异常，需要有一种保护机制防止一个节点故障引发大规模的系统故障，所以要有容错机制
4. 服务大规模集群会是的客户端需要引入负载均衡机制实现请求分发
   而这些对于服务治理的要求，传统的RPC技术在这样的场景中显得有点力不从心，因此很多企业开始研发自己的RPC框架，比如阿里的HSF、Dubbo；京东的JSF框架、当当的dubbox、新浪的motan、蚂蚁金服的sofa等等

有技术输出能力的公司，都会研发适合自己场景的rpc框架，要么是从0到1开发，要么是基于现有的思想结合公司业务特色进行改造。而没有技术输出能力的公司，遇到服务治理的需求时，会优先选择那些比较成熟的开源框架。而Dubbo就是其中一个

1.2 Dubbo的功能

1. 面向接口代理的高性能RPC调用
2. 智能容错和负载均衡
3. 服务自动注册和发现
4. 高度可扩展能力
5. 运行期流量调度
6. 可视化的服务治理与运维。  1.3 Dubbo3介绍
   如开篇所述，Dubbo 提供了构建云原生微服务业务的一站式解决方案，可以使用 Dubbo 快速定义并发布微服务组件，同时基于 Dubbo 开箱即用的丰富特性及超强的扩展能力，构建运维整个微服务体系所需的各项服务治理能力，如 Tracing、Transaction 等，Dubbo 提供的基础能力包括：

• 服务发现
• 流式通信
• 负载均衡
• 流量治理
• …..
  Dubbo 计划提供丰富的多语言客户端实现，其中 Java、Golang 版本是当前稳定性、活跃度最好的版本，其他多语言客户端[]正在持续建设中。

自开源以来，Dubbo 就被一众大规模互联网、IT公司选型，经过多年企业实践积累了大量经验。Dubbo3 是站在巨人肩膀上的下一代产品，它汲取了上一代的优点并针对已知问题做了大量优化，因此，Dubbo 在解决业务落地与规模化实践方面有着无可比拟的优势：

1.开箱即用

• 易用性高，如 Java 版本的面向接口代理特性能实现本地透明调用
• 功能丰富，基于原生库或轻量扩展即可实现绝大多数的微服务治理能力
  2.超大规模微服务集群实践
• 高性能的跨进程通信协议
• 地址发现、流量治理层面，轻松支持百万规模集群实例
  3.企业级微服务治理能力
• 服务测试
• 服务Mock
  Dubbo3 是在云原生背景下诞生的，使用 Dubbo 构建的微服务遵循云原生思想，能更好地复用底层云原生基础设施、贴合云原生微服务架构。这体现在：
• 服务支持部署在容器、Kubernetes平台，服务生命周期可实现与平台调度周期对齐；
• 支持经典 Service Mesh 微服务架构，引入了 Proxyless Mesh 架构，进一步简化 Mesh 的落地与迁移成本，提供更灵活的选择；
• 作为桥接层，支持与 SpringCloud、gRPC 等异构微服务体系的互调互通
  1.4 Dubbo架构
  1.4.1 服务发现
  服务发现，即消费端自动发现服务地址列表的能力，是微服务框架需要具备的关键能力，借助于自动化的服务发现，微服务之间可以在无需感知对端部署位置与 IP 地址的情况下实现通信。

实现服务发现的方式有很多种，Dubbo 提供的是一种 Client-Based 的服务发现机制，通常还需要部署额外的第三方注册中心组件来协调服务发现过程，如常用的 Nacos、Consul、Zookeeper 等，Dubbo 自身也提供了对多种注册中心组件的对接，用户可以灵活选择。

Dubbo 基于消费端的自动服务发现能力，其基本工作原理如下图：1.4.2 部署架构
了解 Dubbo 的三大中心化组件，它们各自的职责、工作方式。

作为一个微服务框架，Dubbo sdk 跟随着微服务组件被部署在分布式集群各个位置，为了在分布式环境下实现各个微服务组件间的协作， Dubbo 定义了一些中心化组件，这包括：

1.注册中心。协调 Consumer 与 Provider 之间的地址注册与发现

2.配置中心。

• 存储 Dubbo 启动阶段的全局配置，保证配置的跨环境共享与全局一致性
• 负责服务治理规则（路由规则、动态配置等）的存储与推送。
  3.元数据中心。
• 接收 Provider 上报的服务接口元数据，为 Admin 等控制台提供运维能力（如服务测试、接口文档等）
• 作为服务发现机制的补充，提供额外的接口/方法级别配置信息的同步能力，相当于注册中心的额外扩展
  上图完整地描述了 Dubbo 微服务组件与各个中心的交互过程。

以上三个中心并不是运行 Dubbo 的必要条件，用户完全可以根据自身业务情况决定只启用其中一个或多个，以达到简化部署的目的。通常情况下，所有用户都会以独立的注册中心 开始 Dubbo 服务开发，而配置中心、元数据中心则会在微服务演进的过程中逐步的按需被引入进来。

当然在 Dubbo + Mesh 的场景下，随着 Dubbo 服务注册能力的弱化，注册中心也不再是必选项，其职责开始被控制面取代。 请参见 Dubbo Mesh 方案的描述，ThinSDK 与 Proxyless Mesh。

注册中心配置中心

类比 Spring Cloud Config同元数据中心1.5 Dubbo协议

1.6 对比SpringCloud
Dubbo 的功能只是 Spring Cloud 体系的一部分。Dubbo 是 SOA 时代的产物，它的关注点主要在于服务调用，流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托Spring、Spring Boot 的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spring Cloud 是一个生态。 仅关注于服务治理的这个层面，Dubbo 优于 Spring Cloud：

• Dubbo 支持更多的协议，如：rmi、hessian、http、webservice、thrift、memcached、redis 等。
• Dubbo 使用 RPC 协议效率更高，Dubbo由于是二进制的传输，占用带宽会更少 Spring Cloud 是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大，在极端压力测试下，Dubbo 的效率会高于 Spring Cloud 效率一倍多，但RESTful比RPC更加灵活，不存在代码级别的强依赖
• Dubbo 有更强大的后台管理，Dubbo 提供的后台管理 Dubbo Admin 功能强大，提供路由规则、动态配置、访问控制、权重调节、均衡负载等诸多强大的功能。
• 可以限制某个 IP 流量的访问权限，设置不同服务器分发不同的流量权重，并且支持多种算法，利用这些功能可以在线上做服务治理、灰度发布、故障转移、流量分发等，Spring Cloud 到现在还不支持灰度发布、流量权重等功能。
• 最大的区别就是通信方式不同，Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输，配合hession序列化进行RPC调用。而SpringCloud是基于Http协议+rest接口调用远程过程的通信，相对来说，Http请求会有更大的报文，占的带宽也会更多。但是REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适，至于注重通信速度还是方便灵活性，具体情况具体考虑。
  1.7 对比Feign
  Feign是Spring Cloud提供的一个声明式的伪Http客户端，它使得调用远程服务就像调用本地服务一样简单，只需要创建一个接口并添加一个注解即可。

Nacos注册中心很好的兼容了Feign，Feign默认集成了Ribbon，所以在Nacos下使用Fegin默认就实现了负载均衡的效果。

1.Feign与Dubbo的对比

• Feign与Dubbo功能上有很多类似的地方，因为都是专注于远程调用这个动作。比如注册中心解耦、负载均衡、失败重试熔断、链路监控等。
• Dubbo除了注册中心需要进行整合，其它功能都自己实现了，而Feign大部分功能都是依赖全家桶的组件来实现的。Dubbo小而专一，专注于远程调用。而Spring全家桶而言，远程调用只是一个重要的功能而已。
  2.协议支持方面：
• Feign更加优雅简单。Feign是通过REST API实现的远程调用，基于Http传输协议，服务提供者需要对外暴露Http接口供消费者调用，服务粒度是http接口级的。通过短连接的方式进行通信，不适合高并发的访问。Feign追求的是简洁，少侵入（因为就服务端而言，在SpringCloud环境下，不需要做任何额外的操作，而Dubbo的服务端需要配置开放的Dubbo接口)。
• Dubbo方式更灵活。Dubbo是通过RPC调用实现的远程调用，支持多传输协议(Dubbo、Rmi、http、redis等等)，可以根据业务场景选择最佳的方式，非常灵活。默认的Dubbo协议：利用Netty，TCP传输，单一、异步、长连接，适合数据量小、高并发和服务提供者远远少于消费者的场景。Dubbo通过TCP长连接的方式进行通信，服务粒度是方法级的。
• 从协议层选择看，Dubbo是配置化的，更加灵活。Dubbo协议更适合小数据高并发场景。
  3.通信性能方面：
• 从通信的性能上来分析，SpringCloud的通信采用Openfeign（feign）组件。Feign基于Http传输协议，底层实现是rest。从OSI 7层模型上来看rest属于应用层。在高并发场景下性能不够理想，成为性能瓶颈（虽然他是基于Ribbon以及带有熔断机制可以防止雪崩），需要改造。具体需要改造的内容需要时再研究。
• Dubbo框架的通信协议采用RPC协议，属于传输层协议，性能上自然比rest高。提升了交互的性能，保持了长连接，高性能。Dubbo性能更好，比如支持异步调用、Netty性能更好。Dubbo主要是配置而无需改造。

使用SpringCloud整合Dubbo，正所谓是强强联合。

4.负载均衡方面：

• Feign默认使用Ribbon作为负载均衡的组件。Dubbo和Ribbon（Feign默认集成Ribbon）都支持负载均衡策略，但是Dubbo支持的更灵活。
• Dubbo和Ribbon对比：

Ribbon的负载均衡策略：随机、规则轮询、空闲策略、响应时间策略。

Dubbo的负载均衡策略：Dubbo支持4种算法，随机、权重轮询、最少活跃调用数、一致性Hash策略。而且算法里面引入权重的概念。

Dubbo可以使用路由策略，然后再进行负载均衡。

Dubbo配置的形式不仅支持代码配置，还支持Dubbo控制台灵活动态配置。

Dubbo负载均衡的算法可以精准到某个服务接口的某个方法，而Ribbon的算法是Client级别的。Ribbon需要进行全局配置，个性化配置比较麻烦。

5.容错机制方面：

• Feign默认使用Hystix作为服务熔断的组件。Hystix提供了服务降级，服务熔断，依赖隔离，监控（Hystrix Dashboard）等功能。Feign是利用熔断机制来实现容错的，与Dubbo处理的方式不一样。
• Dubbo支持多种容错策略，FailOver、FailFast、Failsafe、FailBack、Aviailable、Broadcast、Forking策略等，以及Mock。也引入了retry次数，timeout等配置参数。Dubbo自带了失败重试的功能。
  6.总结
• Dubbo支持更多功能、更灵活、支持高并发的RPC框架。
• SpringCloud全家桶里面（Feign、Ribbon、Hystrix），特点是非常方便。Ribbon、Hystrix、Feign在服务治理中，配合Spring Cloud做微服务，使用上有很多优势，社区也比较活跃，看将来更新发展。
• 业务发展影响着架构的选型，当服务数量不是很大时，使用普通的分布式RPC架构即可，当服务数量增长到一定数据，需要进行服务治理时，就需要考虑使用流式计算架构。Dubbo可以方便的做更精细化的流量调度，服务结构治理的方案成熟，适合生产上使用，虽然Dubbo是尘封后重新开启，但这并不影响其技术价值。
  如果项目对性能要求不是很严格，可以选择使用Feign，它使用起来更方便。
• 如果需要提高性能，避开基于Http方式的性能瓶颈，可以使用Dubbo。
• Dubbo Spring Cloud的出现，使得Dubbo既能够完全整合到Spring Cloud的技术栈中，享受Spring Cloud生态中的技术支持和标准化输出，又能够弥补Spring Cloud中服务治理这方面的短板。