由某CDN故障引发的思考:业务方如何应对坑爹的第三方故障

开发 前端
喜欢喝牛奶未必就要自己养头奶牛,所以大部分公司的业务或多或少都会依赖一些第三方公司的服务,尤其是需要和第三方合作的业务,这种依赖就比较普遍,与业务的关联度也比较大了。

大部分公司的业务规模应该还没有达到所有服务都能够自给自足的程度,而且就算是BAT这些巨头们,很多服务也完全没有必要所有东西都自己做,一是效率问题,二是成本问题。喜欢喝牛奶未必就要自己养头奶牛,所以大部分公司的业务或多或少都会依赖一些第三方公司的服务,尤其是需要和第三方合作的业务,这种依赖就比较普遍,与业务的关联度也比较大了。

CDN服务算是第三方服务的一种,还有很多其他服务,比如短信发送服务,声讯服务,关键词过滤服务,第三方合作数据接口,酒店ota服务,运营数据统计服务,DNS解析服务 ,安全防范平台服务等。如果要给这些第三方服务分个类的话可以将其分为三大类:基础类,比如CDN服务,DNS解析,安全防范服务,这一类第三方服务属于基础服务,与具体的业务没有关系,也不直接与用户产生关联,但是一旦基础服务出现异常往往会导致整个业务完全不可用;业务类,比如酒店ota服务,短信发送服务,,声讯服务,第三方数据合作接口(比如点评信息的引用,第三方登录),业务类的服务会与业务紧密联系在一起,必要的时候还是会业务密不可分的一部分,这一类服务出现异常,只会导致部分业务功能异常或者逻辑异常,将此类异常做好降级工作,业务的其余功能理论上是不受影响,继续能够为用户提供服务的;第三类服务,运营辅助类服务,其实也可以归为基础类,但是第三类服务的重要性对于大部分网站远远没有其他基础类服务的重要性高,一旦出现异常顶多是运营数据的异常,对于用户而言,这部分的异常是无感知的。很多公司在能力所及的范围下都会将这一部分作为自身的运营工具来开发,对于一些业务规模还比较小的网站而言,这部分还是需要依赖一些专业的第三方数据运营平台的,比如GA,站长工具,还有一些点击统计的工具。

在实际的工作场景中,想必大家多数人和我一样,多多少少都会遇到这三类服务中某些或者全部服务出现过异常从而影响到自身业务的可用性。

对此,我们也想过很多方法来规避这些第三方服务发生故障时对我们的业务造成不必要的影响,很多时候,对于基础或者非常重要的服务,要做好备份,容错,降级等准备工作,而且要定期对这些异常备用方案进行演练,切实验证这些准备工作的可用性以及切换效率,避免出现关键时刻准备工作完全不起作用的情况。

针对基础类的第三方服务,我们应该从系统架构着手去支持服务的冗余与高可用,尽量将基础类的服务冗余散列在多个服务商处,就算是其中部分的服务商出现问题,我们也可以及时屏蔽掉这些有问题的服务,从而有效的保证业务的高可用。同时,***相应基础服务的监控也是非常有必要的,因为基础服务一旦出问题,对整个业务的影响那是非常严重的,基础服务与业务的关系更像冰面上行走的人,一旦冰面破了,人就会掉到冰窟里面去了。比如DNS解析异常,那就会导致用户完全无法访问我们的站点,当然也就无法完成其他业务的处理了;CDN服务出现异常,那放在CDN服务上的静态文件,影音文件无法正常访问的话,就会导致用户看不到正常的内容或者无法完成相关的交互操作,比如登录,比如购买,整个业务站点基本上就处于全部瘫痪状态了。基础服务很多后尾效应比较严重,比如DNS服务出现异常后,我们自身是切换到正常的服务方了,但是有可能局部地区的DNS会很长时间出现异常;比如CDN服务异常,很多时候这些异常会被用户或者一些小的运营商的内部代理服务器缓存掉。及时发现,处理基础服务的异常,就是给我们的业务争取可用的时间。

针对业务类的第三方服务,我们应该从业务设计出发,去掉强依赖,做好服务的降级和容错,以便当部分第三方服务异常的时候可以保证业务的其他部分是可用的。业务类第三方服务往往存在着类似“握手”的关系,所以很少能够做备份冗余的工作,而且这种备份冗余也***是第三方服务来做的,对于业务方而言,出现握手失败的话就只能自己处理相关异常并做适当的降级,做到异常部分功能隐藏,同时其他部分的功能不受异常影响能够继续为用户提供服务。

针对运营辅助类的第三方服务,我们首要要做的是,不要让这类异常影响到任何业务功能,同时不要让用户感知到。对于运营工具服务的异常,完全可以临时将此类服务关闭,相关数据可以用过往的数据进行填充,毕竟运营数据一时的异常不会对长远的运营工作造成任何大的影响,但是如果影响到业务的可用性就得不偿失了。

尽量找靠谱,质量有保证的第三方服务提供商,成本不是这么省的,有的时候为了节省成本而选择了一家质量无保证的服务商***损失的也许比我们节省的要多得多。

第三方服务商的责任心与沟通渠道也很重要,需要我们关注的,除了服务商服务质量保证外,我们也需要关注服务商的责任心,出问题后是否会主动,及时通知以及迅速降低第三方服务异常对客户造成的影响。另外,沟通渠道是否顺畅,客服与技术人员是否可以及时有效处理用户的问题也是非常重要的。服务商的改进是不是灵活可变的,对于客户提出的需求,能否尽可能地去实现,很多第三方服务商要么需要花钱定制,要么直接告诉你我们系统就是这个样子的,没的改,虽然他也知道自己系统存在着诸多的不合理之处。

不要把鸡蛋放在一个篮子里,对于大多数的网站,如果成本压力不是很大的话,非常建议不要把所有的服务放在一家服务商身上,必要的时候要做好冗余备份,而且尽可能的在平时就利用其这些备份措施,以保证其可用性。

博文链接:http://liuqunying.blog.51cto.com/3984207/1422341

责任编辑:林师授 来源: 51CTO博客
相关推荐

2015-11-05 16:44:37

第三方登陆android源码

2010-05-10 10:47:21

Chrome操作系统开源

2022-07-15 14:54:43

安全供应链数字化

2014-07-25 09:33:22

2017-12-11 15:53:56

2024-03-25 08:00:00

数字化转型

2017-05-16 13:24:02

LinuxCentOS第三方仓库

2014-07-23 08:55:42

iOSFMDB

2019-07-30 11:35:54

AndroidRetrofit

2023-04-16 19:34:01

2022-05-21 23:56:16

Python库搜索Python

2019-09-03 18:31:19

第三方支付电商支付行业

2017-11-01 06:40:33

2010-04-16 10:06:35

无线交换机故障

2009-12-31 14:38:34

Silverlight

2016-10-21 14:09:10

2019-09-02 14:59:41

苹果维修设备

2011-10-08 14:37:59

漏洞

2023-07-26 08:21:33

点赞
收藏

51CTO技术栈公众号