高并发架构系列:如何从0到1设计一个类Dubbo的RPC框架

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 在过去持续分享的几十期阿里Java面试题中,几乎每次都会问到Dubbo相关问题,比如:“如何从0到1设计一个Dubbo的RPC框架”,这个问题主要考察以下几个方面: 你对RPC框架的底层原理掌握程度。 考验你的整体RPC框架系统设计能力。本文详解~

在过去持续分享的几十期阿里Java面试题中,几乎每次都会问到Dubbo相关问题,比如:“如何从0到1设计一个Dubbo的RPC框架”,这个问题主要考察以下几个方面:

你对RPC框架的底层原理掌握程度。
考验你的整体RPC框架系统设计能力。

具体,mike来为大家详解。

RPC和RPC框架

1.RPC(Remote Procedure Call)

即远程过程调用, 主要解决远程通信间的问题,不需要了解底层网络的通信机制。

2.RPC框架

  • RPC框架负责屏蔽底层的传输方式(TCP或者UDP)、序列化方式、以及通信细节。
  • 实际使用中,并不需要关心底层通信细节和调用过程,让业务端专注于业务代码的实现。
  • 国内大家熟知的PRC框架,阿里的HSF和Dubbo(开源)

Dubbo的发展由来

1. 业务规模小

比如早期一个应用Java War包,将所有功能都打包,部署在一个单机服务器,调用接口也比较方便,不涉及到任何分布式场景。
_

2.业务规模变大

随着业务的快速发展,业务越来越多、子系统也越来越多时。比如:淘宝的交易系统、商品系统、用户系统、评价系统...上百个系统的出现。
系统变得越来越复杂,业务代码依然耦合在一起。比如最早期的淘宝denali工程,包含所有业务系统的代码,就仅打包部署都需要很长的时间。
并且,随着每个业务线的快速发展,业务代码耦合在一起,上线后出现问题急需要回滚代码,拉分支、大量的代码merge工作,这个过程极其痛苦。
这个时候,你会发现技术已经成了业务的瓶颈,急需把业务单独抽离出来,各自单独部署。

3.Dubbo和HSF的出现

应用系统一旦涉及到拆分部署,问题就来了,急需一种高效的应用程序间的通讯手段来完成这种需求,这就会涉及到分布式远程调用。

于是,淘宝就把denali按照业务为单位拆分成了类似这样的系统:UM(UserManger)、SM(ShopManager)..等等几十个工程代码。

再按照业务为单位,把所有调用相关的接口以业务为单元进行拆分;- UIC(用户中心服务)、SIC(店铺中心服务)...等等以业务为单位集群部署,按照业务提供服务。

_

所以,RPC的框架来了,阿里内部使用HSF,以及开源的RPC框架:Dubbo。

RPC框架的核心设计

前面mike提到了RPC的核心目标:主要是解决分布式系统中服务之间的调用问题。

其实,走到这一步涉及的知识体系非常的多:要求对通信、远程调用、消息机制等有深入的理解和掌握,要求的都是从理论、硬件级、操作系统级以及所采用的语言的实现都有清楚的理解。

1.RPC框架三个核心角色

PRC_

1)服务提供者(Server)
对外提供后台服务,将自己的服务信息,注册到注册中心

2)注册中心(Registry)
用于服务端注册远程服务以及客户端发现服务。
目前主要的注册中心可以借由 zookeeper,eureka,consul,etcd 等开源框架实现。
比如:阿里的Dubbo就是采用zookeeper实现注册中心。

3)服务消费者(Client)
从注册中心获取远程服务的注册信息,然后进行远程过程调用。

2.RPC远程调用过程

4

1)服务调用方(client)调用以本地调用方式调用服务;
2)client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体;在Java里就是序列化的过程
3)client stub找到服务地址,并将消息通过网络发送到服务端;
4)server stub收到消息后进行解码,在Java里就是反序列化的过程;
5)server stub根据解码结果调用本地的服务;
6)本地服务执行处理逻辑;
7)本地服务将结果返回给server stub;
8)server stub将返回结果打包成消息,Java里的序列化;
9)server stub将打包后的消息通过网络并发送至消费方
10)client stub接收到消息,并进行解码, Java里的反序列化;
11)服务调用方(client)得到最终结果。

RPC框架的目标就是要2~10这些步骤都封装起来。

RPC框架涉及技术

1.建立通信
首先,要解决通讯的问题,主要是通过在客户端和服务器之间建立TCP连接,远程过程调用的所有交换的数据都在这个连接里传输。

2.服务寻址

1)服务注册
首先需要把服务注册到服务中心。其实就是在注册中心进行一个登记,注册中心存储了该服务的IP、端口、调用方式(协议、序列化方式)等。在zookeeper中,进行服务注册,实际上就是在zookeeper中创建了一个znode节点,该节点存储了上面所说的服务信息。

