作者：焦振清
时间：2017-11-29
这次分享的一个case依然是各家公司都会出现的问题，对于第三方依赖的故障，怎么破？
当然，很多人会说，高内聚低耦合，为啥要用第三方呢？只能说理论如此。我们所依赖的第三方，或者是垄断性质的，或者是效率提升性的，总之有他存在的理由。换句话说，你自己做，未必能比他更好，未必会得到大家的认可，不然，估计他也就不会存在了。
那怎么破呢？不同的公司解法不同，没有标准答案，但是有一点是关键的，你要有价值，要让别人认可你的价值，不然，你懂得。接下来，我们就聊一些技术上的通用手段了，不能保证每种场景都适配，大家需要依据实际的情况来做：
1，切流量
- 第三方依赖的华北集群故障，那就把流量切到他们的华东/华南集群
- 寻找同质的第三方依赖，一家挂了，切换到另外一家
- 反例：支付的依赖，之前某家公司，因为公司战略原因，无法使用市场上的同类竞品，且因为自身技术原因，也做不到跨地域容灾，你说能咋办
2，缓存
- 对于第三方依据实际情况进行本地缓存，从而将第三方视为一个自身故障后的数据全量加载和增量更新的数据源
- 反例：金融类的依赖，很多用户数据你是不能做缓存的，很多数据也是不应该做缓存的
3，降级
- 如果确实无法降低实时依赖，且第三方依赖故障了，那么请求只能延时处理了
- 服务不能写但是可以提供读的能力
接下来，又要讲一个悲伤的故事了，这个悲伤的故事，墨菲同学继续上场了，但是这次的case又和以往不同，基本上每个月这个平台会发生一次问题，但问题非全局的故障，不会影响到所有人仅仅是个别用户，因此，这个问题给大家的感受是：不疼！所以，各家一直没有痛下决心来优化相关的预案，就这么死扛着，而且最近的一个季度，每个月就一次，每次只影响一两个用户，所以，可预见的是，这个问题会继续存在下去，直到哪天影响到哪个核心用户了，或者哪天被大老板碰上了，可能就解决了。
2017/11/17
2017/10/17
2017/9/14
2017/8/24
2017/8/15
2017/8/7
2017/8/2
2017/7/31
2017/7/14
2017/6/3
2017/6/2
2017/6/1
2017/5/3
2017/5/3
2017/4/25
2017/3/31
2017/3/26
2017/3/22
2017/3/21
2017/3/10
2017/3/10
2017/2/3
2017/1/23