11.3 Dubbo
- Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 Spring框架无缝集成。
- 是一款高性能、轻量级的开源Java RPC框架,它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。
- Dubbo文档
- Dubbo的特点:
- 基于 HTTP/2 的 Triple 协议以及面向代理 API 的编程体验。
- 强大的流量治理能力,如地址发现、负载均衡、路由选址、动态配置等。
- 多语言 SDK 实现,涵盖 Java、Golang、Javascript 等,更多语言实现将会陆续发布。
- 灵活的适配与扩展能力,可轻松与微服务体系其他组件如 Tracing、Transaction 等适配。
- Dubbo Mesh 解决方案,同时支持 Sidecar、Proxyless 等灵活的 Mesh 部署方案。
11.3.1 Dubbo 基本工作流程
- Dubbo 首先是一款 RPC 框架,它定义了自己的 RPC 通信协议与编程方式。如上图所示,用户在使用 Dubbo 时首先需要定义好 Dubbo 服务;其次,是在将 Dubbo 服务部署上线之后,依赖 Dubbo 的应用层通信协议实现数据交换,Dubbo 所传输的数据都要经过序列化,而这里的序列化协议是完全可扩展的。
- 使用 Dubbo 的第一步就是定义 Dubbo 服务,服务在 Dubbo 中的定义就是完成业务功能的一组方法的集合,可以选择使用与某种语言绑定的方式定义,如在 Java 中 Dubbo 服务就是有一组方法的 Interface 接口,也可以使用语言中立的 Protobuf Buffers IDL 定义服务。
- 定义好服务之后,服务端(Provider)需要提供服务的具体实现,并将其声明为 Dubbo 服务,而站在服务消费方(Consumer)的视角,通过调用 Dubbo 框架提供的 API 可以获得一个服务代理(stub)对象,然后就可以像使用本地服务一样对服务方法发起调用了。 在消费端对服务方法发起调用后,Dubbo 框架负责将请求发送到部署在远端机器上的服务提供方,提供方收到请求后会调用服务的实现类,之后将处理结果返回给消费端,这样就完成了一次完整的服务调用。如图中的 Request、Response 数据流程所示。
需要注意的是,在 Dubbo 中,我们提到服务时,通常是指 RPC 粒度的、提供某个具体业务增删改功能的接口或方法,与一些微服务概念书籍中泛指的服务并不是一个概念。
- 在分布式系统中,尤其是随着微服务架构的发展,应用的部署、发布、扩缩容变得极为频繁,作为 RPC 消费方,如何定动态的发现服务提供方地址成为 RPC 通信的前置条件。Dubbo 提供了自动的地址发现机制,用于应对分布式场景下机器实例动态迁移的问题。如下图所示,通过引入注册中心来协调提供方与消费方的地址,提供者启动之后向注册中心注册自身地址,消费方通过拉取或订阅注册中心特定节点,动态的感知提供方地址列表的变化。
11.3.2 角色介绍
- 注册中心(registry):是用于发布和订阅服务的一个平台。注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。用于替代SOA结构体系框架中的ESB服务总线的。
发布:开发服务端代码完毕后, 将服务信息发布出去. 实现一个服务的公开。
订阅:客户端程序,从注册中心下载服务内容 这个过程是订阅.订阅服务的时候, 会将发布的服务所有信息,一次性下载到客户端.
客户端也可以自定义, 修改部分服务配置信息. 如: 超时的时长, 调用的重试次数等.
-
服务的提供者(provider):服务的客户端.消费者必须使用Dubbo技术开发部分代码. 基本上都是配置文件定义,服务提供者在启动时,向注册中心注册自己提供的服务。
-
服务的消费者(consumer):调用远程服务的服务消费方,服务消费者在启动时,向注册中心订阅自己所需的服务,服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
-
容器(container):Dubbo技术的服务端(Provider), 在启动执行的时候, 必须依赖容器才能正常启动.默认依赖的就是spring容器. 且Dubbo技术不能脱离spring框架.
-
监控中心(monitor):是Dubbo提供的一个jar工程.主要功能是监控服务端(Provider)和消费端(Consumer)在内存中的累计使用数据的. 如: 服务端是什么,有多少接口,多少方法, 调用次数, 压力信息等. 客户端有多少, 调用过哪些服务端, 调用了多少次等.定时每分钟发送一次统计数据到监控中心
-
调用关系说明
服务容器负责启动,加载,运行服务提供者。
服务提供者在启动时,向注册中心注册自己提供的服务。
服务消费者在启动时,向注册中心订阅自己所需的服务。
注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。
11.3.4 支持协议
- Dubbo协议(官方推荐协议)
优点:采用NIO复用单一长连接,并使用线程池并发处理请求,减少握手和加大并发效率,性能较好(推荐使用)
缺点:大文件上传时,可能出现问题(不使用Dubbo文件上传)
- RMI(Remote Method Invocation)协议
优点:JDK自带的能力。可与原生RMI互操作,基于TCP协议
缺点:偶尔连接失败.
- Hessian协议
优点:可与原生Hessian互操作,基于HTTP协议
缺点:需hessian.jar支持,http短连接的开销大
11.3.5 Dubbo支持的注册中心
- Zookeeper(官方推荐)
优点:支持分布式.很多周边产品.
缺点:受限于Zookeeper软件的稳定性.Zookeeper专门分布式辅助软件,稳定较优
- Multicast
优点:去中心化,不需要单独安装软件.
缺点:Provider和Consumer和Registry不能跨机房(路由)
- Redis
优点:支持集群,性能高
缺点:要求服务器时间同步.否则可能出现集群失败问题.
- Simple
优点:标准RPC服务.没有兼容问题
缺点:不支持集群.
- Nacos:阿里