搜狐首页 科技 法医秦明

手机搜狐

SOHU.COM

如何健壮你的后端服务?

对每一个程序员而言,故障都是悬在头上的达摩克利斯之剑,都唯恐避之不及,如何避免故障是每一个程序员都在苦苦追寻希望解决的问题。对于这一问题,大家都可以从需求分析、架构设计、代码编写、测试、codereview、上线、线上服务运维等各个视角给出自己的答案。本人结合自己两年有限的互联网后端工作经验,从某几个视角谈谈自己对这一问题的理解,不足之处,望大家多多指出。

我们大部分服务都是如下的结构,既要给使用方使用,又依赖于他人提供的第三方服务,中间又穿插了各种业务、算法、数据等逻辑,这里面每一块都可能是故障的来源。如何避免故障?我用一句话概括,“怀疑第三方,防备使用方,做好自己”

1 怀疑第三方

坚持一条信念:“所有第三方服务都不可靠”,不管第三方什么天花乱坠的承诺。基于这样的信念,我们需要有以下行动。

1.1 有兜底,制定好业务降级方案

如果第三方服务挂掉怎么办?我们业务也跟着挂掉?显然这不是我们希望看到的结果,如果能制定好降级方案,那将大大提高服务的可靠性。举几个例子以便大家更好的理解。

比如我们做个性化推荐服务时,需要从用户中心获取用户的个性化数据,以便代入到模型里进行打分排序,但如果用户中心服务挂掉,我们获取不到数据了,那么就不推荐了?显然不行,我们可以在cache里放置一份热门商品以便兜底;

又比如做一个数据同步的服务,这个服务需要从第三方获取最新的数据并更新到mysql中,恰好第三方提供了两种方式:1)一种是消息通知服务,只发送变更后的数据;2)一种是http服务,需要我们自己主动调用获取数据。我们一开始选择消息同步的方式,因为实时性更高,但是之后就遭遇到消息迟迟发送不过来的问题,而且也没什么异常,等我们发现一天时间已过去,问题已然升级为故障。合理的方式应该两个同步方案都使用,消息方式用于实时更新,http主动同步方式定时触发(比如1小时)用于兜底,即使消息出了问题,通过主动同步也能保证一小时一更新。

有些时候第三方服务表面看起来正常,但是返回的数据是被污染的,这时还有什么方法兜底吗?有人说这个时候除了通知第三方快速恢复数据,基本只能干等了。举个例子,我们做移动端的检索服务,其中需要调用第三方接口获取数据来构建倒排索引,如果第三方数据出错,我们的索引也将出错,继而导致我们的检索服务筛选出错误的内容。第三方服务恢复数据最快要半小时,我们构建索引也需要半小时,即可能有超过1个多小时的时间检索服务将不能正常使用,这是不可接受的。如何兜底呢?我们采取的方法是每隔一段时间保存全量索引文件快照,一旦第三方数据源出现数据污染问题,我们先按下停止索引构建的开关,并快速回滚到早期正常的索引文件快照,这样尽管数据不是很新(可能1小时之前),但是至少能保证检索有结果,不至于对交易产生特别大的影响。

精选