关于java:Dubbo-的设计思想真优秀

27次阅读

共计 3582 个字符,预计需要花费 9 分钟才能阅读完成。

作者:叁滴水 \
博客:https://blog.csdn.net/qq_30285985/

本文来自作者「叁滴水」投稿,谢谢分享,也欢送喜好技术分享的各位技术敌人向「Java 技术栈」投稿,让更多人看到,投稿形式:关注公众号「Java 技术栈」在后盾回复:投稿。

起源

如果在一个我的项目中有两个 serviceuserServiceorderService。咱们想要其中一个 service 调用另一个。

咱们大略会有如下写法:

public class userService{
    
    private orderService orderService;
    
    public User getOrder(Long orderId){return orderService.getOrder(orderId);
    }
}

随着业务的逐步简单,在开发中必定会有业务拆分。初步是通过 maven 进行模块的拆分。

不论 maven 如何拆分,都始终是在一个 jvm 中运行,这样只是在代码开发时会分明不便一点。然而,某一个 service 在有较大压力的状况下,没有方法单单对此 service 做出调整。最终,咱们是想要 userServiceorderService在不同的 jvm 中运行,如果 orderService 拜访较多,咱们能够只对它进行扩容。

如下图,才是咱们最终想要的计划,对于这种计划,orderService端,咱们称之为 服务提供者 ,调用orderService 的端,咱们称之为 服务消费者。这种思维,也为 dubbo 的呈现埋下了伏笔。

jvm 的 userService 如何调用 orderService 呢?

在 java 近程调用多年的积淀,一个接着一个框架的呈现,在一点点的优化这个调用的过程。

首先是 socket 调用。在 orderService 中凋谢 socket 服务,在 userService 中进行近程调用。

  • 长处:解决了单机调用的问题。
  • 毛病:代码简单,不易于扩大。

这可能是最后的一个近程调用解决方案,笔者未曾遇到过纯 socket 调用的框架。

如何跨语言调用?

咱们发现,在 java 的对象是不能够间接通过 socket 进行传输的,须要有一个序列化的过程。而且 java 的默认的序列化,是无奈被其余语言解析的。这样导致如果有其余语言提供的服务,是无奈通过 java 调用。因而对于 socket 进行了降级,通过 http+xml 进行信息的传输。这就呈现了 webservice。

Web Service 技术,能使得运行在不同机器上的不同利用毋庸借助附加的、专门的第三方软件或硬件,就可相互交换数据或集成。根据 Web Service 标准施行的利用之间,无论它们所应用的语言、平台或外部协定是什么,都能够相互交换数据。

Web Service 尽管晚期很多人应用,然而到当初看来,这是一种过期的框架。因为,同样的一些数据,通过 json 会比 xml 少很多。通过 json 会更少的占用带宽。如上面数据。

{
    "id": 12312,
    "userName": "12312"
}
<id type="number">12312</id>
<userName type="string">12312</userName>

外部调用协定

http 协定是应用层的一种协定,对于凋谢给内部零碎时,是一个很好的抉择,它能够实现跨语言调用。如果是本人的 java 服务外部调用时,应用 http 协定,就有点浪费资源。

如上图,http 协定在交互之前须要进行 tcp 三次握手,握手胜利之后进行数据传输。一个 http 交互下来,有申请头、申请体、响应头、响应体。这些数据,在外部调用时,很多无关紧要的数据。兴许能够自定义协定,简化传输数据。这就呈现了 dubbo 协定,一种外部调用的协定。

dubbo 协定谋求的是 数据量小 ,小则快,协定的设计也合乎 dubbo 框框架的理念,实用与 外部 服务之间的数据交互。安全性就没有 https 做的那么好, 然而也不须要,毕竟 dubbo 协定设计的初衷就是外部应用的。

spring cloud 的 feign 组件外部应用 http 协定,外部调用可能有一些资源的节约,然而 http 协定能够实现跨语言调用。

RPC 框架

对于一个 RPC 框架来说,只是能实现近程调用,并不算完满。

个别开发一个服务须要多个机器进行部署,为了防止出现单点故障。对于一个较为欠缺的 RPC 框架来说,在多个机器提供同样的一个服务的时候,须要主动做出抉择。好比上图,userServuce在调用 orderService 的时候,须要自动识别集群信息,并且主动抉择机器进行调用。

