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

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

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

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

咱们大略会有如下写法：

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

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

不论 maven 如何拆分，都始终是在一个 jvm 中运行，这样只是在代码开发时会分明不便一点。然而，某一个 service 在有较大压力的状况下，没有方法单单对此 service 做出调整。最终，咱们是想要 userService 和orderService在不同的 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 框架来说，在多个机器提供同样的一个服务的时候，须要主动做出抉择。好比上图，userServuce在调用 orderService 的时候，须要自动识别集群信息，并且主动抉择机器进行调用。

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

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

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

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

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

注册核心的抉择

作为协调者的注册核心，占据着一个重要位置。这样来看，注册核心次要实现了长期数据存储的性能。能够有多种抉择 数据库、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 开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞 + 转发哦！

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

起源

RPC 框架

结束语