RPC 实战与核心原理
何小锋
京东云混合云首席架构师
40244 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 29 讲
RPC 实战与核心原理
15
15
1.0x
00:00/00:00
登录|注册

13 | 优雅关闭:如何避免服务停机带来的业务损失?

优雅启动的实现
应用容器框架Tomcat的关闭流程
优雅关闭的重要性
处理正在处理的请求
捕获关闭事件
主动通知流程
设置请求“挡板”
服务提供方通知调用方下线
服务发现的局限性
服务关闭时的情况
服务重启对调用方的影响
RPC框架
微服务架构
单体应用复杂度
课后思考
总结
优雅关闭
关闭流程问题
问题
优雅关闭

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

你好,我是何小锋。上一讲我们讲了“异常重试”,总结来说,异常重试就是为了尽最大可能保证接口可用率的一种手段,但这种策略只能用在幂等接口上,否则就会因为重试导致应用系统数据“写花”。
接着昨天的内容,今天我们再来聊聊 RPC 中的关闭流程。

关闭为什么有问题?

我们知道,在“单体应用”复杂到一定程度后,我们一般会进行系统拆分,也就是时下流行的微服务架构。服务拆分之后,自然就需要协同,于是 RPC 框架就出来了,它用来解决各个子系统之间的通信问题。
我再倒回来问你一个非常基础的问题?你觉得系统为啥非要拆分呢?从我的角度,如果只说一个原因,我觉得拆分之后我们可以更方便、更快速地迭代业务。那么问题来了,更快速地迭代业务,说人话不就是我会经常更新应用系统,时不时还老要重启服务器吗?
那具体到我们的 RPC 体系里,你就要考虑,在重启服务的过程中,RPC 怎么做到让调用方系统不出问题呢?
要想说明白这事,我们先要简述下上线的大概流程:当服务提供方要上线的时候,一般是通过部署系统完成实例重启。在这个过程中,服务提供方的团队并不会事先告诉调用方他们需要操作哪些机器,从而让调用方去事先切走流量。而对调用方来说,它也无法预测到服务提供方要对哪些机器重启上线,因此负载均衡就有可能把要正在重启的机器选出来,这样就会导致把请求发送到正在重启中的机器里面,从而导致调用方不能拿到正确的响应结果。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

在微服务架构中,服务的重启可能会对调用方业务造成影响,因此需要一种优雅的关闭流程来避免这种情况。本文讨论了RPC中的关闭流程,并提出了一种自动化方式来解决这个问题。作者首先介绍了服务重启可能导致的问题,包括调用方无法感知目标服务下线或正在关闭的情况。然后,作者提出了通过服务发现来实现自动化下线的方式,但指出了其无法完全保证实现无损上下线的问题。最后,作者提出了在服务提供方自己通知调用方下线的方式,并分析了其中可能出现的问题。文章深入浅出地解释了RPC中的关闭流程问题,并提出了解决方案,对于需要了解微服务架构中服务关闭流程的读者具有一定的参考价值。文章通过银行办理业务的类比,引出了服务提供方关闭时设置请求“挡板”的思路,以及通过捕获操作系统的进程信号来获取关闭事件的方法。同时,还介绍了如何处理正在处理的请求以及避免一直等待造成应用无法正常退出的方法。总的来说,本文对RPC中的优雅关闭流程进行了深入探讨,为读者提供了解决方案和思路。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《RPC 实战与核心原理》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(32)

  • 最新
  • 精选
  • 小罗希冀
    关闭由外到内;启动从内到外

    作者回复: 总结的太准确了

    2020-04-01
    52
  • 楼下小黑哥
    优雅启动,必须保证内部服务启动正常之后,才能接受服务调用。由于现有 RPC 一般都与 Spring 深度结合,所以需要等待 Spring 容器启动完毕之后,开始暴露服务。当内存 RPC 服务创建完成之后,才能向注册中心注册,此时就可以接受服务。

    作者回复: 👍

    2020-03-19
    3
    18
  • Jackey
    我们在启动服务时会由请求一个health check接口。这个接口会检查服务本身是否启动以及连接数据库等组件是否正常。只有检查通过才会注册到注册中心

    作者回复: 这就更稳妥了

    2020-03-18
    2
    15
  • 高源
    老师你讲的我倒是明白😊还是需要实操,或者看代码能够加深印象,知识点需要强化

    作者回复: 加油

    2020-03-18
    11
  • 🐾
    理论是看懂了、但实现的话却无从下手

    作者回复: 照着这个思路实现应该不难

    2020-03-18
    2
    7
  • Darren
    服务方万事具备后,上报信息到注册中心

    作者回复: 理解的很到位

    2020-03-18
    6
  • 忆水寒
    这一节课让我想到了socket底层的如何优雅关闭socket连接。不错!

    作者回复: 👍

    2020-04-26
    2
  • 陈国林
    1. 每个服务提供方方提供一个服务就绪探针 2. 服务调用方可以周期性调用服务提供方的就绪探针来确保服务提供方已经就绪 3. 服务端调用方通过负载均衡选出某服务节点的时候,只能从已经就绪的节点列表中选

    作者回复: 从工程角度考虑可能不是很合适,资源有的浪费

    2020-03-18
    1
  • 桂冠远航
    标题起的特别好。

    作者回复: 谢谢

    2020-03-22
  • 武装到牙齿
    启动成功,告诉注册中心,陆续加流量

    作者回复: 加流量的工作,一般都会内置在调用方逻辑里面

    2020-03-20
收起评论
显示
设置
留言
32
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部