原创投稿
  1. 趣知天下事首页
  2. 科技
  3. 技术

第三方服务挂了，如何保证服务不受影响？

糖太宗 • • 技术 • 阅读 33
上周有个朋友问我说：
沈老师，我们有很多服务依赖第三方接口，他们的接口不稳定，从而影响我们的服务，有没有什么方法避免？

今天和大家聊一聊这个问题。

 
首先，可以将第三方接口，收口到一个服务内。
 
这样，可以避免每个调用方都依赖于第三方服务：
（1）解除调用方与第三方接口的耦合；
（2）当第三方的接口变动时，只有服务需要修改，而不是所有调用方均修改；
 
此时，接口调用流程是什么样的呢？
第三方服务挂了，如何保证服务不受影响？
如上图1-4所述：
（1）业务调用方调用内部service；
（2）内部service跨公网调用第三方接口；
（3）第三方接口返回结果给内部service；
（4）内部service返回结果给业务调用方；
 
封装了服务之后，还存在什么潜在的问题呢？
第三方服务挂了，如何保证服务不受影响？
内部服务可能对上游业务提供了很多服务接口，当有一个接口跨公网第三方调用超时时，可能导致所有接口都不可用，即使大部分接口不依赖于跨公网第三方调用。
 
为什么会出现“一个第三方接口超时，所有接口都不可用”的情况呢？
内部服务对业务方提供的N个接口，会共用服务容器内的工作线程（假设有100个工作线程）。
假设这N个接口的某个接口跨公网依赖于第三方的接口，发生了网络抖动，或者接口超时（不妨设超时时间为5秒）。
潜台词是，这个工作线程会被占用5秒钟，然后超时返回业务调用方。
假设这个请求的吞吐量为20qps，言下之意，很短的时间内，所有的100个工作线程都会被卡在这个第三方超时等待上，而其他N-1个原本没有问题的接口，也得不到工作线程处理。
 
如何来进行优化呢？
常见的方案有三种：
（1）增大工作线程数（不根本解决问题）；
（2）降低超时时间（不根本解决问题）；
（3）垂直拆分，N个接口拆分成若干个服务，使得在出问题时，被牵连的接口尽可能少（依旧不根本解决问题，难道一个服务只提供一个接口吗？）；
 
还能如何优化呢？
异步代理法，是一种很常见的架构实践。
 
业务场景：通过OpenID实时获取微信用户基本信息。
解决方案：增加一个代理，向服务屏蔽究竟是“本地实时”还是“异步远程”去获取返回结果。
第三方服务挂了，如何保证服务不受影响？
本地实时流程如上图1-5：
（1）业务调用方调用内部service；
（2）内部service调用异步代理service；
（3）异步代理service通过OpenID在本地拿取数据；
（4）异步代理service将数据返回内部service；
（5）内部service返回结果给业务调用方；
 
远程异步流程如上图6-8粗箭头的部分：
（6）异步代理service定期跨公网调用微信服务；
（7）微信服务返回数据；
（8）刷新本地数据；
 
这种方案有什么优缺点呢？
优点：公网抖动，第三方接口超时，不影响内部接口调用。
 
缺点：本地返回的不是最新数据（很多业务可以接受数据延时）。
画外音：有时候，内部service和异步代理service可以合成一个service。
 
还有其他的方法吗？
第三方接口备份与切换，也是一种常见的实践。
 
业务场景：调用第三方短信网关，或者电子合同等。
解决方案：同时使用（或者备份）多个第三方服务。
第三方服务挂了，如何保证服务不受影响？
流程如上图1-4：
（1）业务调用方调用内部service；
（2）内部service调用第一个三方接口；
（3）超时后，调用第二个备份服务，未来都直接调用备份服务，直到超时的服务恢复；
（4）内部service返回结果给业务调用方；
 
这种方案有什么优缺点呢？
优点：公网抖动，第三方接口超时，不影响内部接口调用（初期少数几个请求会超时）。
 
缺点：不是所有公网调用都能够像短息网关，电子合同服务一样有备份接口的，像微信、支付宝等就只此一家。
 
还有其他的方法吗？
异步调用法，也是一种实践。
 
业务场景：本地结果，同步第三方服务，例如用户在58到家平台下单，58到家平台需要通知平台商家为用户提供服务。
解决方案：本地调用成功就返回成功，异步调用第三方接口同步数据（和异步代理有微小差别）。
第三方服务挂了，如何保证服务不受影响？
本地流程如上图1-3：
（1）业务调用方调用内部service；
（2）内部service写本地数据；
（3）内部service返回结果给业务调用方成功；
 
