首先感激王晓老师的 [接口优化的常见计划实战总结] 一文总结，凑巧最近在对持重理财 BFF 层聚合查问服务优化治理，针对文章内的串行改并行章节进行开展，分享下实践经验，次要波及原同步改异步的过程、全异步化后衍生的问题以及治理方面的思考与改良。
心愿通过分享这些教训，可能对大家的工作有所启发和帮忙。如果有任何问题或倡议，请随时提出。
一、问题背景
将不同理财产品（如基金、券商、保险、银行理财等）针对不同投放渠道人群进行个性化商品举荐，每个渠道或人群看到的商品或个性数据又各不相同，为不便渠道疾速对接，由 BFF 层对立对所有数据进行聚合下发，因而 BFF 层汇集依赖了大量底层原子服务，所以次要问题是在依赖大量上游接口的场景下保障 TP99、以及可用率。
案例：
以其中比拟典型的商品举荐接口为例，须要依赖本地商品池缓存、算法举荐服务、商品根底信息服务、持仓查问服务、人群标签服务、券配置服务，可领用券服务、其余数据服务 ServN……等等，其中大部分上游原子接口对单次批量查问反对无限，所以极其状况，单个推品接口单次举荐 1 - n 个推品，每个商品如果要绑定 10 个动静属性，至多须要发动(1~n)*10 次 io 调用。
革新前的流程和问题：
流程：
问题：
- 一是逻辑流程强耦合，很多上下游服务强同步依赖；
- 二是链路较长，其中某个上游服务不稳固时很容易造成整体链路失败。
革新后的流程和实现的指标：
流程：
指标：
- 革新指标也很明确，就是对现有逻辑革新，尽可能减少弱依赖比例，一是不便异步提前加载，二是弱依赖代表可摘除，为降级操作奠定根底，缩小因某个链路抖动影响整体链路失败；
初步革新后的新问题【【重点解决】】：
▪逻辑上解耦比较简单，无非就是前置参数或冗余加载，本次不开展探讨；
▪技术上革新后期异步逻辑次要是采纳 @Async(“tpXXX”)标注，这也是最快捷实现的形式，但也存在以下几个问题，次要是波及治理方面：
- 随着我的项目和人员一直迭代，造成 @Async 注解满天飞；
- 不同人员在不相熟其余模块的状况下，无奈界定不同线程池的是否可专用，大多都会采纳申明新的线程池，造成线程池资源泛滥；
- 局部调用场景不合理造成 @Async 嵌套过多或注解生效问题；
- 降级机制反复代码太多，须要频繁手动申明各种降级开关；
- 短少对立的申请级别的缓存机制，尽管 jsf 曾经提供了肯定水平的反对；
- 线程池上下文传递问题；
- 短少线程池状态的对立监控报警，无奈观测理论运行过程中的每个线程池状态，可能每次都是拍脑袋觉设置线程池参数。
二、整体革新门路
切入点：
鉴于大部分我的项目都会封装独自的 io 调用层，比方 com.xx.package.xxx.client，所以以此为切入点进行重点革新治理。
最终目标：
实现、利用简略，对老代码革新敌对，尽可能升高革新老本；
- 形象 io 调用模板，对立 io 调用层封装标准，标准化 io 调用须要的加强属性申明并提供默认配置，如所属线程池调配、超时、缓存、熔断、降级等；
- 优化 @Async 调用，所有 io 异步操作对立膨胀至 io 调用层，在模板层实现回调机制，老代码仅继承模板即可实现异步回调;
- 申请级别的缓存实现，默认反对 r2m;
- 申请级别的熔断降级反对，在上游故障时使服务实现肯定水平的自治理；
- 线程池集中管理，对上下文主动传递 MDC 参数提供反对；
- 线程池状态主动可视化监控、报警实现；
- 反对配置核心动静设置。
具体实现：
1. io 调用形象模板
模板次要作用是进行标准和加强，目前提供两种模板，默认模板、缓存模板，核心思想就是对 io 操作波及的大部分行为进行申明，比方以后服务所属线程池分组、申请分组等，由委托组件依照申明的属性进行加强实现，示例如下：
次要是提供代码级别的默认申明，从日常实际看大部分采纳开发时的代码级别的配置即可。
2. 委托代理
此委托属于整个执行过程的桥接实现，io 封装实现继承形象模板后，由模板创立委托代理实例，次要用于对 io 封装进行加强实现，比方调用前、调用后、以及调用失败主动调用申明的降级办法等解决。
能够了解为：模板专一申请行为，委托关注对象行为进行组合加强。
3. 执行器选型
基于后面的实现目标，缩小自研老本，调研目前已有框架，如 hystrix、sentinel、resilience4j，因为次要目标是冀望反对线程池级别的壁舱模式实现，且 hystrix 集成度要优于 resilience4j，最终选型默认集成 hystrix，备选 resilience4j，以此实现线程池的动态创建治理、熔断降级、半连贯重试等机制，HystrixCommander 实现如下：
4. hystrix 适配 concrete 动静配置
1、继承 concrete.PropertiesNotifier, 注册 HystrixPropertiesNotifier 监听器，缓存配置核心所有以 hystrix 起始的 key 配置；
2、实现 HystrixDynamicProperties，注册 ConcreteHystrixDynamicProperties 替换默认实现，最终反对所有的 hystrix 配置项，具体用法参考 hystrix 文档。
5. hystrix 线程池上下文传递革新
hystrix 曾经提供了革新点，次要是对 HystrixConcurrencyStrategy#wrapCallable 办法重写实现即可，在 submit 工作前暂存主线程上下文进行传递。
6. hystrix、jsf、spring 注册线程池状态多维可视化监控、报警
次要依赖以下三个自定义组件，注册一个状态监控处理器，独自启动一个线程，定期 (每秒) 收集所有实现数据上报模板的实例，通过指定的通道实现状态数据推送，目前默认应用 PFinder 上报：
- ThreadPoolMonitorHandler 定义一个线程状态监控处理器，定期执行上报过程；
- ThreadPoolEndpointMetrics 定义要上报的数据模板，包含利用实例、线程类型（spring、jsf、hystrix……）、类型线程分组、以及线程池的几个外围参数；
- AbstractThreadPoolMetricsPublisher 定义监控处理器执行上报时依赖的通道（Micrometer、PFinder、UMP……）。
例如以下是 hystrix 的状态收集实现，最终可实现基于机房、分组、实例、线程池类型、名称等不同维度的状态监控：
PFinder 实际效果：反对不同维度组合查看及报警
7. 提供对立 await future 工具类
因为大部分调用是基于列表模式的异步后果 List<Future<T>>、Map<String,Future<T>>，并且 hystrix 目前暂不反对返回 CompletableFuture，不便对立 await，提供工具类：
8. 其余小性能
1、除了 sgm traceId 反对，同时内置自定义的 traceId 实现，次要是解决 sgm 在子线程内打印 traceId 须要在控制台手动增加监控办法的问题以及提供对局部无 sgm 环境的链路 Id 反对，不便日志跟踪；
2、比方针对 jsf 调用，基于 jsf 过滤器实现跨利用级别的前后申请 id 传递反对；
3、默认减少 jsf 过滤器实现日志打印，同时反对 provider、consume 的动静日志打印开关，不便线上随时开关 jsf 日志，不再须要在 client 层反复 logger.isDebugerEnabled()；
4、代理层主动上报 io 调用办法、fallback 等信息至 ump，不便监控报警。
日常应用示例：
1. 一个最简略的 io 调用封装
仅减少继承即可反对异步回调，不重写线程池分组时应用默认分组。
2. 一个反对申请级别熔断的 io 调用封装
默认反对的熔断级别是服务级别，老服务仅须要继承原申请参数，实现 FallbackRequest 接口即可，可避免因为某一个非凡参数引起的整体接口熔断。
3. 一个反对申请级别缓存、接口级别熔断降级、独立线程池的 io 调用封装
4. 下层调用，实际效果
1、间接将一个商品列表转换成一个异步属性绑定工作；
2、利用工具类 await List<Future<T>>；
3、在下层无感知的状态下，实现线程池的治理、熔断、降级、或缓存逻辑的加强，且可依据 pfinder 监控的可视化线程池状态，通过 concrete 实时调整线程池及超时或熔断参数；
4、举例：比方某接口频繁 500ms 超时，可通过配置间接关上短路返回降级后果，或者调低超时为 100ms，疾速触发熔断，默认 10s 内申请总数达到 20 个，50% 失败时关上断路器，每隔 5s 半链接重试。
三、最初
本篇次要是思考如何依赖现有框架、环境的能力，从代码层面系统化的实现相干治理标准。
最初仍援用王晓老师文章结尾来完结
接口性能问题造成的起因思考我置信很多接口的效率问题不是久而久之造成的，在需要迭代的过程中，为了需要疾速上线，采取间接累加代码的形式去实现性能，这样会造成以上这些接口性能问题。变换思路，更高一级思考问题，站在接口设计者的角度去开发需要，会防止很多这样的问题，也是降本增效的一种卓有成效的形式。以上，共勉！
作者：京东科技 刘大朋
起源：京东云开发者社区