有关程序健壮性的小思考

有一个需求：为网关加入一个功能。对于指定直播间的非核心功能，直接进行流量降级，用以保护后端。

开发语言是 golang。最开始的想法就很简单，起一个协程。定时将存在 Redis 的需要降级的直播 id 同步到一个 map 中。在网关拦截器中进行判断，如直播 id 存在于 map 中的话，就判断该次请求是否需要降级，并执行。最开始也是这样实现，很快就写完进入测试了。

但是想到一个问题，假如用于同步数据的协程因为某些原因挂了怎么办？那么这个功能就失效了。根据情况会出现两个场景。

1. 处于降级中。该实例则将无法正常配置和移除直播 id。该直播在这个实例上，将一直处于降级模式。从外面观察看起来就是，虽然移出了降级，在大多数时候也恢复正常了，但是总会出现偶尔的降级情况，无规律。

2. 无降级中。该实例则将无法正常配置和移除直播 id。大部分请求遇到非核心功能都能正常进行降级，但也会有偶尔的没有进行降级的请求。

考虑到这个功能的初衷是为了保护后端整个服务不会被单个大直播间冲垮，保证其他直播的可用性而做的妥协。被限制的直播间，除了基本的直播功能以外其他都不可用。所以，所以在正常情况下是不希望开启的，只是作为最后保障。此处协程挂了，没有恢复能力，也没有任何观测能力。又不能直接把程序崩溃，陷入了一种无可奈何的状态。

当有直播处于降级中，协程挂了。对于业务来说是不可接受的，无法取消意味着营销销售相关的功能统统无法使用了。斟酌了几次，选择了触发式更新数据，每次请求都会比对最后一次请求的时间，如果超过一定时间，则触发更新。一次失败则会反复重试，直到成功。可控可

在开发过程中，因为实现方式的不可控和不可观测性。选择了一种不那么优雅的实现方式。