14 | 优雅启动：如何避免流量打到没有启动完成的节点？
何小锋
该思维导图由 AI 生成，仅供参考
你好，我是何小锋。上一讲我们介绍了优雅停机，就是为了让服务提供方在停机应用的时候，保证所有调用方都能“安全”地切走流量，不再调用自己，从而做到对业务无损。其中实现的关键点就在于，让正在停机的服务提供方应用有状态，让调用方感知到服务提供方正在停机。
接着上一讲的内容，今天我们来聊聊优雅启动。
是不是很诧异？应用启动居然也要这么“讲究”吗？这就好比我们日常生活中的热车，行驶之前让发动机空跑一会，可以让汽车的各个部件都“热”起来，减小磨损。
换到应用上来看，原理也是一样的。运行了一段时间后的应用，执行速度会比刚启动的应用更快。这是因为在 Java 里面，在运行过程中，JVM 虚拟机会把高频的代码编译成机器码，被加载过的类也会被缓存到 JVM 缓存中，再次使用的时候不会触发临时加载，这样就使得“热点”代码的执行不用每次都通过解释，从而提升执行速度。
但是这些“临时数据”，都在我们应用重启后就消失了。重启后的这些“红利”没有了之后，如果让我们刚启动的应用就承担像停机前一样的流量，这会使应用在启动之初就处于高负载状态，从而导致调用方过来的请求可能出现大面积超时，进而对线上业务产生损害行为。
在上一讲我们说过，在微服务架构里面，上线肯定是频繁发生的，那我们总不能因为上线，就让过来的请求出现大面积超时吧？所以我们得想点办法。既然问题的关键是在于“刚重启的服务提供方因为没有预跑就承担了大流量”，那我们是不是可以通过某些方法，让应用一开始只接少许流量呢？这样低功率运行一段时间后，再逐渐提升至最佳状态。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了在微服务架构中如何通过启动预热功能来解决服务提供方应用冷启动的问题，避免在启动初期就承担大流量导致的高负载状态，从而实现平滑上线。文章首先解释了应用启动后的“热点”代码执行速度更快的原理，然后详细介绍了启动预热的概念和实现方法，包括通过负载均衡算法控制调用方发送到服务提供方的流量，并且提出了解决大批量重启服务提供方可能出现的问题的观点。此外，文章还提到了与热启动息息相关的另一个重点——延迟暴露。通过实际案例和技术原理，深入浅出地介绍了如何通过启动预热功能解决微服务架构中的启动问题，对于需要了解微服务架构优雅启动的读者具有一定的参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《RPC 实战与核心原理》，新⼈⾸单¥59
《RPC 实战与核心原理》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(30)
- 最新
- 精选
Darren如果是大批量重启，可以通过： 1、分时分批启动，就和灰度发布一样； 2、在请求低峰把，在热点的应用肯定是有使用低峰的； 3、如果必须同时大批量重启，为了保证服务的可用性，可以在低峰时期，限流，为PLUS服务，非PLUS的就提醒暂时不可用之类的友好提示。 暂时就能想到这么多，请老师指点作者回复: 分批次启动很重要
2020-03-20230
小可1.启动时逐步增加流量 2.等服务资源完全启动完成，再去注册服务 3.最好在注册前预热jvm，比如提前加载业务缓存作者回复: 是的，尽量延迟注册时机
2020-03-2910
武装到牙齿串行重启啊，明知道留下的机器顶不住流量，硬生生的给同时强制重启肯定不行啊作者回复: 是的，速度很重要。但也可以通过在调用方那边快速加权重到新启动的实例上
2020-03-205
吴小智重要的还是减少大批量重启服务的情况，应该滚动升级，逐步替代。作者回复: 👍
2020-03-205
每天晒白牙确实有这个问题，我们在上线服务提供方时，重启的并行度会控制在比较低的状态，比如只并行2台，避免发生大量请求打到未重启的服务提供方上作者回复: 需要容量预估，才好控制并发
2020-03-203
dancer感谢老师的分享，文中举的例子是基于服务先关闭再启动的情况。像K8s这种先启动一定数量新实例再关闭旧实例的发布流程，我们在关闭和启动时要注意哪些问呢作者回复: 从单个实例角度出发，是一样的
2020-05-082
波波老师，延迟暴露那个hook具体怎么实现，如何确定资源加载完毕了呢？作者回复: hook就是一个接口，可以让使用者注入具体实现
2020-03-2531
陈国林控制发布的步长，类似K8s里面的Deployment的RollingUpgrade，滚动升级保证有足够的服务在抗流量作者回复: 是的，控制速度很重要
2020-03-231
桂冠远航优雅启动确实优雅关闭一样重要。作者回复: 是的
2020-03-221
高源老师请教个问题，socket客户端和服务端通讯，开始时间同步后，跑业务跑了一段时间后，后来发现日志客户端发出和服务端接收时间差了2秒，客户端有超时设置超了2秒就报警了，这是怎么解决啊，偶尔出现现象作者回复: 看看是否有tcp重传
2020-03-201
收起评论
