Java 后端工程师必会知识点 -(分布式 RPC 框架 Dubbo)

你曾经使用过 dubbo 吗?你知道他干什么 吗?

Apache Dubbo是一个高性能、轻量、开放源代码的Java服务框架

提供了六大核心能力：面向接口代理的高性能 RPC 调用，智能容错和负载均衡，服务自动注册和发现，高度可扩展能力，运行期流量调度，可视化的服务治理与运维。其实 Dubbo 呢就是一个 RPC 框架。

你所说的是RPC

RPC（Remote Procedure Call）—远程过程调用，它是通过网络从远程计算机程序提供的一种请求服务,你不需要知道底层网络技术的协议。例如,两个不同的服务A和B在两个不同的机器上部署。那么如果服务A想调用服务B中的一种方法,它应该做些什么?当然你可以使用HTTP请求,但这可能更麻烦。RPC似乎使得调用远程方法和调用本地方法一样简单。

事实上,对于我来说,RPC的范围相当广,例如,一些简单的生产情况

• 首先我觉得很少读者公司用的 fegin 其实也算一个简单的 RPC 吧？因为它也是屏蔽了底层的调用，让我们调用远程方法像调用本地方一样的方便。

• 第二个就是我们说的 dubbo，那他跟 fegin 的一个最大的区别，我觉得就是网络传输的方式不一样，但是他也是一个 RPC 框架，并且性能更好，但是他目前不支持跨语言调用。

• 为什么 Six Six 提到了第三种thrift 呢? 当一个公司规模较大,如一家大型互联网公司,当然不同的部门使用不同的语言,那么你必须去他那里,我们有这样的服务。

你在谈论RPC的原理

• 服务消费方（client）调用以本地调用方式调用服务；

• client stub 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；

• client stub 找到服务地址，并将消息发送到服务端；

• server stub 收到消息后进行解码；

• server stub 根据解码结果调用本地的服务；

• 本地服务执行并返回结果到服务器小作品;

• 服务器stub将返回结果包装成消息并发送给消费者;

• 客户端stub接收消息并解码;

• 服务消费者得到最终的结果.

它很简单,你想知道它是什么,每个人都能理解记忆,但是你必须理解它

我们重新聊 Dubbo,你对 Dubbo 的各个模块熟悉呢？知道每个模块的作用不

• config 配置层：对外配置接口，以 ServiceConfig, ReferenceConfig 为中心，可以直接初始化配置类，也可以通过 spring 解析配置生成配置类

• proxy 服务代理层：服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy 为中心，扩展接口为 ProxyFactory

• registry 注册中心层：封装服务地址的注册与发现，以服务 URL 为中心，扩展接口为 RegistryFactory, Registry, RegistryService

• cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为 Cluster, Directory, Router, LoadBalance

• monitor 监控层：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory, Monitor, MonitorService

• protocol 远程调用层：封装 RPC 调用，以 Invocation, Result 为中心，扩展接口为 Protocol, Invoker, Exporter

• 交换信息交换层:封装请求响应模式,同步转异步，以 Request, Response 为中心，扩展的接口包括 Exchanger 、 ExchangeChannel 、 ExchangeClient 、 ExchangeServer

• transport 网络传输层：抽象 mina 和 netty 为统一接口，集中于消息,扩展接口为 Channel, Transporter, Client, Server, Codec

• serialize 数据序列化层：可复用的一些工具，扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool

谈 Dubbo建筑

杜博建筑

• 提供者: 被曝光服务的提供者

• 消费者:使用远程服务的消费者

• 注册表:服务注册表和发现注册表(一般使用zk)

• 监视:统计服务电话数目和时间的监视中心

• Container： 服务运行容器(Spring 的容器)

调用关系说明：

• 服务容器负责启动、装载和运行服务提供者。

• 服务提供者在启动时，向注册中心注册自己提供的服务。

• 服务消费者在开始服务时就订阅登记中心提供所需的服务。

• 注册处向消费者返回服务提供者地址的清单,如果发生更改,注册处根据长途连接向消费者转达更改数据。

• 服务消费者根据软负载平衡算法从提供者地址列表中选择一个提供者,如果调用失败,则选择另一个提供者。

