知道Dubbo性能为什么这么强?看完你就懂了!

前言

为什么Dubbo说自己性能高?

高性能要从底层的原理说起,既然是一个RPC框架,主要干的就是远程过程(方法)调用, 那么提升性能就要从最关键、最耗时的两个方面入手:序列化和网络通信。

序列化:我们学习 Java 网络开发的时候知道,本地的对象要在网络上传输,必须要实现Serializable 接口,也就是必须序列化。我们序列化的方案很多:xml、json、二进制流…其中效率最高的就是二进制流(因为计算机就是二进制的)。然而Dubbo采用的就是效率最高的二进制。

网络通信:不同于HTTP需要进行7步走(三次握手和四次挥手),Dubbo采用Socket通信机制,一步到位,提升了通信效率,并且可以建立长连接,不用反复连接,直接传输数据

别的RPC框架

gRPC

Thrift

HSF

Dubbo的前世今生

dubbo之前一直都作为Alibaba公司内部使用的框架。

2011年,dubbo被托管到了GitHub上(开源)

2014年11月发布2.4.11版本后宣布停止更新。此后一段时间很多公司开源了自己基于Dubbo的变种版本(例如当当网的Dubbo X,网易考拉的Dubbo K)

2017年SpringCloud横空出世Dubbo感觉到压力后连续更新了几个版本2018年1月,阿里公司联合当当网将Dubbo和Dubbo X合并,发布了2.6版本2018年除夕夜阿里将Dubbo贡献给了Apache基金会

2018除夕夜至今,Apache维护和更新Dubbo

  • 从基础开始手把手详细讲解了RPC概念,PRC在分布式应用的重要作用。
  • Dubbo分布式服务框架的应用入门基础。
  • 传统应用到分布式以及微服务的转变思想。
  • Dubbo协议的特点。
  • Dubbo分布式服务的详细开发流程、Dubbo服务的实施部署,Zookeeper的服务管理等。

dubbo 概述

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

Dubbo 是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案、服务治理方案。

特性:

面向接口代理:调用接口的方法,在A服务器调用B服务器的方法,由dubbo实现对B的调用,无需关心实现的细节,就像MyBatis 访问Dao的接口,可以操作数据库一样。不用关心 Dao接口方法的实现。这样开发是方便,舒服的。

基本架构

  • 服务提供者(Provider):暴露服务的服务提供方,服务提供者在启动时,向注册中心注册自己提供的服务。
  • 服务消费者(Consumer): 调用远程服务的服务消费方,服务消费者在启动时,向注册中心订阅自己所需的服务,服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
  • 注册中心(Registry):注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者
  • 监控中心(Monitor):服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心

调用关系说明:

  • 服务容器负责启动,加载,运行服务提供者。
  • 服务提供者在启动时,向注册中心注册自己提供的服务。
  • 服务消费者在启动时,向注册中心订阅自己所需的服务。
  • 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
  • 服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
  • 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。

Dubbo 支持的协议

支持多种协议:dubbo , hessian , rmi , http, webservice , thrift , memcached , redis。dubbo 官方推荐使用dubbo协议。dubbo协议默认端口20880

使用dubbo协议,spring配置文件加入:

<dubbo:protocol name=“dubbo” port=“20880” />

电商平台需求

某电商平台系统需求,用户浏览商品;选择商品下订单,订单系统需要获取用户信息中的送货地址;向支付系统请求完成付款。

直连方式dubbo

点对点的直连项目:消费者直接访问服务提供者,没有注册中心。消费者必须指定服务提供者的访问地址(url)。

消费者直接通过url地址访问固定的服务提供者。这个url地址是不变的。

实现目标

用户访问------>【商品网站服务】访问----->【订单服务】

实现方式

以JavaSE为例,服务提供者,服务消费者都是JavaSE项目

(1) 创建服务提供者:订单服务

A、 新建java project

项目名称:
link-orderservice-provider

设置 version为1.0.0

B、 maven pom.xml

在下的标签中加入JDK1.8编译插件

C、 创建订单实体类:Order

D、 新建订单服务接口:OrderService

E、新建接口的实现类:OrderServiceImpl

F、创建 dubbo 配置文件

orderservce-provider.xml

G、 测试配置文件

H、 安装本地jar到maven仓库

服务接口中的方法要给消费者使用,消费者项目需要知道接口名称和接口中的方法名称、参数等。这些信息服务提供者才知道。需要把接口的class文件打包为jar

服务接口项目的类文件打包为jar, 安装到maven仓库,仓库中的提供者jar可以被消费者使用。

使用IDEA的maven窗口执行install

(2) 创建服务消费者:商品网站

I、 新建java project

项目名称:link-main-web

J、 maven pom.xml

在下的标签中加入JDK1.8编译插件

K、创建购买商品接口

L、创建购买接口的实现类

M、 创建dubbo配置文件

shop-consume.xml

N、 执行消费者

Dubbo服务化最佳实践

分包

建议将服务接口、服务模型、服务异常等均放在公共包中。

粒度

服务接口尽可能大粒度,每个服务方法应代表一个功能,而不是某功能的一个步骤,服务接口建议以业务场景为单位划分,并对相近业务做抽象,防止接口数量爆炸。

不建议使用过于抽象的通用接口,如:Map query(Map),这样的接口没有明确语义,会给后期维护带来不便。

版本

每个接口都应定义版本号,区分同一接口的不同实现,如: <dubbo:service interface=“com.xxx.XxxService” version=“1.0” />。

猜你喜欢

转载自blog.csdn.net/m0_48795607/article/details/119580377