RPC - 麻雀虽小,五脏俱全

限时加码!20+主流AI编程工具免费用 购周边加赠Coding Plan Lite,Claude Code、Cursor等即刻畅享,学习进阶更高效! 阅读详情

说起 RPC (远程过程调用),大家应该不陌生。随着微服务、分布式越来越流行,RPC 应用越来越普遍。常见的 RPC 框架如:Dubbo、gRPC、Thrift 等。本篇文章不是介绍各种 RPC 的使用和对比。而是深入剖析一个 RPC 包含哪些内容。我最近在 Hadoop 的源码,正好把 Hadoop RPC 看完了。感觉 Hadoop 的 RPC 框架设计的还是比价优秀的。Hadoop 作为大数据技术的基石,如果没有一个高性能、高可靠的 RPC 框架,很难支撑上千台服务器规模的集群。因此,本篇文章就以 Hadoop RPC 为例,介绍一个 RPC 框架会涉及的技术。

架构设计

RPC 的架构涉及客户端、网络、服务端三大组件。网络一般使用 socket ,更多的是基于现有的网络框架进行参数的设置达到最优的目的。但是客户端和服务端需要我们自己设计,并且对于分布式框架来说,设计的架构应该有高性能、高可用以及可扩展的特点。

  • 高性能:由于客户端同时发起多个请求,这就要求系统能够快速处理,降低响应延迟。也就是高吞吐、低延迟。从客户端角度来说,由于创建客户端到服务端的连接成本较高。因此可以缓存连接资源,从而实现多个客户端复用相同的连接资源,避免每个客户端都来创建而降低性能;从服务端角度来说,可以启动多线程来并发处理客户端请求。除了多线程,可以采用 Reactor 编程模式,提高多线程并发的性能。
  • 高可用:当我们的服务端挂了,能不能有备用节点继续提供服务。Hadoop 2.x 实现了 NameNode 的高可用。当客户端需要通过 RPC 调用 NameNode 服务的过程中,如果主 NameNode 宕机,那么备用 NameNode 会升级成活动节点。同时会将 RPC 的请求发送的当前活跃的 NameNode,从而继续提供可用的服务,而这个过程对客户端来说是透明的。
  • 可扩展性:一个框架需要不断地优化、不断升级。需要在架构设计时明确不变的需求点,以及可变的需求点,对于可变的需求需要能够有良好的可扩展性。以 RPC 涉及的序列化为例。由于不同序列化框架适用场景不同,因此这需要被当成可变的需求点,应该将其设计成可扩展的,能够容易地支持不同的序列化框架。目前,Hadoop RPC 支持自身的序列化框架(Writable)和 Protoc Buffer。

设计模式

设计模式更多地与上面提到的可扩展性相呼应。良好的设计模式可以提高代码复用性、增强可扩展性,同时能够降低 BUG 数量。Hadoop RPC 中涉及的设计模式比较多,大概包括:工厂模式、代理模式、适配器模式、装饰者模式和命令模式等。以代理模式为例,当客户端调用远程方法时,实际上是通过代理,将方法名和参数通过网络发送到服务端。但这个过程对客户端是透明的,对于客户端来说就像调用本地方法一样。

除了设计模式,在工程实践中还应该注意遵循常见的设计原则。

多线程

在任何一个系统中多线程都比较常见。通过多线程并发处理,提高系统的吞吐量。在 Hadoop RPC 中,客户端与服务端都用到了多线程技术。客户端开启多线程,每个线程处理一类请求,并且缓存连接资源。服务端也是多线程并发处理客户端的请求,使用 Reactor 编程模式提高并发性能。

谈到多线程就不得不提另一个话题 —— 线程安全。Hadoop RPC 中用了不少的技术来保证线程安全,包括:synchronized、concurrent并发包、atomic并发包和 nio 工具包。从优秀框架中学习线程安全,对我们以后并发编程有不少好处。

序列化与反序列化

由于 RPC 涉及数据在网络上传输,因此需要一个优秀的序列化框架,既能够高效的编码与解码,且编码后的数据大小又尽可能小。不同的序列化框架主要是在编解码效率和编码大小两个主要方面做权衡。Hadoop RPC 目前支持两种序列化框架,一个是 Hadoop 自己实现的 Writable 框架,另一个是 Protocol Buffer。Hadoop RPC 虽然支持 Writable 序列化框架,但还是以 Protocol Buffer 为主。因为 Protocol Buffer 从编解码效率和编码大小方便都是比较优秀的。当然常见的序列化包括 Avro、Kryo 等,有兴趣的读者可以查一下它们之间的性能对比。

