【八股消消乐】构建微服务架构体系—一致性抽象

😊你好，我是小航，一个正在变秃、变强的文艺倾年。
🔔本专栏《八股消消乐》旨在记录个人所背的八股文，包括Java/Go开发、Vue开发、系统架构、大模型开发、具身智能、机器学习、深度学习、力扣算法等相关知识点，期待与你一同探索、学习、进步，一起卷起来叭！

题目

💬技术栈：微服务架构

🔍简历内容：重新设计第三方平台调用接口，提供一致性抽象，并引入客户端治理。全面接入可观测性平台，包括 Prometheus 和 Skywalking，并且配置了告警。

🚩面试问：
（1）你们公司有没有出现什么因为第三方服务不可用引发的故障？后面你们有没有设计什么改进方案？
（2）你的工作经历中有没有什么内容主要是提高同事研发效率的？如果有，你是怎么向面试官介绍这个项目并且让他相信你确实提高了研发效率的？

💡建议暂停思考10s，你有答案了嘛？如果你有不同题解，欢迎评论区留言、打卡。

答案

一致性抽象

一致性抽象会统一解决很多细节问题。比如不同的通信协议、不同的加密解密算法、不同的请求和响应格式、不同的身份认证和鉴权机制、不同的回调机制等等。

好处：

1. 研发效率大幅提高， 对于业务方来说他们不需要了解第三方的任何细节，所以他们接入一个第三方会是一件很简单的事情。
2. 高可扩展性， 你可以通过扩展接口的方式轻松接入新的第三方，而已有的业务完全不会受到影响。

提供了一致性抽象之后，你就可以在这种一致性抽象上做很多事情，比如说客户端治理。

客户端治理

一般来说，客户端治理有两个关键措施： 限流 和 重试。

限流：大部分的第三方平台 API 为了保护自己的系统，是不允许你频繁发送请求的。比如说某些银行的接口只允许你一秒钟发送十个请求，多了就会拒绝服务。那么自然地，你其实可以在你发起调用之前就开启限流，这样就可以省去一次必然失败的调用。

重试：当你调用第三方平台超时的时候，业务方肯定不希望你直接返回超时响应，因为他们还要自己处理超时，比如说发起重试等。

只有当第三方接口是幂等的时候你才能发起重试。

可观测性支持

第三方接口一般都不在你的控制范围内，所以你一定要做好监控，比如说接入 Prometheus 和SkyWalking 等工具。可观测性做得好，定位和解决问题就会变得很简单。

告警也是必不可少的。这些告警分成两类：

（1）给你和你共同维护这个功能的同事使用的。
（2）给业务方用的。

例如，当监控系统发现第三方平台突然不可用了，那么它会发出两个告警，一个是告诉你出事了；另外一个则是通知业务方第三方平台目前不稳定，那么业务方就需要确认对他们业务的影响范围，以及他们是否需要启动一些容错措施。

测试支持

测试支持的核心是你要提供 mock服务。例如正常情况下，业务方调用你的接口，你会真的调用第三方API。但是在测试环境下，你就要考虑返回mock响应。

如果第三方平台还有回调机制，并且你在收到回调之后还要通知业务方，那么你还需要模拟这个回调。比如说微信支付接口后面会回调你的一个接口，告知你支付结果。

好处：

• 没有额外开支。比如说发短信之类的，短信是收费的，那么测试服务如果能避免真的发送短信，多少也能省一点。
• 不受制于第三方平台。有些第三方平台的认证和鉴权机制非常复杂，在测试环境要发起一次调用几乎不可能，那么只能用 mock 服务。
• 你可以返回业务方任何预期的响应，包括成功响应、失败响应，甚至于你还能返回模拟第三方平台超时的响应。

简历包装

场景：系统需要和很多第三方平台打交道。所以要想保证系统的可用性，就需要保证和第三方打交道是高可用的。

前后对比

我在刚接手这个项目的时候，这一块的设计和实现不太行。总体来说可扩展性、可用性、可观测性和可测试性都非常差。为了解决这个问题，全方位提高系统的可扩展性、可用性、可观测性和可测试性，我做了比较大的重构。

1. 我重新设计了接口，提供了一个一致性抽象。（这里你可以补充你设计了哪些接口，然后强调一下效果）重构之后，研发效率提高了 30%，并且接入一个全新的第三方，也能对业务方做到完全没感知。
2. 我引入客户端治理措施，主要是限流和重试，并且针对一些特殊的第三方接口，我还设计了一些特殊的容错方案。
3. 我全方面接入了可观测性平台，包括 Prometheus 和 Skywalking，并且配置了告警。和原来比起来，现在能够做到快速响应故障了。
4. 我还进一步提供了测试工具，可以按照业务方的预期返回响应，比如说成功响应、失败响应以及模拟接口超时。针对压测，我也做了一些改进。

效果示例：

研发效率的提高：

