首页
下载应用
提交文章
关于我们
问卷:你怎么看自由微信?
🔥 热搜 🔥
1
百度
2
今日热点
3
微信公众平台
4
贴吧
5
opgg
6
dnf私服
7
百度贴吧
8
知乎
9
dnf公益服
10
百度傻逼
分类
社会
娱乐
国际
人权
科技
经济
其它
首页
下载应用
提交文章
关于我们
问卷:你怎么看自由微信?
🔥
热搜
🔥
1
百度
2
今日热点
3
微信公众平台
4
贴吧
5
opgg
6
dnf私服
7
百度贴吧
8
知乎
9
dnf公益服
10
百度傻逼
分类
社会
娱乐
国际
人权
科技
经济
其它
白石洲拆迁后,那些上学奔波的孩子都去哪儿了?
一个医保局长之死
给宠物做保姆的中国留学生
本以为吴京大儿子叫“吴所谓”够随意了,听到二儿子名字,真服了
法院4.2元拍卖一瓶雪碧,限自提!被执行人回应:没有更多可供执行财产
生成图片,分享到微信朋友圈
查看原文
其他
第三方服务挂了,如何保证服务不受影响?
Original
58沈剑
架构师之路
2022-07-22
收录于合集
上周有个朋友问我说:
沈老师,我们有很多服务依赖第三方接口,他们的接口不稳定,从而影响我们的服务,有没有什么方法避免?
今天和大家聊一聊这个问题。
首先,可以将第三方接口,收口到一个服务内。
这样,可以避免每个调用方都依赖于第三方服务:
(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)
向第三方同步数据
:本地写成功就算成功,异步向第三方同步数据;
希望第三方的服务挂掉,不再影响大家的服务。
您可能也对以下帖子感兴趣
{{{title}}}
文章有问题?点此查看未经处理的缓存