2)服务发现
服务消费者在第一次调用服务时,会通过注册中心找到相应的服务的IP地址列表,并缓存到本地,以供后续使用。当消费者调用服务时,不会再去请求注册中心,而是直接通过负载均衡算法从IP列表中取一个服务提供者的服务器调用服务。

3)注册服务
可靠的寻址方式(主要是提供服务的发现)是RPC的实现基石,比如可以zookeeper来实现注册服务等等。

5

  • 服务提供者启动后主动向服务(注册)中心注册机器ip、端口以及提供的服务列表。
  • 服务消费者启动时向服务(注册)中心获取服务提供方地址列表,可实现软负载均衡和Failover。
  • 提供者需要定时向注册中心发送心跳,一段时间未收到来自提供者的心跳后,认为提供者已经停止服务,从注册中心上摘取掉对应的服务等等。

3.网络传输

数据传输采用什么协议,数据该如何序列化和反序列化。

4.NIO通信

当前很多RPC框架都直接基于netty这一IO通信框架,比如阿里巴巴的HSF、dubbo,Hadoop Avro,推荐使用Netty 作为底层通信框架。

5.服务调用

比如:B机器进行本地调用(通过代理Proxy)之后得到了返回值,此时还需要再把返回值发送回A机器,同样也需要经过序列化操作,然后再经过网络传输将二进制数据发送回A机器,而当A机器接收到这些返回值之后,则再次进行反序列化操作。

总之,要实现一个RPC不算难,难的是实现一个高性能高可靠的RPC框架,后续将结合Dubbo的实现一起再探讨。

以上就是RPC的介绍,更多Redis、Spring Cloud、MySQL数据库分库分表等高并发架构设计,具体请参考高并发架构系列专题:

_

觉得不错请点赞支持,欢迎留言或进我的个人群179961551领取【架构资料专题目合集90期】、【BATJTMD大厂JAVA面试真题1000+】,本群专用于学习交流技术、分享面试机会,拒绝广告,我也会在群内不定期答题、探讨。

往期博文:

最新拼多多技术部面试题:幻影读+分段锁+死锁+Spring Cloud+秒杀

阿里P8架构师谈:Zookeeper的原理和架构设计,以及应用场景

---------------end---------------------

相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
相关文章
|
2月前
|
缓存 NoSQL 关系型数据库
|
2月前
|
负载均衡 Dubbo Java
Dubbo 3.x:探索阿里巴巴的开源RPC框架新技术
随着微服务架构的兴起,远程过程调用(RPC)框架成为了关键组件。Dubbo,作为阿里巴巴的开源RPC框架,已经演进到了3.x版本,带来了许多新特性和技术改进。本文将探讨Dubbo 3.x中的一些最新技术,包括服务注册与发现、负载均衡、服务治理等,并通过代码示例展示其使用方式。
76 9
|
2月前
|
缓存 安全 API
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的API网关设计实现
公司对外开放的OpenAPI-Server服务,作为核心内部系统与外部系统之间的重要通讯枢纽,每天处理数百万次的API调用、亿级别的消息推送以及TB/PB级别的数据同步。经过多年流量的持续增长,该服务体系依然稳固可靠,展现出强大的负载能力。
56 9
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的API网关设计实现
|
1月前
|
程序员 Python
类的设计奥秘:从代码到架构的科普全解
类的设计奥秘:从代码到架构的科普全解
13 2
|
1月前
|
存储 消息中间件 算法
深度思考:架构师必须掌握的五大类架构设计风格
数据流风格注重数据在组件间的流动,适合处理大量数据。调用返回风格则强调函数或方法的调用与返回,过程清晰明了。独立构件风格让每个构件独立运作,通过接口交互,提升灵活性和可重用性。虚拟机风格则模拟完整系统,实现资源的高效利用。
深度思考:架构师必须掌握的五大类架构设计风格
|
1月前
|
消息中间件 缓存 API
|
2月前
|
XML JSON Java
RPC框架之Thrift—实现Go和Java远程过程调用
RPC框架之Thrift—实现Go和Java远程过程调用
46 1
|
2月前
|
存储 消息中间件 Java
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的高可靠消息服务设计实现
在深入研究了 **“【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的API网关设计实现”** 设计实现后,我们意识到,尽管API网关为服务商提供了高效的数据获取手段,但实时数据的获取仍然是一个亟待解决的问题。
39 1
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的高可靠消息服务设计实现
|
2月前
|
负载均衡 监控 Dubbo
探秘Dubbo Registry:微服务架构的核心【十二】
探秘Dubbo Registry:微服务架构的核心【十二】
24 0
|
3月前
|
XML Dubbo Java
【面试问题】Dubbo 的整体架构设计有哪些分层?
【1月更文挑战第27天】【面试问题】Dubbo 的整体架构设计有哪些分层?