07 | 远程服务调用（上）：从本地方法到远程方法的桥梁

周志明

你好，我是周志明。从今天这一讲开始，我们就进入了课程的第二个模块：架构师的视角。
“架构师”这个词，其实指向非常宽泛，你可以说做企业战略设计的是架构师，也可以说做业务流程分析的是架构师。而在这门课程中，我所针对的架构师视角，特指软件系统中技术模型的系统设计者。在这个模块当中，我会带你系统性地了解，在做架构设计的时候，架构师都应该思考哪些问题、可以选择哪些主流的解决方案和行业标准做法，以及这些主流方案都有什么优缺点、会给架构设计带来什么影响，等等。
理解了架构师的这些职责，你对“架构设计”这种听起来就很抽象的工作，是不是有个更具体的认识了？
从今天开始，我会花两讲的时间，和你一起学习“远程服务调用（Remote Procedure Call，RPC）”这个话题。我会尽可能地从根源到现状、从表现到本质，为你解释清楚 RPC 的一些常见的问题。
那今天，我们就先从“什么是 RPC”开始，一起去学习“远程服务”这个构建分布式系统的最基本的前置条件，看看它是如何出现、如何发展的，以及当前业界的主流实现手段。
其实，RPC 这个词儿在计算机科学中已经有超过 40 年的历史了，肯定不是一个新概念。但是直到今天，我们还是会在知乎等网站上，看到很多人提问“什么是 RPC？”“如何评价某某 RPC 技术？”“RPC 好还是 REST 好？”，仍然“每天”都有新的不同形状的 RPC 轮子被发明出来，仍然有层出不穷的文章，去比对 Google gRPC、Facebook Thrift 等各个厂家的 RPC 技术的优劣。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

远程服务调用（RPC）是构建分布式系统的基本前提条件。本文从RPC的起源、概念和发展出发，介绍了RPC的历史、发展和当前主流实现手段。文章首先讲解了本地方法调用的过程，然后探讨了进程间通讯的几种解决办法，包括管道、信号、信号量、消息队列、共享内存和本地套接字接口。通过这些解决办法，读者可以了解到RPC的基本概念和其在分布式系统中的重要性。文章还介绍了RPC的定义，即RPC是一种语言级别的通讯协议，允许程序在一台计算机上通过某种管道调用另一台计算机上的程序。此外，文章还掏出了RPC发展中的一些分歧和挑战，以及RPC与IPC的关系。最后，文章提出了一个引人深思的问题：远程方法调用是否应该无视通讯成本。这一问题在现代软件系统开发中具有重要意义。通过简洁的语言和具体的例子，本文帮助读者快速了解RPC的基本原理和实现方式，为进一步深入学习和应用RPC技术打下基础。

该试读文章来自《周志明的软件架构课》，如需阅读全部文章，
请先领取课程

免费领取

登录后留言

全部留言(25)

最新
精选

J.Smile
老师擅长把技术的来龙去脉，历史演进梳理的很清楚，对于工程师来说，这种行文思路确实让人醍醐灌顶。期待后文！（感觉后边可以整理成纸质书，哈哈）
作者回复: 感谢认可。其实是先把纸质书全文写好了之后，再做的音频稿。极客时间的编辑MM花了很大力气将纸质书的书面语改写成第一人称的口语的。
2020-12-02
4
72
刘智恒
老师对于IPC socket的讲解解答了我很长时间以来对本地使用RPC况下效率问题的疑惑。一直以来都是在golang语言下使用gRPC。包括在本地process交互的情况下也会使用gRPC做IPC. 我感觉gRPC的设计理念就是面向简单，尽可能的把RPC包装成本地调用的形式。我还想确认的一个问题是，在IPC场景下，gRPC如果不会经过打包，解包等过程，与共享内存，消息队列等IPC方式比起来会有显著的效率差异吗？差异的原因主要是哪些？
作者回复: 这里列的IPC方式，最快的显然是共享内存了。 IPC Socket虽然不用经过网络栈，但是还有另一个重要开销是socket接口实现在OS的内核空间中的，用户进程要使用它，就无可避免地在收和发会涉及到从用户空间向内核空间复制数据，以及反过来的两次复制过程。如果用共享内存就不会涉及到这方面问题，完全的zero-copy。现在一些对通讯性能敏感的场景，譬如sidecar与服务的通讯，都会将ipc socket改造为share memory作为一种可考虑的方式。
2020-12-02
2
47
Monday
dubbo的rpc，spring cloud的restful 我一直没弄清楚socket与restful的区别，服务不都是要经过网络吗？tcp/ip
作者回复: socket是一种来源自于BSD，目前被所有操作系统采用的网络接口，它与下层协议无关（但一般下层就只有TCP和UDPl了）。 restful是一种架构（或者狭义一点，接口设计）风格。这两者其实并没有太多可比性。
2020-12-10
3
14
zhanyd
让计算机能够跟调用本地方法一样，去调用远程方法，是应该RPC的终极目标。但是目前的技术水平无法实现这一终极目标，所以就有了其他更可行的折中方案。事物是慢慢演化发展的，目标可以远大，但是做事还得根据实际情况实事求是。
作者回复: 同意。这门课程从放弃了UNIX设计哲学、放弃了透明的RPC开始，到重拾“透明与简单”的服务网格为结束，最大的一条主线就是从本地到分布式演进过程中，对通讯的思维、视角变化
2020-12-03

11
Mr.Chen
听大神的课像追剧一样，容易上瘾！
作者回复: 感谢认可
2020-12-08

6
奔跑的蜗牛
老师什么时候出书呀
作者回复: 进入排版印刷阶段了，应该也许大概在6月吧。 https://icyfenix.cn/introduction/about-book.html
2021-04-26

5
tt
“远程方法不应该无视通讯成本”这个观点，从性能的角度来看是有益的，但从简单的角度看则是有害的。 ------------------------------ 来自“原始时代的声音”：从简单的角度来看确实是有害的，作为经常使用C语言socket的人，和使用某种RPC框架的人，在底层网络出问题进行排查的时候，有时无法对话：我：收到了一个RST。对方：我用的是流。
作者回复: 对。可惜在很长一段时间里，分布式都放弃了“简单性是接口第一属性”的原则。
2020-12-02
2
1
蓝蓝
请问老师，那个八宗罪是反话吗？意思是IPC忽略了通讯成本，以为那八宗罪是正确的？那边有点看不太懂
作者回复: 当然是反话呀
2020-12-16
3

Demon.Lee
到时买一本纸质书留着纪念，如果有老师的签名就更好了😁
作者回复: 感谢支持
2020-12-10


华仔
老师在架构历史中讲过，计算机从单体到分布式的发展，是被动需要满足不断扩大复杂化系统的需求，但是云原生和serverless追求的是让开发者不需要感知这种复杂性就能开发应用，也即是一种透明；但是在本文中RPC的发展说明了追求透明的失败。我理解说明RPC的发展还没有到能够透明的阶段，过早的追求透明了，未来随着网络带宽、低延迟，计算机软件框架的演进，RPC还是会追求透明的。
2021-06-29

2

收起评论