其他

一个 RPC 框架,除了包含上面提到比较主要的方面。还有一些其他的方面

  • 语言层面:利用好 Java 语言的继承、组合、封装、多态等特性。甚至包括泛型、注解等。
  • 代码规范:良好的工程实现应该有一个良好的代码规范。在 Hadoop 中,代码风格比较统一,且每个重要的类都有详细的注释,在关键的方法或者属性上也有明确的注释。我在自己的工程中会使用阿里的 Java 代码规约插件,也会为了让自己的代码更规范。
  • 异常处理:对于一个优秀的框架异常处理很关键,什么时候需要抛出异常、抛出什么样的异常以及什么时候需要处理异常。在 RPC 中除了需要处理本地异常还要处理远程服务的异常。因此,在程序中如何优雅的处理异常也是体现一个程序员能力的地方。
  • 网络编程:RCP 中涉及的网络编程一般用 socket,Hadoop RPC 使用的 Reactor 模式的网络编程,并且 Netty 也在使用这种框架。我们有必要会用并且掌握它。

 这一段写的比较杂,想到哪写到哪。最近有跟朋友聊过在看 RPC 相关的东西,朋友说:“一个 RPC 能够涉及多少东西?值得研究?”。其实我一开始也是这样想的,无非就是客户端将请求序列化,通过网络发给服务端,服务端反序列化调用函数后再返回。但是看了 Hadoop RPC 代码后,我发现这样框架涉及的知识还是特别多的,并且还比较系统,基本上包含了我们平时编程涉及的方方面面。同时它不再是一个单机程序,而是一个 C/S 架构的程序。如果我们有兴趣还可以继续研究他的高可用,从而对分布式应用有更深入的了解。

我觉得 RPC 是麻雀虽小五脏俱全。由于它涉及了我们编程的方方面面,所以我想基于 Hadoop RPC 做一个详细的教程,把它涉及的每个重要部分都进行详细的分析,上面提到的内容基本都会涵盖。对于想了解 RPC 的读者,能够感受到一个 RPC 框架更清晰的面貌。对于仅有 Java 基础的读者来说,能够学到编写一个框架所涉及的具体编程技术,同时能够从世界顶级开源项目学到优秀设计和工程经验。

小结 

本篇文章主要介绍了 RPC 框架涉及的知识。包括:架构设计、设计模式以及设计原则、多线程并发以及线程安全、序列化框架和一些其他的内容。我觉得学习最好的方式就是从优秀的框架中学习、模仿。好比我们练书法基本都要经过临摹这一步。当然直接看别人的代码确实需求花费更多的时间和经历,并且有时候投入与产出并不成正比。所以,我想把我在 Hadoop RPC 框架中学到的优秀的设计和实现能够整理成教程,以便有兴趣的读者学习。如果有任何建议欢迎与我交流。公众号有福利

公众号「渡码」

 

如何实现一个高性能分布式 RPC 框架 RPC 框架是大型企业高频使用的一种中间件框架,用于解决分布式系统中服务之间的调用问题。RPC 框架设计很多重要的知识点,如线程模型、通信协议设计、同步/异步调用、负载均衡等,对于提高我们的技术综合能力有非常大的帮助。 市面上有较多出名的 RPC 框架,例如 Dubbo、Thrift、gRPC 等,RPC 框架本身是非常负责的,我们不可能面面俱到,而是抓住 RPC 框架的核心流程以及必备的组件,开发一个功能比较丰富的小型 RPC 框架麻雀虽小五脏俱全。 在正式开始 RPC 实战项目之前,我们先学习一下 阅读详情

相关推荐

RPC远程协议之Thrift非阻塞多线程处理

RPC远程协议之Thrift非阻塞多线程处理 在上一篇文章《RPC远程协议之Thrift入门》中,我已经介绍了Thrift的基本使用,并举例验证了如何使用,当然这个例子是阻塞单线程的模式,实际客户端请求增多,单线程处理时间变长时,无可厚非就会卡顿延迟,所以需要实现非阻塞多线程的通信模式,而Thrift已经想到,并且为我们提供好了几种Server的实现方式,以供在实际业务需求下做出合适的选择。本篇文...

云水之路的专栏 4527

