从gRPC的重试策略说起

本文首发在 技术成长之道 博客，访问 hechen0.com 查看更多，或者微信搜索「技术成长之道」关注我的公众号，或者扫描下方二维码关注 公众号获得第一时间更新通知！

本文让你了解

1. 重试解决什么问题

2. 短时故障的产生原因

3. 处理短时故障的挑战

4. 重试分为几步

5. gRPC是如何进行重试的

1. 重试解决什么问题

如今的互联网服务早已不是单体应用，而是由若干个模块组成的微服务，每个模块可以进行单独的扩容、缩容，独立上线部署等等；模块与模块之间通过网络进行联通。我们的应用必须对网络错误进行妥善的处理。从发生时长上而言，网络错误可以分为两类：

1. 长时间不可用，如光纤被挖断，机房被炸等

2. 短时间不可用，比如网络出现抖动，正在通信的对端机器正好重新上线等

而重试是应对短时故障利器，简单却异常有效。

2. 短时间故障的产生原因

在任何环节下应用都会有可能产生短时故障。即使是在没有网络参与的应用里，软件bug或硬件故障或一次意外断电都会造成短时故障。短时故障是常态，想做到高可用不是靠避免这些故障的发生，而是去思考短时故障发生之后的应对策略。

就互联网公司的服务而言，通过冗余，各种切换等已经极大提高了整体应用的可用性，但其内部的短时故障却是连绵不断，原因有这么几个：

1. 应用所使用的资源是共享的，比如docker、虚拟机、物理机混布等，如果多个虚拟单位(docker镜像、虚拟机、进程等)之间的资源隔离没有做好，就可能产生一个虚拟单位侵占过多资源导致其它共享的虚拟单元出现错误。这些错误可能是短时的，也有可能是长时间的。

2. 现在服务器都是用比较便宜的硬件，即使是最重要的数据库，互联网公司的通常做法也是通过冗余去保证高可用。贵和便宜的硬件之间有个很重要的指标差异就是故障率，便宜的机器更容易发生硬件故障，虽然故障率很低，但如果把这个故障率乘以互联网公司数以万计、十万计的机器，每天都会有机器故障自然是家常便饭。这里有个