目前,orderService只有一个服务,三台机器,兴许能够在 userServuce 中配置三个 ip,而后自行编写路由规定即可。然而随着业务的简单,机器的变动,兴许,咱们起初无奈得悉机器的 ip 信息。

为了实现动静的机器增加与移除。最终,增加了一个机器的协调者,所有凋谢服务的机器在这个协调者中增加本人的凋谢服务的信息,这个协调者中会有哪些机器凋谢了哪些服务。这样看来这个协调者相似一个 ” 通讯录 ”。咱们称这个 ” 通讯录 ” 为 注册核心

​ 这样一个较为欠缺的 RPC 框架,就有了雏形。

  1. 服务提供者启动之后向注册核心,提交本人提供服务的信息。
  2. 服务消费者,在生产时,去注册核心查问是否有机器提供对应的服务。例如调用 orderService 时,能够发现有 192.168.1.1192.168.1.2机器有提供对应的服务。消费者能够依据随机、轮训等规定抉择调用哪个服务。
  3. 在有服务上线或者下线时,注册核心能够对批改的信息进行告诉。

这样一套流程下来,就完满的实现的服务的动静部署,能够任意部署服务。

注册核心的抉择

作为协调者的注册核心,占据着一个重要位置。这样来看,注册核心次要实现了长期数据存储的性能。能够有多种抉择 数据库、redis、zookeeper、eureka、nacos、或者本人实现

期初 dubbo 框架官网举荐应用 zookeeper 为注册核心,呈现 nacos 之后,逐步从 zookeeper 转为 nacos。

其中的起因有很多,有趣味的小伙伴能够微信搜寻 Java 技术栈在历史文章中搜寻浏览。

为什么 zookeeper 转为 nacos?论断为:zookeeper 在大数据计算时做注册核心是一个好的抉择,然而在服务调用时,兴许数据不须要超强的一致性。nacos 是目前来说很敌对的一个注册核心,他提供了CP+AP。还有可视化界面,还有配置核心等性能。性能相当欠缺。

springcloud 与 dubbo 的历史

笔者不才,在 17 年时,这两个词才进入我的眼帘。过后还有一个超级火的 springboot。那个时候招聘,简直每个岗位都要求会 springboot。一时间,成为了一个 java 开发的必备功底。

因为 springboot 在大大开发了开发的速度,而且 springcloud 的各个组件都比较完善,feign、网关、配置核心、熔断等等。spring、springcloud 和 springboot 显著是一家人。这让一个孤身的 dubbo 有点不好立足,一些公司从 dubbo 框架转为 springcloud 全家桶。

2018 年 7 月份,eureka 进行更新。就目前来说 eureka 的性能单单作为注册核心,曾经足够优良了。然而对于节奏如此快的互联网时代,进行更新,就意味着会缓缓的隐没。

2019 年 7 月 24 日晚,Spring Cloud 官网发布公告 Spring Cloud Alibaba 行将毕业。提供了很多组件,对于大部分开发者而言,nacos、dubbo、seata应该是较为罕用的组件。

  • nacos:注册核心。
  • dubbo:一个基于 Java 的高性能开源 RPC 框架。
  • seata:一种高性能且易于应用的分布式事务解决方案,可用于微服务架构。

nacos是一个新推出的注册核心,其中最亮眼的性能是提供了可视化界面,而且还附带配置核心。霎时 dubbo 就找到了家人。这些组件的呈现让 dubbo 又崛起了起来。而且 dubbo 原本扩展性就很好。能够进行 协定扩大、调用拦挡扩大、援用监听扩大、集群扩大 等等。

另外 dubbo3.0 主力应用Triple 协定。残缺兼容 gRPC over HTTP/2。举荐应用 protobuf 作为默认序列化,在性能和跨语言上的成果都会更好。

结束语

就目前来看,dubbo 框架是一个目前地位十分优良的 RPC 框架,一个必须要学的一个框架。兴许当前它会更加优良,兴许会落寞。然而其设计思维,十分值得开发者去学习。

近期热文举荐:

1.1,000+ 道 Java 面试题及答案整顿(2021 最新版)

2. 终于靠开源我的项目弄到 IntelliJ IDEA 激活码了,真香!

3. 阿里 Mock 工具正式开源,干掉市面上所有 Mock 工具!

4.Spring Cloud 2020.0.0 正式公布,全新颠覆性版本!

5.《Java 开发手册(嵩山版)》最新公布,速速下载!

感觉不错,别忘了顺手点赞 + 转发哦!

正文完
 0