有http 了,为什么还要rpc

       技术应该不是为了使用新技术而去使用,而应该是旧技术存在某些瓶颈,存在难以支撑或者扩展性越老越差等问题暴露出来之后,用新技术来进行解决。        那RPC最大的优点,或者说它相比简单的HTTP接口,它的优势、更适合它的业务场景是怎样呢?简单的HTTP又哪里不足,哪些场景明显不太适合呢?        RPC=Remote Produce Call 是一种技术的概念名词.RPC...

360linker 1217

RPC深入解析(下)

2.1 网络IO模型 有哪些网络IO模型 分为五种: 同步阻塞 IO(BIO) 同步非阻塞 IO(NIO) IO 多路复用 信号驱动IO 异步非阻塞 IO(AIO) 常用的是同步阻塞 IO 和 IO 多路复用模型。 什么是阻塞IO模型 IO多路复用 IO多路复用的实现主要有 select,poll 和 epoll 模式。 文件描述符: 在 Linux 系统中一切皆可以看成是文件,文件又可分为:普通文件、目录文件、链接文件和设备文件。 三者的区别: 基于 selec

qianxingx的博客 253

RPC多线程化

根据UNP上介绍,SUN RPC随solaris 2.4提供多线程化的服务器,通过向rpcgen传递-M参数以支持多线程。使得有rpcgen产生的服务器代码线程安全。选项-A让服务器根据处理新客户请求的需要自动创建线程。 但linux下并不支持-A选项,-M只是使rpcgen产生的代码是线程安全的,并不会自动创建线程处理请求。 测试:(rpc -M -C square.x) 服务器...

weixin_30482383的博客 548

记一次愚蠢的操作--线程安全问题

前言 只有光头才能变强。 文本已收录至我的GitHub仓库,欢迎Star:github.com/ZhongFuChen… 记一次在工作中愚蠢的操作,本文关键字:线程安全 (我怎么天天在写Bug啊) 一、交代背景 我这边有一个系统,提供一个RPC接口去发送各种信息(比如短信、邮件、微信)等等渠道。我这边的系统架构是这样的: 概括:service系统提供一个RPC接口,别人调用我提供的接口,...

weixin_30702413的博客 205

麻雀虽小五脏俱全:JSR311让Restful WebService变简单

麻雀虽小五脏俱全 ”系列---需求 公司有一个产品,包括前台WEB界面和多个后台服务,各个服务都需要在前面界面中进行配置和控制,以调整服务的行为。以前,配置文件都存放在数据库中,界面上修改配置后入库,并发送消息(Socket)通知特定的服务重新加载配置。这样有些问题,一方面自己维护Socket带来很多麻烦,二来数据库重建的时候,需要备份/恢复这些配置数据。所以,我们想把配置文件局部

思考-jinxfei 1万+

rpc调用

RPC框架原理与实现 RPC,全称 Remote Procedure Call(远程过程调用),即调用远程计算机上的服务,就像调用本地服务一样。那么RPC的原理是什么呢?了解一个技术最好的思路就是寻找一个该类型麻雀虽小五脏俱全的开源项目,不负所期,找到一个轻量级分布式 RPC 框架,本文从这个项目入手来解读RPC的原理及其实现。 其实说到RPC,大家应该不会陌生才是,以往流行的Web Serv...

u011280083的博客 833

基于Netty的RPC框架

概述 RPC(Remote Procedure Call),远程过程调用,是一个计算机通信协议,该协议允许运行一个进程调用另一个进程,而程序员无需额外为这个交互作用编程。 两个或者多个应用程序分布在不同的服务器上,他们之间的调用在客户端看来,就跟调用本地方法一样。 场景的RPC框架用阿里的dubbo、Google的gRPC,Apache的thrift、spring 的SpringCloud等。 调用流程: clientsub是客户端本地调用的代理,ServerSub是服务端的代理。 流程解释: 服务消费

qq_40837310的博客 868

良好的RPC接口设计,需要注意这些方面

RPC 框架的讨论一直是各个技术交流群中的热点话题,阿里的 dubbo,新浪微博的 motan,谷歌的 grpc,以及不久前蚂蚁金服开源的 sofa,都是比较出名的 RPC 框架RPC 框架,或者一部分人习惯称之为服务治理框架,更多的讨论是存在于其技术架构,比如 RPC 的实现原理,RPC 各个分层的意义,具体 RPC 框架的源码分析…但却并没有太多话题和“如何设计 RPC 接口”这样的业务架构...

