最近随项目组对整个项目进行联调，在联调过程中暴露出各种问题，让我不得不开始反思，怎么样更好地去做好一件事情，譬如说在开发过程中如何保证 Web 服务的稳定性，在敏捷开发中如何降低文档维护的成本，以及如何提高多环境服务部署的效率等等。我为什么会考虑这些问题呢？通常我们都是在约定好接口后并行开发的，因此在全部接口完成以前，所有的服务都是以渐进的形式进行集成的，那么如何保证服务在集成过程中的稳定性呢？尤其当我们面对开发/测试/生产三套环境时，如何提高服务部署的效率呢？当接口发生变更的时候，如何让每一个人都知悉变化的细节，同时降低人员维护文档的成本呢？这些问题或许和你我无关，甚至这不是一个技术问题，可恰恰这是我们时常忽视的问题，我是我想要写这篇文章的一个重要原因。
代码越来越复杂
面对这种问题，尤其是当你发现，它并不是一个纯粹的技术问题的时候。选择一件你喜欢的事情的去做，固然可以令你开心；而选择一件你不喜欢的事情去做，则可以令你成长。我们每一个人都不是人类学家，可生命中 80%的时间都在研究人类。当你接收到一条别人的讯息时，不管这个讯息本身或对或错，在生而为人的角色预设中，你都必须去提供一个响应，甚至是比对方期望更高的一个响应。可是服务器会返回 403、404 或者 500 甚至更多的状态码，人生有时候并没有机会去选择 Plan B 或者 Plan C。所以，即使所面临境地再艰难，能不能勇敢地再去尝试一次，说服对方或者选择妥协，就像一段代码被修改得面目全非，可人类本来就是喜欢皆大欢喜的动物，总希望别人都认认真真，而自己则马马虎虎，因为“认真你就输了”，有谁喜欢输呢？
好了，现在假设我们有这样一个业务场景，我们需要调用一个 WebAPI 来获取数据，然后对这些数据做相关处理。这个 API 接口被设计为返回 JSON 数据，因此，这个“简单”的业务场景通过以下代码来实现：
def extract(url):
text = requests.get(url).content.decode('utf-8')
json_data = json.loads(text)
data = json_data['raw_data']
return data
这个代码非常简单吧！可是过了十天半个月，每次解析 JSON 数据的时候随机出现异常，经验丰富的同事建议增加 try…except，并在捕获到异常以后返回 None。于是，extract()方法被修改为：
def extract(url):
text = requests.get(url).content.decode('utf-8')
try:
json_data = json.loads(text)
data = json_data['raw_data']
return data
except Exception:
print("JSON数据无效，重试！")
return None
修改后的代码，果然比修改前稳定啦，可是负责后续流程的同事开始抱怨，现在代码中出现大量判断返回值是否为 None 的代码片段，甚至在 Web API 返回正确结果的情况下，依然会返回 None，为此，机智的同事再次修改代码如下：
def extract(url):
text = requests.get(url).content.decode('utf-8')
try:
json_data = json.loads(text)
data = json_data['raw_data']
return data
except Exception:
print("JSON数据无效，重试！")
return extract(url)
可以预见的是，使用递归可能会导致递归的深度问题，假如调用者传入一个错误的 URL，将导致这里无限递归下去，于是考虑限制重试的次数；增加重试次数的限制以后，发现每次重试需要有一个时间间隔……更不必说要在这里增加日志记录，以及在特定场景下需要将异常抛出，由此可见这段简单的代码会变得越来越复杂，如下所示：
def extract(url):
text = requests.get(url).content.decode('utf-8')
try:
json_data = json.loads(text)
data = json_data['raw_data']
return data
except Exception:
for i in range(3):
print('正在进行第{0}次重试'.format(str(i))
result = extract(url)
if(result!=None):
return result
可以注意到，这是一个非常合理的代码演进过程。在这个演进过程中，一段非常简单的代码变得越来越复杂。在我写下这篇文章前，我亲眼目睹了这种复杂的代码，是如何难以复用以及集成的，日志记录、异常处理等流程和正常流程“混合”在一起，甚至你不得不通过函数的返回值来判断是否异常，我一直在想怎么样去解决这些“corner”问题，就像人们一致认为：王垠博士擅长解决的是理想状态下的纯问题。而现实世界中存在着各种各样的“corner”问题，这或许就是学术界与工业界的区别，那么怎么样去更好地解决这一切问题呢？
应用程序重试策略
既然我们可以预见到这些问题的存在，那么，现在让我们正式切入今天这篇博客的主题，即应用程序重试策略。我们在这里以一种渐进式的方式，向大家展示了一个简单的应用程序，是如何因为异常处理变得越来越复杂的，这里我们选择重试，是因为现实世界本身存在不稳定性，即使我们现在有各种自动化工具来替代传统运维。就像有时候你怀疑是代码出现 Bug，实际上则是服务器在某一段时间内宕机，当这种事情就发生在你身边的时候，你不得不去着手解决这些“corner”问题，而这恰好是人生的无奈之处。
Try-Catch-Redo 策略
这应该是我们最容易想到的一种重试策略了，其思路是对函数的返回值和异常进行处理，其缺点是无法解决重试无效的问题。这里我们将问题简化为对异常进行处理，其基本的代码实现如下：
private void Retry()
{
try
{
var result = DoWork();
if(!result){
//重试一次
Thread.Sleep(1000);
DoWork();
}
}
catch(Exception e)
{
//重试一次
Thread.Sleep(1000);
DoWork();
}
}
可以注意到，这种策略最多可以重试一次，因此如果重试后无效，这个策略就变得毫无意义起来，我们需要寻找一种更好的方式。
Try-Catch-Redo-Retry 策略
考虑到第一种策略无法解决重试无效的问题，我们在此基础上增加对重试次数以及重试间隔的控制，这就是 Try-Catch-Redo-Retry 策略，其基本实现如下：
private void Retry()
{
//最大重试次数为5次
int times = 5;
//重试间隔为10秒
int interval = 10;
//存储异常的列表
var exceptions = new List<Exception>();
while(true)
{
try
{
var result = DoWrok();
if(result) return result;
}
catch(Exception ex)
{
if(--times<=0) throw new AggregateException(exceptions);
exceptions.Add(ex);
Thread.Sleep(TimeSpan.FromSeconds(interval));
}
}
}
可以注意到，通过 while(true)结构的确可以增加重试的次数。问题在于：如果不设置合理的循环跳出条件，就有可能造成逻辑上的死循环。尤其当循环体内的逻辑执行时间较长时，会增加用户的等待时间，这看起来亦非良策啊！
Retry-Builder 策略
Try-Catch-Redo 和 Try-Catch-Redo-Retry 这两种策略理解起来非常容易，可这两种策略都有一个致命的缺陷，即正常逻辑和重试逻辑重度耦合。我们希望采用一种更优雅的方法，以一种非侵入式的方式给正常逻辑增加重试重试逻辑。需要考虑的是，在确保重试次数和重试间隔可配置的前提下，支持自定义重试源，即可以捕捉一个或多个异常以及对返回值进行处理。在这里推荐三个框架，分别是 Java 中的Spring-Retry和Guava-Retrying、.NET 中的Polly。其中 Spring-Retry 是基于 Throwable 类型的重试机制，即针对可捕获异常执行重试策略，并提供相应的回滚策略；而 Guava-Retrying 提供了更为丰富的重试源定义，譬如多个异常或者多个返回值；而 Polly 则提供了除重试以外的断路器、超时、隔板隔离、缓存、回退等多种策略。这三者的相似之处在于，通过一个 Factory 来创建满足不同重试策略的 Retryer，然后由 Retryer 来通过回调来执行重试逻辑，我不喜欢 Java 中回调函数写法，所以这里以 Polly 为例：
try
{
var retryTwoTimesPolicy = Policy
.Handle<DivideByZeroException>()
.Retry(3, (ex, count) =>
{
Console.WriteLine("执行失败! 重试次数 {0}", count);
Console.WriteLine("异常来自 {0}", ex.GetType().Name);
});
retryTwoTimesPolicy.Execute(() =>
{
var a = 0;
var b = 1/a;
});
}
catch (DivideByZeroException e)
{
Console.WriteLine($"Excuted Failed,Message: ({e.Message})");
}
可以看到，写出一段语义化的代码是多么的重要，因为我相信大家都看懂了。这里的 Policy 承担了 RetryBuilder 的角色，它定义了这样一种策略：当程序引发 DivideByZeroException 时进行重试，重试次数为 3 次，并且以匿名函数的方式指定了重试时的回调函数；而创建的 retryTowTimesPolicy 承担了 Retryer 的角色，它通过 Execute()方法来定义要执行的重试逻辑。当 3 次都重试失败时就会引发 DivideByZeroException 并在最外层函数中被捕捉到。我经常听到有人说设计模式没有用，我想说因为你从来都不知道什么叫做大道至简，引入无数个中间层是无法让你直接看到代码定义，可计算机领域里有一句名言，“任何一个问题都可以通过引入一个中间层来得到解决”。
装饰器/AOP 策略
我从来不惮于将各种重复的工作自动化，这并不是我喜欢在别人面前炫技，而是因为在现实生活中我是一个懒惰的人，甚至是每天早上 10 点开站会这样的事情，我都愿意让计算机程序去提前通知我做好准备。我并不是一个不懂得自律的人，仅仅是因为我觉得我们可以用这个时间去做些别的事情。AOP 是一种可以在运行时期间动态修改代码的技术，我们自然可以想到给所有的函数都加上异常处理和重试的特性，幸运的是 Python 中的有这样一个第三方库：Tenacity，它可以帮助我们优雅地实现重试：
from tenacity import retry
from json.decoder import JSONDecodeError
@retry(retry=retry_if_exception_type(JSONDecodeError), wait=wait_fixed(5), stop=stop_after_attempt(3))
def extract(url):
text = requests.get(url).content.decode('utf-8')
json_data = json.loads(text)
data = json_data['raw_data']
return data
通过@retry 这个装饰器函数，我们就可以知道，这里设计的重试策略是：当引发 JSONDecodeError 这个异常时，每隔 5 秒中重试一次，最大重试次数为 3 次。Python 中的装饰器，本质上就是高阶函数的概念，修饰器函数对被修饰函数进行“操作”后返回一个新的函数，这个特性在.NET 中可以通过委托/匿名方法/lambda 来实现，结合 Unity、AspectCore 等 AOP 框架，相信大家完全可以将这个特性移植到.NET 中来，当语言的差别变得微乎其微的时候，原理的重要性不言而喻。
重试策略核心理念
好了，截止到目前，我们分析了四种不同的重试策略，并且这四种重试策略是随着我们认知的加深而逐渐递进的。那么，通过这四种不同的重试策略，我们能否梳理出一个相对完整的应用程序重试策略呢？换言之，当为应用程序增加重试相关的功能时，我们都需要考虑哪些因素，因为使用这些框架会是非常简单的过程，而更重要的则是我们逐步演进的思考过程。当我们所依赖的是一个不稳定的场景，譬如远程调用、数据加载、数据上传等场景时，或者是在异常场景中需要重试以满足业务稳定性的要求等等，就可以考虑使用重试策略。这里简单地做一下梳理：
- 重试逻辑与正常逻辑解耦，整个设计是非侵入式的。
- 支持自定义策略，譬如重试次数、重试间隔、重试源、重试超时时间等。
- 支持自定义断言，即可以使用 Predict或者类似表达式来定义返回值满足的条件。
- 支持多种异常，即可以针对特定的 Exception 或者自定义的 Exception 进行拦截。
- 断言实例和异常实例，作为正常逻辑和重试逻辑两者间的媒介进行交互。
- 通过命令模式，由 Retryer 对象完成对正常逻辑的调用，同时在内部封装重试逻辑。
一个简单的 Retry 实现
好了，熟悉我写作风格的朋友，一定知道我不喜欢空泛地讲一套理论，我更喜欢通过“造轮子”的这种方式，以加深对一个事物或者原理的认识。对于今天这篇文章，我的初衷是想告诉大家如何优雅地去实现 Retry，因为在现实中我们总会遇到各种各样的枷锁，这些枷锁约束着你写出糟糕的代码，我们比别人用心甚至更努力，反而常常被认为是有代码洁癖或者是炫技，可不管怎么样，人生是我们自己的，如果没有办法说服别人在项目中使用这些技术，那我们就在项目以外的地方去使用，或者是告诉别人我们有一种相对优雅的设计，如果这个设计恰好对别人有用，对我们来说就是一种莫大的幸福。参考 Polly 的 API 风格，这个 Retry 被我设计成了下面的样子：
try
{
var result = Retry.Default
.Times(3)
.Interval(2)
.Catch<DivideByZeroException>()
.Reject((count,ex)=>
{
var message = string.format("第{0}次重试，异常来自:{1}", count, ex.Message);
Trace.WriteLine(message);
})
.Execute<int>(()=>
{
var m = 0;
return 3 / m;
});
}
catch(Exeption ex)
{
Trace.WriteLine(ex.Message);
}
我承认它和 Polly 非常地像，不过我并没有去看 Polly 是如何实现的，目前它的实现完全来自这篇文章中我们提到的这些策略。我在为它增加了针对返回值的断言支持，通过 Return 方法来实现，而对异常的支持则是通过 Catch 方法来实现，除此以外，它支持异步方法调用，我们熟悉的 Task/async/await 这些 API 都可以使用。目前它还是一个玩具儿，因为我发现最难的部分，其实是断言或者说自定义表达式的设计，对于线程安全相关的问题，我会在慢慢地去完善它，如果你对它感兴趣的话，可以通过这里访问：RetryIt。好了，感谢大家关注我的博客，今天这篇先写到这里啦，欢迎大家在博客中留言！