• 重构之前：公司的 A 组要接入我们的接口，搞了大概一个星期。
• 重构之后：B 组接入我们的接口，只用了两天。而且稳定性更好，Bug 更少。

告警：

• 早期我们调用第三方接口的时候，缺乏监控和告警，以至于只有等用户出现问题联系客服的时候，或者业务方发现我们出现故障报告过来的时候，我们才知道出问题了。
• 接入了监控和告警之后，在第三方接口出问题的短时间内，就能得到通知，然后快速启动各种容错预案，并且通知业务方和第三方。

在任何跟第三方打交道的场景之下，都要考虑好第三方崩溃的时候自己的系统怎么容错。公司或者部门内部的调用出现问题了，还可以推动同事快速修复。但是第三方是推不动的，所以只能是我们调用者考虑容错。

同步转异步

在一些不需要立刻拿到响应的场景，如果你发现第三方已经崩溃了，你可以将业务方的请求临时存储起来。等后面第三方恢复了再继续调用第三方处理。这种方案一般用于对时效性要求不高的业务。比如业务方只是要求你上报数据，不要求你立刻成功，那么你就可以采用这种方案。

这种操作进一步的改进是：解耦。

这种容错机制其实完全可以做成利用消息队列来彻底解耦的形式。在这种解耦的架构下，业务方不再是同步调用一个接口，而是把消息丢到消息队列里面。然后我们的服务不断消费消息，调用第三方接口处理业务。等处理完毕再将响应通过消息队列通知业务方。

自动替换第三方

场景：我们本来有多个第三方，相互之间是可以替换的，于是我就做了一个简单的自动切换机制。当我发现第三方接口出现故障的时候，就会切换到一个新的第三方。

你怎么知道第三方出问题了？

判断服务健康与否，比如说用响应时间、错误率、超时率。那么自然可以将话题引导到熔断、降级、限流那边。

如果全部可用的第三方都崩溃了怎么办？

直接认怂就可以。因为一家出故障是小概率，多家同时出故障那就更是小概率事件了，在这种情况下你除了告警也没有别的办法了。也就是所谓的尽人事，听天命。

压测支持

正常来说，你不能指望第三方会配合你的压测。所以只能下面这三件事情：

• 模拟第三方的响应时间。例如在代码里面睡眠一段时间，这段时间是第三方接口的平均响应时间加上一个随机偏移量计算得出的。
• 模拟触发你的容错机制。如果你采用了同步转异步这种容错机制，那么你需要确保在流量很大的情况下，你确实转异步了；如果你采用的是自动切换第三方，那你也要确保真的如同你设想的那样真的切换了新的第三方。
• 流量分发。如果是在全链路压测的情况下，压测流量你会分发到 mock 逻辑，而真实业务请求你是真的调用第三方。

往期精彩专栏内容，欢迎订阅：

🔗【八股消消乐】20250615：构建微服务架构体系—链路超时控制
🔗【八股消消乐】20250614：构建微服务架构体系—实现制作库与线上库分离
🔗【八股消消乐】20250612：构建微服务架构体系—限流算法优化
🔗【八股消消乐】20250611：构建微服务架构体系—降级策略全总结
🔗【八股消消乐】20250610：构建微服务架构体系—熔断恢复抖动优化
🔗【八股消消乐】20250609：构建微服务架构体系—负载均衡算法如何优化
🔗【八股消消乐】20250608：构建微服务架构体系—服务注册与发现
🔗【八股消消乐】20250607：MySQL存储引擎InnoDB知识点汇总
🔗【八股消消乐】20250606：MySQL参数优化大汇总
🔗【八股消消乐】20250605：端午节产生的消费数据，如何分表分库？
🔗【八股消消乐】20250604：如何解决SQL线上死锁事故
🔗【八股消消乐】20250603：索引失效与优化方法总结
🔗【八股消消乐】20250512：慢SQL优化手段总结
🔗【八股消消乐】20250511：项目中如何排查内存持续上升问题
🔗【八股消消乐】20250510：项目中如何优化JVM内存分配？
🔗【八股消消乐】20250509：你在项目中如何优化垃圾回收机制？
🔗【八股消消乐】20250508：Java编译优化技术在项目中的应用
🔗【八股消消乐】20250507：你了解JVM内存模型吗？
🔗【八股消消乐】20250506：你是如何设置线程池大小？
🔗【八股消消乐】20250430：十分钟带背Duubo中大厂经典面试题
🔗【八股消消乐】20250429：你是如何在项目场景中选取最优并发容器？
🔗【八股消消乐】20250428：你是项目中如何优化多线程上下文切换？
🔗【八股消消乐】20250427：发送请求有遇到服务不可用吗？如何解决？

📌 [ 笔者 ]   文艺倾年
📃 [ 更新 ]   2025.6.15
❌ [ 勘误 ]   /* 暂无 */
📜 [ 声明 ]   由于作者水平有限，本文有错误和不准确之处在所难免，
              本人也很想知道这些错误，恳望读者批评指正！