异步化组件的场景选型及实现

前景概要

在我们日常的开发过程中经常会碰到无血缘关系的流水账逻辑(数据补全、通知逻辑等)，这个时候我们通常会采用异步化的方式去处理从而加快响应速度。与此同时，伴随着上下游依赖的服务变多，对应的可能也会产生一系列的问题包括不限于问题难以排查、性能难以保证等。在闲鱼也不例外：

• 补齐的串行操作（这里指串行去实现多次网络io）存在性能瓶颈，严重影响到了接口rt。

• 逻辑单元化程度不好，逻辑"自由飞翔"导致代码可读性较差，单元逻辑相关指标也难以衡量。

基于上述的描述，我们想就此抽象出一个异步化组件去解决对应的问题。那先给自己定几个小目标吧！

• 可监控：每个单元逻辑生命周期内的所有状态和行为（成功，失败，rt等关键指标）都在监控范围内。

• 容灾性: 有fallback机制，当逻辑单元内出现大量异常（通常指的是超时）的时候能堪大用。

• 零成本接入：接入使用方便，做到拆箱即用。

举个栗子

不超时场景

假设逻辑单元L有a, b, c三个任务, 执行时长分别为t1=1, t2=2, t3=3, 超时时间为4. 如图所示:

现在希望的结果是:

1. 该逻辑单元L执行时间为3

2. a任务执行成功1次耗时为1, b任务执行成功1次耗时为2, c任务执行成功1次耗时为3

超时场景

假设假设逻辑单元L有a, b, c三个任务, 执行时长分别为t1=3, t2=5, t3=6, 超时时间为4. 如图所示:

现在希望的结果是:

1. 该逻辑单元L执行时间为4

2. a任务执行成功1次耗时为3, b任务执行失败, c任务执行失败

3. b和c线程在失败后线程停止, 不继续占用线程池资源

下面所有的方案都是围绕 超时场景展开

方案之akka