接口设计

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

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

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

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

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

1.2 遵循快速失败原则，一定要设置超时时间
　　某服务调用的一个第三方接口正常响应时间是50ms，某天该第三方接口出现问题，大约有15%的请求响应时间超过2s，没过多久服务load飙高到10以上，响应时间也非常缓慢，即第三方服务将我们服务拖垮了。

为什么会被拖垮？没设置超时！我们采用的是同步调用方式，使用了一个线程池，该线程池里最大线程数设置了50，如果所有线程都在忙，多余的请求就放置在队列里中。如果第三方接口响应时间都是50ms左右，那么线程都能很快处理完自己手中的活，并接着处理下一个请求，但是不幸的是如果有一定比例的第三方接口响应时间为2s，那么最后这50个线程都将被拖住，队列将会堆积大量的请求，从而导致整体服务能力极