防微杜渐的稳定性法宝:播控系统面向失败的设计

作者| 阿里文娱高级开发工程师 云琰

一、浅谈面向失败的设计

1. 什么是面向失败的设计?

面向失败的设计,就是以“失败”为对象,天然为了失败而存在的设计思想,在一开始的系 统设计阶段就考虑到各种失败场景,把面向失败当成是系统设计的一部分,准备好从失败中恢 复的策略。

2. 为什么要面向失败设计?

因为无所不在的失败场景,比如硬件问题,软件 bug,配置变更错误,系统恶化,超预期流量,外部攻击,依赖库问题,依赖服务问题。
并且,这些一旦失败,轻则出现业务不可用,影响用户体验和企业声誉;重则导致数据永 久丢失、业务再无恢复可能。例如,911 事故发生前,约有 350 家企业在世贸大厦工作。事故 后,有 200 家企业由于重要系统被破坏,关键数据丢失而倒闭。

防微杜渐的稳定性法宝:播控系统面向失败的设计

3. 怎么面向失败设计?

在软件的整个生命周期中,不同的阶段面对失败场景有不同的应对规则。在设计阶段将系 统的架构简单化,结构层次分明;在发布阶段尽量做到最小变更原则,小规模,多次迭代;在运维阶段做好周期性压测,最小依赖。

防微杜渐的稳定性法宝:播控系统面向失败的设计

二、播控是如何实现面向失败设计的

1. 播控架构设计

防微杜渐的稳定性法宝:播控系统面向失败的设计

优酷播放控制系统从层级结构上将系统分成 3 层,对外服务层、基础服务层、数据存储层。
第一层:对外服务层包含播控 SDK,播控查询服务,播控变更服务,播控筛选服务;
第二层:基础服务层包含播控任务调度,播控数据库服务;
第三层:数据存储层包含分布式缓存,数据库,开放搜索。

从功能上,播控系统共 3 大核心线路读核心、写核心、筛选服务。
线路一:读核心是整个系统的核心服务,负责优酷、土豆、天猫视频展示、透出能力;
线路二:写核心负责整个系统策略变更核心服务;
线路三:筛选服务提供管理后台多数据源筛选服务。
这样设计的特性如下:
1)线路上读、写分离,核心与筛选分离(主次分离),单独链路变更失败之后不会影响核心链路的功能;
2)核心高并发查询服务读取数据库方式从数据库服务隔离开,当压力增加后,无单点瓶颈, 可以无限扩展;
3)任一链路故障,其他链路正常运行,稳定提供服务;
4)数据库服务遵从容量设计原则,针对查询服务、变更服务相同接口有不同限流策略。

2. 数据库不可用兜底设计

数据库兜底设计的目的在于在数据库不可用的极端场景下,保证生产链路不挂,且不会影 响到业务方。实现方式通过全局统一开关,切换核心读链路和写链路使用缓存作为临时的数据 持久层,并把数据变更堆积在消息队列中,待数据库可用后再切换回数据库,并消费消息队列。

防微杜渐的稳定性法宝:播控系统面向失败的设计

读链路以查询是否资源是否可播为例,兜底开关打开,则只查询缓存中是否存在该资源。 若缓存中存在资源,则返回查询结果。若不存在,则判断资源是否在禁播黑名单,根据判断结 果返回是否可播。可见兜底开关打开后,虽然返回的是降级之后的结果,但至少摆脱了对数据 库的依赖,整个流程仍能正常进行下去。

防微杜渐的稳定性法宝:播控系统面向失败的设计

写链路以新增资源策略为例,兜底开关打开,则先查询缓存中是否存在该资源策略。若缓 存中存在该资源策略,则流程结束。若不存在,则更新缓存,并发送消息,用于延时消费,更 新数据库。可以看到思路仍然是以缓存作为临时数据源,降低对数据库的依赖,同时借助了消 息队列的异步特性,来解决数据库恢复后,数据库数据与缓存数据的一致性问题。

3. 缓存冗余更新和缓存一致性检测设计

高并发的业务场景下,数据库是十分宝贵的资源,也是非常薄弱的环节。系统设计时不可 避免的需要使用缓存作为缓冲。上一小节针对数据库不可用的极端场景设计了方案,本小节将 会提出两种解决缓存与数据不一致问题的方案。
1)缓存冗余更新 缓存冗余更新是在数据发生变更时,通过同步与异步冗余更新的方式,保证不会出现脏数
据,并且保证最终的数据一致性。

防微杜渐的稳定性法宝:播控系统面向失败的设计

1-2-6-7 即为一个常见的旁路缓存更新结构。但由于业务的复杂性,在播控变更服务执行完
数据变更后,需要通过步骤 3 发消息通知外部系统,外部系统接收到消息后通过步骤 4-5 进行
反查,但由于步骤 3 和步骤 6-7 都是异步过程,可能在 6-7 执行完成之前,3-4-5 已经执行,则 查询到的是更新之前的脏数据。
缓存冗余更新的思路是,变更服务除了通过消息异步更新缓存之外,同步的调用播控任务 调度,去更新缓存。同步更新保证缓存数据的准确性,不会出现脏数据,异步更新保证更新链 路的高可用,不会因为接口调用失败而导致缓存更新失败,达到最终数据的一致性。
2)缓存一致性检测 缓存冗余更新是用来确保写入缓存时数据的正确性。除此之外,我们还提供一种写入缓存
后的缓存一致性检测机制,专门检查近期写入缓存的数据是否符合预期,检测到不一致后进行
上报和清理。
检测流程如下,利用 guava cache 设置 5s 过期机制,在数据变更写入数据库和缓存的 5s 之 后,通过监听器监听 guava cache 的过期,来触发数据对比的检测,并根据检测结果做出相应的处理。

防微杜渐的稳定性法宝:播控系统面向失败的设计

4. 远端/近端调用动态切换设计

播控除了通过 RPC 调用方式为上游业务提供基础服务,还提供了播控 SDK 可以供业务方 进行近端调用。近端调用对于业务方来说在降低延时,提高成功率方面都有很好的效果,对于 播控来说也能减轻服务器压力,节省资源。但为了防止出现稳定性问题,也必须面向失败设计, 提供降级方案,其中一种降级方案是流量动态切换方案。当业务方机器能够承受的 SDK 流量上 限超过阈值时,多余的流量会动态分散到播控中心系统;这在实际中是很有效的,在一些单机 QPS 达到 1000 甚至更高的场景下,确保 SDK 不会压垮业务方机器。极端情况下,所有流量都 可以回切到播控中心系统。

三、总结

一个优秀的架构师往往都是悲观主义者,除了设计好能够支撑业务持续发展的优雅架构, 另一个容易被忽略的重要能力在于充分考虑失败场景。面向失败设计是一种十分重要的设计思 路,需要能够防患于未然,在设计阶段考虑到各种失败场景,提前准备好预案,并且做好充分 的演练和验证。只有这样才能够在失败来临时从容应对。

上一篇:新冠这只“黑天鹅”,AI 该如何“驯服”?|开发者必读(167期)


下一篇:如何降低 PB 级带宽成本?揭秘优酷“云边端”分发网络