某CDN故障引发的思考：业务方如何应对作弊的第三方故障？完全没有必要事事亲力亲为。一是效率，二是成本。如果你喜欢喝牛奶，不一定非得自己养牛，所以大部分企业都或多或少地依赖第三方公司的服务，尤其是需要与第三方合作的企业。关联度也比较大。CDN服务是一种第三方服务，还有很多其他的服务，比如短信发送服务、语音留言服务、关键字过滤服务、第三方合作数据接口、酒店ota服务、运营数据统计服务、DNS解析服务、安全防护平台服务等。如果要对这些第三方服务进行分类，可以分为三类：基本类，如CDN服务、DNS解析、安全服务等。这些第三方服务为基础服务，与具体业务无关，与用户没有直接关联，但一旦基础服务出现异常，往往会导致整个业务完全不可用；业务类，如酒店ota服务、短信发送服务、语音服务、第三方数据合作接口（如点评信息参考、第三方登录），业务类服务将与业务紧密相连，仍将必要时成为业务不可分割的一部分。此类服务出现异常只会导致部分业务功能或逻辑出现异常。其余业务功能理论上不受影响，可以继续为用户提供服务；第三类服务，运营辅助服务，其实也可以归为基本类，但是第三类服务对大多数网站的重要性远低于其他基础服务。一旦出现异常，顶多是一个异常的操作数据。对于用户来说，这部分异常是无法察觉的。很多公司会在自己的能力范围内开发这部分作为自己的操作工具。对于一些业务规模比较小的网站，这部分还是需要依赖一些专业的第三方数据运营平台，比如GA，站长工具，一些点击统计工具。在实际工作场景中，想必大部分人都和我一样，或多或少会遇到这三类服务中的部分或全部出现异常，从而影响到自身业务的可用性。对此，我们也想了很多办法，避免这些第三方服务出现故障时，对我们的业务造成不必要的影响。很多时候，对于基础或者非常重要的服务，我们要做好备份、容错、降级的准备，并且要定期对这些异常备份方案进行演练，验证这些备案的可用性和切换效率，避免关键时刻备案根本不起作用的情况。对于基础的第三方服务，我们应该从系统架构入手，支持服务冗余和高可用，尽量将基础服务冗余hash到多个服务商，即使其中一些有问题，我们也可以屏蔽这些有问题的服务及时，从而有效保证业务的高可用。同时，监控相应的基础服务也是非常有必要的，因为一旦基础服务出现问题，对整个业务的影响会非常严重。基础服务与业务的关系更像是一个人如履薄冰。冰破裂时，人就会掉进冰洞里。例如，如果DNS解析出现异常，用户将根本无法访问我们的网站，当然也无法完成其他业务处理；如果CDN服务出现异常，如果放置在CDN服务上的静态文件和影音文件无法正常访问，将导致用户无法看到正常的内容或完成相关的交互操作，比如登录，比如购买，并且整个营业网点基本完全瘫痪。很多基础服务的尾部效应比较严重。比如DNS服务出现异常后，我们已经切换到正常的服务商，但是有可能部分地区的DNS会长期不正常；比如CDN服务异常，很多时候这些异常会被用户或者一些小运营商的内部代理服务器缓存起来。及时发现并处理基础业务异常，为我们的业务争取时间。对于业务第三方服务，我们应该从业务设计入手，去除强依赖，做好服务降级和容错工作，这样当部分第三方服务出现异常时，可以保证其他部分业务正常运行能得到的。业务第三方服务往往是“握手”关系，所以很少做备份冗余，而这种备份冗余最好由第三方服务来完成。对于业务端，如果握手失败，只能自己处理相关的异常，并进行适当的降级，让异常部分的功能被隐藏，其他部分的功能不受异常的影响，可以继续进行为用户提供服务。对于支撑运营的第三方服务，我们首先要做的就是不要让这样的异常影响到任何业务功能，同时也不要让用户感知到。对于运营工具服务异常，可以暂时关闭该服务，相关数据可以用过往数据填充。毕竟运营数据暂时的异常不会对长期的运营工作造成太大的影响，但是如果影响到业务的可用性就得不偿失了。尽量找靠谱的第三方服务商，质量有保证。成本没有那么低。有时为了节省成本，我们会选择没有质量保证的服务商。损失可能比我们节省的更多。许多。第三方服务商的责任感和沟通渠道也很重要。我们需要注意的是，除了服务商的服务质量保证，我们还需要注意服务商的责任。第三方服务异常对客户的影响。此外，沟通渠道是否畅通，客服和技术人员能否及时有效地处理用户问题也很重要。服务商的改进是否灵活多变？客户提出的需求能否尽可能实现？很多第三方服务商要么需要花钱定制，要么直接告诉你，我们的系统就是这样，没有变化，虽然他也知道他的系统有很多不合理的地方。不要把所有的鸡蛋都放在一个篮子里。对于大多数网站来说，如果成本压力不是太大，强烈建议不要把所有的服务都交给一个服务商。冗余备份应在必要时进行，并尽可能在平时使用这些备份措施，以保证其可用性。博客链接：https://img.ydisp.cn/news/20220914/wdm2e4qm113.com