异步流程如上图4-5粗箭头的部分：
（4）异步service定期将本地数据取出（或者通知也行，实时性好）；
（5）异步调用第三方接口同步数据；
这种方案有什么优缺点呢？
优点：公网抖动，第三方接口超时，不影响内部接口调用。
 
缺点：不是所有业务场景都可以异步同步数据。
 
总结
跨公网调用第三方，可能存在的问题：
（1）公网抖动，第三方服务不稳定，影响自身服务；
（2）一个接口超时，占住工作线程，影响其他接口；
降低影响的优化方案有：
（1）增大工作线程数；
（2）降低超时时间；
（3）服务垂直拆分；
 
任何脱离业务的架构方案都是耍流氓，可以结合业务实施方案：
（1）业务能接受旧数据：读取本地数据，异步代理定期更新数据；
（2）有多个第三方服务提供商：多个第三方互备；
（3）向第三方同步数据：本地写成功就算成功，异步向第三方同步数据；
 
希望第三方的服务挂掉，不再影响大家的服务。

发布者：糖太宗，转载请注明出处：https://www.qztxs.com/archives/science/technology/6556

赞 (0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
糖太宗糖太宗
0 0
上一篇 2022年5月14日 上午12:46
下一篇 2022年5月14日 上午12:49

相关推荐

  • 99%的人会答错，你敢不敢挑战一下？

    用户产品讲直觉，商业产品更讲逻辑。 设计师讲直觉，工程师更讲逻辑。 打德州，一部分同学讲究“就赌最后一张了”让人血脉喷张，一部分同学“没把牌计算概率”让人崩溃。 这样一些有意思的问题，凭直觉99%会答错。 问题一 一枚硬币，随机投掷一次，是正面和反面的概率各为50%。 随机投掷两次，有四种可能，正正，反反，正反，反正，概率各为25%。   现在，投掷第一次，...

    糖太宗 糖太宗
    技术 2022年5月11日
    3200
  • 无锁缓存，每秒10万并发，究竟如何实现？ 技术

    无锁缓存，每秒10万并发，究竟如何实现？

    有一类业务场景： （1）超高吞吐量，每秒要处理海量请求； （2）写多读少，大部分请求是对数据进行修改，少部分请求对数据进行读取； 这类业务，有什么实现技巧么？   接下来，一起听我从案例入手，娓娓道来。   快狗打车，场景举例： （1）司机地理位置信息会随时变化，可能每几秒钟地理位置要修改一次； （2）用户打车的时候查看某个司机的地理位置，查询地理位置的频率...

    糖太宗 糖太宗
    2022年5月14日
    7300

  • HTTPS 安全最佳实践（转发）

    0x00 前言 SSL/TLS 是一种简单易懂的技术，它很容易部署及运行。但想要部署的安全通常是不容易的。这也使系统管理员和开发者不得不去了解 SSL 和 TLS 相关的技术，掌握如何配置一个安全的 web 服务器或应用。无疑会耗费很大的精力去看相关的技术文档，乏味且宽泛。 本篇文档的目的在于如何让系统管理员或开发者用尽可能少的时间部署一个安全的 web 站...

    常山赵子龙 常山赵子龙
    技术 2022年6月1日
    5700

  • JumpServer堡垒机部署与运营

    前言 从应用安全，做成运维安全了，把最近做的东西总结一下。为啥需要堡垒机就不用多说了，服务器管理存在风险（ 多云导致服务器分散、账号混乱定位不明、权限粗放资源滥用、误操作、审计不严取证困难、等保合规要求等），访问服务器存在安全隐患（直接对公网开放22和3389端口、办公网直连、服务器互联等），因此，部署实施堡垒机，利用堡垒机的4A能力（身份鉴别、授权控制、账...

    常山赵子龙 常山赵子龙
    技术 2022年5月28日
    6200

  • mongodb开启认证

    修改配置文件，开启认证 1 2 3 4 # vi /etc/mongod.conf security: authorization:enablesd   创建密码 db.createUser({ user: “w11scan”, pwd: “w11scan”, roles: [{ role: “dbOwner”, db: “w11scan_conf...

    常山赵子龙 常山赵子龙
    技术 2022年5月28日
    4800

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

联系我们

400-800-8888

在线咨询： QQ交谈

邮件：admin@example.com

工作时间：周一至周五，9:30-18:30，节假日休息

关注微信