分布式技术原理与算法解析
聂鹏程
智载云帆 CTO,前华为分布式 Lab 资深技术专家
39663 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 43 讲
分布式技术原理与算法解析
15
15
1.0x
00:00/00:00
登录|注册

19 | 分布式通信之远程调用:我是你的千里眼

原理及应用
Apache Dubbo
原理及应用
采用更底层的网络通信协议
基于HTTP协议
远程过程调用(RPC)
本地过程调用(LPC)
异步调用
同步调用
RPC与RMI对比分析
RMI
RPC
B/S架构
远程调用
通信是必不可少的
本质是多进程协作,共同完成任务
进程间函数的相互调用
进程内函数之间的相互调用
思考题
远程过程调用存在同步和异步
分布式通信
远程调用
本地调用
如何理解远程调用的“我是你的千里眼”

该思维导图由 AI 生成,仅供参考

你好,我是聂鹏程。今天,我来继续带你打卡分布式核心技术。
在前面三个模块中,我带你学习了分布式领域中的分布式协调与同步、分布式资源管理与负载调度,以及分布式计算技术,相信你对分布式技术已经有了一定的了解。
通过前面的学习,不知道你有没有发现分布式的本质就是多进程协作,共同完成任务。要协作,自然免不了通信。那么,多个进程之间是如何通信的呢?这也就是在“第四站:分布式通信技术”模块中,我将要为你讲解的问题。
话不多说,接下来我们就一起进入分布式通信的世界吧。今天,我首先带你打卡的是,分布式通信中的远程调用。

什么是远程调用?

首先,我通过一个例子,来让你对远程调用和本地调用有一个直观了解。
以电商购物平台为例,每一笔交易都涉及订单系统、支付系统和库存系统,假设三个系统分别部署在三台机器 A、B、C 中独立运行,订单交易流程如下所示:
用户下单时,调用本地(机器 A)的订单系统进行下单;
下单完成后,会远程调用机器 B 上的支付系统进行支付,待支付完成后返回结果,之后在本地更新订单状态;
在本地远程调用机器 C 上的仓库系统出货,出货完成后返回出货结果。
在整个过程中,“下单”和“订单状态更新”两个操作属于本地调用,而“支付”和“出货”这两个操作是通过本地的订单系统调用其他两个机器上的函数(方法)实现的,属于远程调用。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

远程过程调用(RPC)是分布式系统中的重要通信方式,类似于“千里眼”,能实现不同进程之间的函数调用。本文通过电商交易系统的例子介绍了本地调用和远程调用的区别,以及RPC的原理和应用。RPC的核心原理是将远程调用的复杂过程封装起来,让用户看不到细节,使远程过程调用和调用本地服务没有太大区别。与本地调用相比,RPC的区别主要体现在调用ID和函数的映射、序列化和反序列化、以及网络传输协议等方面。文章还以Apache Dubbo为例,介绍了一个具有代表性的RPC框架,展示了RPC框架的设计思路和工作流程。通过本文,读者能够快速了解远程调用的概念、原理和应用,对分布式系统中的通信方式有了更深入的了解。 本文通过电商交易系统的例子介绍了本地调用和远程调用的区别,以及RPC的原理和应用。RPC的核心原理是将远程调用的复杂过程封装起来,让用户看不到细节,使远程过程调用和调用本地服务没有太大区别。文章还以Apache Dubbo为例,介绍了一个具有代表性的RPC框架,展示了RPC框架的设计思路和工作流程。通过本文,读者能够快速了解远程调用的概念、原理和应用,对分布式系统中的通信方式有了更深入的了解。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《分布式技术原理与算法解析》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(29)

  • 最新
  • 精选
  • cpzhao
    参考zookeeper作为注册中心时的实现。消费方缓存服务方的信息,然后向注册中心订阅服务者的信息,如果服务方有上下线可以及时通知到。并且再加一个定时刷新的兜底集中。 高可用会依赖注册中心,所以一般注册中心也不是单机运行的,一般可以用集群主备或者多主(参考集群架构那块)的方式来搞。

    作者回复: 加油,希望你通过后面的学习能获得更多收获

    2020-02-24
    8
  • lobby
    想到的就是本地缓存,然后监听变化。看见有同学说定时刷新兜底,感觉更稳妥

    作者回复: 不同的场景可以采用不同的方法,具体可结合业务场景来看

    2020-06-08
  • 任大鹏
    服务消费方本地缓存一份地址列表
    2019-11-04
    1
    10
  • 安排
    文中从n*m的通信量直接引入了服务注册中心,感觉有点牵强,是因为通信量大才引入的注册中心吗?引入之后通信量就不大了?那最大不还是有n*m个调用关系吗?文中引入的注册中心只是为了查询服务提供方地址吧?
    2019-12-18
    3
    8
  • 鱼向北游
    回问题 可以用缓存 但要解决缓存失效问题
    2019-12-03
    2
  • kylexy_0817
    终于打卡都这章,满满的干货,谢谢老师!
    2019-11-22
    2
  • 老师,请问思维导图使用什么软件画的?
    2019-11-05
    1
    2
  • Jackey
    1.抱歉想先纠个错:RPC调用过程第6步Pay写成了Par 2.思考题:没有了解过dubbo,工作中用的是Spring cloud,注册中心eureka。这里每个服务都会在本地缓存一份注册表,然后定时刷新,这样服务调用时只需要读本地缓存即可。但也引入了一些新的问题,比如缓存时间设置多久合适?太长导致更新不及时,太短则会耗费过多资源。这里是不是可以考虑注册中心“通知”各个客户端,例如引入mq,获取pub/sub。但这样会增加系统复杂度,还是要结合实际情况考虑。 3.想补充一点点rpc调用的细节,内核中会有消息缓冲区,发送消息时会把消息写到buffer中,然后发给本地网卡,读消息时也一样,需要从内核的read buffer中读。如果发送消息很大,就会有多次网络通信。
    2019-11-04
    1
    2
  • Geek_3046bc
    回复问题:可以使用zookeeper,etcd等组件来解决注册中心的实现,同时对于dubbo的设计也有一个疑问,注册中心为什么不直接转发到对应的服务节点,这样对于调用方无需理解服务列表。而且zookeeper的监听者全部收缩到注册中心上了,避免了zookeeper的性能问题。可以用多实例的方式来解决注册中心的单点的问题。
    2021-07-29
    1
  • leslie
    老师的这张图表分享的非常好:用句通俗的话语“没有对比就没有伤害",各种知识的优劣直接用图表展现就非常直观的体现了-方便记忆;毕竟学习中有些知识还是要记忆的。 记住关键的知识,然后对课程的知识勤加思考和练习;自然就掌握了。
    2019-11-06
    1
收起评论
显示
设置
留言
29
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部