郑州网站建设有限公司,建设电脑网站,学校微网站模板下载,物流网站建设费用#x1f60a;你好#xff0c;我是小航#xff0c;一个正在变秃、变强的文艺倾年。 #x1f514;本专栏《八股消消乐》旨在记录个人所背的八股文#xff0c;包括Java/Go开发、Vue开发、系统架构、大模型开发、具身智能、机器学习、深度学习、力扣算法等相关知识点#xff… 你好我是小航一个正在变秃、变强的文艺倾年。 本专栏《八股消消乐》旨在记录个人所背的八股文包括Java/Go开发、Vue开发、系统架构、大模型开发、具身智能、机器学习、深度学习、力扣算法等相关知识点期待与你一同探索、学习、进步一起卷起来叭 目录 题目答案一致性抽象客户端治理可观测性支持测试支持 简历包装前后对比同步转异步自动替换第三方压测支持 题目
技术栈微服务架构
简历内容重新设计第三方平台调用接口提供一致性抽象并引入客户端治理。全面接入可观测性平台包括 Prometheus 和 Skywalking并且配置了告警。
面试问 1你们公司有没有出现什么因为第三方服务不可用引发的故障后面你们有没有设计什么改进方案 2你的工作经历中有没有什么内容主要是提高同事研发效率的如果有你是怎么向面试官介绍这个项目并且让他相信你确实提高了研发效率的 建议暂停思考10s你有答案了嘛如果你有不同题解欢迎评论区留言、打卡。 答案
一致性抽象
一致性抽象会统一解决很多细节问题。比如不同的通信协议、不同的加密解密算法、不同的请求和响应格式、不同的身份认证和鉴权机制、不同的回调机制等等。
好处
研发效率大幅提高 对于业务方来说他们不需要了解第三方的任何细节所以他们接入一个第三方会是一件很简单的事情。高可扩展性 你可以通过扩展接口的方式轻松接入新的第三方而已有的业务完全不会受到影响。 提供了一致性抽象之后你就可以在这种一致性抽象上做很多事情比如说客户端治理。
客户端治理
一般来说客户端治理有两个关键措施 限流 和 重试。
限流大部分的第三方平台 API 为了保护自己的系统是不允许你频繁发送请求的。比如说某些银行的接口只允许你一秒钟发送十个请求多了就会拒绝服务。那么自然地你其实可以在你发起调用之前就开启限流这样就可以省去一次必然失败的调用。
重试当你调用第三方平台超时的时候业务方肯定不希望你直接返回超时响应因为他们还要自己处理超时比如说发起重试等。 只有当第三方接口是幂等的时候你才能发起重试。 可观测性支持
第三方接口一般都不在你的控制范围内所以你一定要做好监控比如说接入 Prometheus 和SkyWalking 等工具。可观测性做得好定位和解决问题就会变得很简单。
告警也是必不可少的。这些告警分成两类
1给你和你共同维护这个功能的同事使用的。 2给业务方用的。
例如当监控系统发现第三方平台突然不可用了那么它会发出两个告警一个是告诉你出事了另外一个则是通知业务方第三方平台目前不稳定那么业务方就需要确认对他们业务的影响范围以及他们是否需要启动一些容错措施。 测试支持
测试支持的核心是你要提供 mock服务。例如正常情况下业务方调用你的接口你会真的调用第三方API。但是在测试环境下你就要考虑返回mock响应。
如果第三方平台还有回调机制并且你在收到回调之后还要通知业务方那么你还需要模拟这个回调。比如说微信支付接口后面会回调你的一个接口告知你支付结果。
好处
没有额外开支。比如说发短信之类的短信是收费的那么测试服务如果能避免真的发送短信多少也能省一点。不受制于第三方平台。有些第三方平台的认证和鉴权机制非常复杂在测试环境要发起一次调用几乎不可能那么只能用 mock 服务。你可以返回业务方任何预期的响应包括成功响应、失败响应甚至于你还能返回模拟第三方平台超时的响应。
简历包装
场景系统需要和很多第三方平台打交道。所以要想保证系统的可用性就需要保证和第三方打交道是高可用的。
前后对比 我在刚接手这个项目的时候这一块的设计和实现不太行。总体来说可扩展性、可用性、可观测性和可测试性都非常差。为了解决这个问题全方位提高系统的可扩展性、可用性、可观测性和可测试性我做了比较大的重构。 我重新设计了接口提供了一个一致性抽象。这里你可以补充你设计了哪些接口然后强调一下效果重构之后研发效率提高了 30%并且接入一个全新的第三方也能对业务方做到完全没感知。我引入客户端治理措施主要是限流和重试并且针对一些特殊的第三方接口我还设计了一些特殊的容错方案。我全方面接入了可观测性平台包括 Prometheus 和 Skywalking并且配置了告警。和原来比起来现在能够做到快速响应故障了。我还进一步提供了测试工具可以按照业务方的预期返回响应比如说成功响应、失败响应以及模拟接口超时。针对压测我也做了一些改进。 效果示例
研发效率的提高
重构之前公司的 A 组要接入我们的接口搞了大概一个星期。重构之后B 组接入我们的接口只用了两天。而且稳定性更好Bug 更少。
告警
早期我们调用第三方接口的时候缺乏监控和告警以至于只有等用户出现问题联系客服的时候或者业务方发现我们出现故障报告过来的时候我们才知道出问题了。接入了监控和告警之后在第三方接口出问题的短时间内就能得到通知然后快速启动各种容错预案并且通知业务方和第三方。
在任何跟第三方打交道的场景之下都要考虑好第三方崩溃的时候自己的系统怎么容错。公司或者部门内部的调用出现问题了还可以推动同事快速修复。但是第三方是推不动的所以只能是我们调用者考虑容错。
同步转异步
在一些不需要立刻拿到响应的场景如果你发现第三方已经崩溃了你可以将业务方的请求临时存储起来。等后面第三方恢复了再继续调用第三方处理。这种方案一般用于对时效性要求不高的业务。比如业务方只是要求你上报数据不要求你立刻成功那么你就可以采用这种方案。 这种操作进一步的改进是解耦。
这种容错机制其实完全可以做成利用消息队列来彻底解耦的形式。在这种解耦的架构下业务方不再是同步调用一个接口而是把消息丢到消息队列里面。然后我们的服务不断消费消息调用第三方接口处理业务。等处理完毕再将响应通过消息队列通知业务方。 自动替换第三方
场景我们本来有多个第三方相互之间是可以替换的于是我就做了一个简单的自动切换机制。当我发现第三方接口出现故障的时候就会切换到一个新的第三方。 你怎么知道第三方出问题了 判断服务健康与否比如说用响应时间、错误率、超时率。那么自然可以将话题引导到熔断、降级、限流那边。 如果全部可用的第三方都崩溃了怎么办 直接认怂就可以。因为一家出故障是小概率多家同时出故障那就更是小概率事件了在这种情况下你除了告警也没有别的办法了。也就是所谓的尽人事听天命。
压测支持
正常来说你不能指望第三方会配合你的压测。所以只能下面这三件事情
模拟第三方的响应时间。例如在代码里面睡眠一段时间这段时间是第三方接口的平均响应时间加上一个随机偏移量计算得出的。模拟触发你的容错机制。如果你采用了同步转异步这种容错机制那么你需要确保在流量很大的情况下你确实转异步了如果你采用的是自动切换第三方那你也要确保真的如同你设想的那样真的切换了新的第三方。流量分发。如果是在全链路压测的情况下压测流量你会分发到 mock 逻辑而真实业务请求你是真的调用第三方。 往期精彩专栏内容欢迎订阅
【八股消消乐】20250615构建微服务架构体系—链路超时控制 【八股消消乐】20250614构建微服务架构体系—实现制作库与线上库分离 【八股消消乐】20250612构建微服务架构体系—限流算法优化 【八股消消乐】20250611构建微服务架构体系—降级策略全总结 【八股消消乐】20250610构建微服务架构体系—熔断恢复抖动优化 【八股消消乐】20250609构建微服务架构体系—负载均衡算法如何优化 【八股消消乐】20250608构建微服务架构体系—服务注册与发现 【八股消消乐】20250607MySQL存储引擎InnoDB知识点汇总 【八股消消乐】20250606MySQL参数优化大汇总 【八股消消乐】20250605端午节产生的消费数据如何分表分库 【八股消消乐】20250604如何解决SQL线上死锁事故 【八股消消乐】20250603索引失效与优化方法总结 【八股消消乐】20250512慢SQL优化手段总结 【八股消消乐】20250511项目中如何排查内存持续上升问题 【八股消消乐】20250510项目中如何优化JVM内存分配 【八股消消乐】20250509你在项目中如何优化垃圾回收机制 【八股消消乐】20250508Java编译优化技术在项目中的应用 【八股消消乐】20250507你了解JVM内存模型吗 【八股消消乐】20250506你是如何设置线程池大小 【八股消消乐】20250430十分钟带背Duubo中大厂经典面试题 【八股消消乐】20250429你是如何在项目场景中选取最优并发容器 【八股消消乐】20250428你是项目中如何优化多线程上下文切换 【八股消消乐】20250427发送请求有遇到服务不可用吗如何解决 [ 笔者 ] 文艺倾年[ 更新 ] 2025.6.15
❌ [ 勘误 ] /* 暂无 */[ 声明 ] 由于作者水平有限本文有错误和不准确之处在所难免本人也很想知道这些错误恳望读者批评指正