AlbenXie的博客 751

RPC接口设计

初识 RPC 接口设计 由于 RPC 中的术每个程序员的理解可能不同,所以文章开始,先统一下 RPC,方便后续阐述。 大家都知道共享接口是 RPC 最典型的一个特点,每个服务对外暴露自己的接口,该模块一般称之为 api;外部模块想要实现对该模块的远程调用,则需要依赖其 api;每个服务都需要有一个应用来负责实现自己的 api,一般体现为一个独立的进程,该模块一般称之为 app。 api 和 app 是构建微服务项目的最简单组成部分,如果使用 maven 的多 module 组织代码,则体现为如

anthony4515的博客 2263

一篇文章了解RPC框架原理

Java面经2019-03-03 06:30:00 作者:Yasin 原文:https://blog.csdn.net/u013592964/article/details/80441205 1.RPC框架的概念 RPC(Remote Procedure Call)--远程过程调用,通过网络通信调用不同的服务,共同支撑一个软件系统,微服务实现的基石技术。使用RPC可以解耦系统,方...

u011277123的博客 433

yang模型中rpc_一篇文章了解RPC框架原理

原标题:一篇文章了解RPC框架原理1.RPC框架的概念RPC(Remote Procedure Call)–远程过程调用,通过网络通信调用不同的服务,共同支撑一个软件系统,微服务实现的基石技术。使用RPC可以解耦系统,方便维护,同时增加系统处理请求的能力。 上面是一个简单的软件系统结构,我们拆分出来用户系统和订单系统做为服务存在,让不同的站点去调用。只需要引入各个服务的接口包,在代码中调用RPC服...

weixin_39818631的博客 204

架构设计:如何实现一个高性能分布式 RPC 框架

在前面的课程中,我们由浅入深地讲解了 Netty 的基础知识和实现原理,并对 Netty 的核心源码进行了剖析,相信你已经体会到了 Netty 的强大之处。本身学习一门技术是一个比较漫长的过程,恭喜你坚持了下来。纸上得来终觉浅,绝知此事要躬行。你是不是已经迫不及待想在项目中使用 Netty 了呢?接下来我会带着你完成一个相对完整的 RPC 框架原型,帮助你加深对 Netty 的理解,希望你能亲自动手跟我一起完成它。 我先来说说,为什么要选择 RPC 框架作为实战项目。RPC 框架是大型企业高频使用的一种中间

qq_41854911的博客 1044

java 分布式rpc调用_如何实现一个分布式RPC框架

远程过程调用(Remote Procedure Call,RPC)是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序,而程序员无需额外地为这个交互作用编程。RPC的主要目标是让构建分布式应用更加容易,在提供强大的远程调用能力的同时不损失本地调用的义的简洁性。趁实习前的这段业余时间,我实现了一个轻量级的分布式RPC框架,名字叫做 buddha,代码量不大,但是麻雀虽小却...

weixin_32380501的博客 228

第五部分:从0到1实现RPC

如果你可以完成上述 RPC 框架的核心功能,那么一个简易的 RPC 框架的 MVP 原型就完成了,这也是我们实践课的目标。当然实现一个高性能高可靠的 RPC 框架并不容易,需要考虑的问题远不止如此,例如异常重试、服务级别线程池隔离、熔断限流、集群容错、优雅下线等等,在实践课最后我会为你讲解 RPC 框架进阶的拓展内容。本节课我们介绍了服务发布与订阅的实现原理,搭建出了服务提供者和服务消费者的基本框架

小小博客 1068

基于Netty的分布式 RPC 框架

转载自:http://blog.csdn.net/z69183787/article/details/52700274               http://blog.csdn.net/z69183787/article/details/52680941        采用Zookeeper、Netty和spring实现了一个轻量级的分布式RPC框架,这个RPC框架可以算是一个简易版的

ZERO 1440

设计RPC接口时,你有考虑过这些吗?

RPC 框架的讨论一直是各个技术交流群中的热点话题,阿里的 dubbo,新浪微博的 motan,谷歌的 grpc,以及不久前蚂蚁金服开源的 sofa,都是比较出名的 RPC 框架RPC ...

架构师小秘圈 314
上一篇: Flink DataStream 编程入门
下一篇: 半年技术输出的总结,继续前行
渡码
博客等级 码龄14年 31粉丝 22原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值