• 服务消费者和服务提供者,在记忆中积累电话和电话时间,每分钟按一定时间向监测中心发送统计数据。

建筑设计方法对多博SPI进行交谈

对于中间设计原则,插件设计, 任何功能都可以设计.

• 协议扩展

• 调用拦截扩展

• 引用监听扩展

• 暴露监听扩展

• 集群扩展

• 路由扩展

• 负载均衡扩展

• 合并结果扩展

• 注册中心扩展

• 监控中心扩展

• 扩展点加载扩展

• 动态代理扩展

• 编译器扩展

• Dubbo配置中心扩展

• 消息派发扩展

• 线程池扩展

• 序列化扩展

• 网络传输扩展

• 信息交换扩展

• 组网扩展

• Telnet命令扩展

• 状态检查扩展

• 容器扩展

• 缓存扩展

• 验证扩展

• 日志适配扩展

事实上,我认为这是一个代码设计原则,但事实上,我们经常做生意的同时设计,高集成,低耦合。

很好,伙计,你对杜博的通讯协议怎么说?

dubbo支持不同的通信协议

• dubbo 协议默认就是走 dubbo 协议，单一长连接，进行的是 NIO 异步通信，基于 hessian 作为序列化协议。使用的场景是：传输数据量小（每次请求在 100kb 以内），但是并发量很高。

为了支持高耦合场景,一般来说,服务提供者有几个机器,但有成百上万的服务消费者,每天可能有成千上万的电话!现在最好使用长途连接,要与每一个服务消费者保持长期的联系,总共可能有100个连接。根据我们的选择模式

• rmi协议运行Java二进制序列,具有多个短连接,适合相同数量的用户和提供者,适合传输文件,并且一般较少有用。

• hessian 协议走 hessian 序列化协议，多个短连接，适用于提供者数量比消费者数量还多的情况，适用于文件的传输，一般较少用。

那么你对它的序列化协议怎么说?

dubbo支持 hession、Java二进制序列、json、SOAP文本序列和多进制序列协议。probuffer。然而, hessian是其默认的序列协议, probuffer是最快的。

为什么最快速的缓冲器

• 它使用 proto 编译器，自动进行序列化和反序列化，速度非常快，应该比 XML 和 JSON 快上了 20~100 倍；

• 它具有良好的数据压缩效果,即在序列化后具有少量数据。 由于容量小,传输的带宽和速度将得到优化。

杜博的负荷平衡策略

• Random LoadBalance(默认，基于权重的随机负载均衡机制)->随机,按权重设置随机概率。一个节点发生碰撞的可能性很高,但是,电话的数量越大, 分配就越统一.而且, 即使在概率使用权重之后.有利于动态调整提供者重量.

• RoundRobin LoadBalance->(不推荐，基于权重的轮询负载均衡机制)

• LeastActive LoadBalance->最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

• ConsistentHash LoadBalance->一致性 Hash，请求相同的参数总是发送给相同的提供者。如果你不需要随机负荷平衡,这是一个请求节点的类别,然后使用这个一致的 Hash 策略。当提供者挂钩时,原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

当你设计RPC框架时需要考虑什么

哈哈，事实上,这也是对整体的考虑,问的还是很大，早些时候,小六六写了一个简单的rpc轮,正如你可以看到,它基本上是一个简单的实现每个模块在杜布包本身。一个 Web 后端框架的轮子从处理 Http 请求【基于 Netty 的请求级 Web 服务器】 到 mvc【接口封装转发)】，然后再注射注射注射液,aop【切面】，然后到rpc(远程进程调用)和最后到orm(数据库操作)全靠自己做(简单的)轮子。

结束

事实上,有很多 Dubbo的东西,但是要深入讲，每个点都可以遵循源代码,我们以后会有机会跟随你。事实上,我认为杜博的官方文件是非常好的,不管你如何使用 dubbo,我建议大家去读读，我们需要发展很多启发性的点,我有机会向大家讲这件事。

本文由 在线网速测试 整理编辑，转载请注明出处，原文链接：https://www.wangsu123.cn/news/31514.html。