BFF层聚合查询服务异步改造及治理实践
💡
原文中文，约3800字，阅读约需10分钟。
📝
内容提要
该文章讨论了在依赖上游接口的场景下，通过改造流程和实现目标来提高系统的可用性和性能。文章提出了基于io调用层的改造治理方案，包括抽象io调用模板、优化@Async调用、请求级别的缓存和熔断降级支持、线程池集中管理、线程池状态监控报警等。文章强调了从接口设计者的角度思考问题，以避免性能问题的产生。
🎯
关键要点
- 在依赖大量上游接口的场景下，保障TP99和可用率是主要问题。
- 商品推荐接口依赖多个上游服务，导致单次推荐需要大量IO调用。
- 改造目标是增加弱依赖比例，减少链路失败的风险。
- 改造前存在逻辑流程强耦合和链路不稳定的问题。
- 改造后需解决@Async注解管理、线程池资源泛滥、降级机制重复等问题。
- 整体改造路径以IO调用层为切入点，目标是降低改造成本。
- 抽象IO调用模板，统一封装规范，提供默认配置。
- 优化@Async调用，所有异步操作统一收缩至IO调用层。
- 实现请求级别的缓存和熔断降级支持，增强服务自治能力。
- 集中管理线程池，提供状态监控和报警功能。
- 提供统一的await future工具类，方便处理异步结果。
- 通过现有框架实现治理规范，避免接口性能问题的产生。
❓
延伸问答
BFF层聚合查询服务的主要问题是什么？
主要问题是在依赖大量上游接口的场景下保障TP99和可用率。
改造BFF层的目标是什么？
改造目标是增加弱依赖比例，减少链路失败的风险，提升系统的可用性和性能。
在改造过程中遇到了哪些技术问题？
技术问题包括@Async注解管理混乱、线程池资源泛滥、降级机制重复等。
如何优化@Async调用以提高性能？
通过将所有异步操作统一收缩至IO调用层，并在模板层实现回调机制来优化@Async调用。
改造后的BFF层如何实现请求级别的缓存和熔断支持？
改造后实现请求级别的缓存和熔断降级支持，使服务具备一定的自治能力。
如何集中管理线程池以提高监控能力？
通过集中管理线程池并提供状态监控和报警功能来提高线程池的监控能力。
➡️
