架构 高可用

高可用：别人死我们不死，自己不作死，不被队友搞死。

　　然后就是怎么别人死我们不死：最好就是别人的东西和我们没关系，就是去依赖。如果实在有依赖呢，那就尽量弱依赖。弱依赖有需要被依赖方的返回结果和不依赖返回结果两种。需要结果就要请求后回调，不需要就直接异步化。另外要做好超时和重试、蓄洪、限流、熔断、降级。如果只能强依赖呢，人家死了，那就我们报错，但是我们不死。这也需要设置合理超时和重试、蓄洪、限流、熔断、降级。人家又复活了，我们也要立即恢复。

　　基于对依赖的策略总结如下：

　　依赖策略里涉及到容灾的问题。容灾需要解决两个方面的问题：

 

　　这里就怎样快速失败和安全失败举一个例子。java.util包的容器的迭代器，在每次迭代的时候，其内部实现都会去判断modCount变量是否为expectedModCount的值。是的话就继续遍历，否则就抛出异常，终止遍历。这是一个快速失败的典型例子。

　　而采用安全失败机制的集合容器，在遍历时不时直接在集合内容上访问的，而是先复制原有集合内容，然后在拷贝的集合上进行遍历。所以再遍历过程中对元集合所作的修改并不能被迭代器检测到，不会触发异常。但是这时遍历对原集合的修改是不感知的。

　　快速恢复有些策略。最简单的比如心跳检测、事件监听等。

　　安全恢复一般主要是在恢复前对系统或数据先做一些检查、数据还原等。

 　　有依赖的时候要尽量弱化依赖，除了理清业务逻辑之外，技术手段上可以采用异步化和旁路来解决。

 

　　再考虑怎么自己不作死。自己不作死，就是要考虑两个关键字：一个作，一个死。

　　作就是：改出问题？那就要不出问题：规范流程、做好测试、做好演练和压测。不当小白鼠，只用成熟的技术。职责单一化。

 

　　死就是：要考虑单个接口挂了咋办？单个接口挂了现场返回错误，同时不扩大影响，用其他服务补数据。单个节点挂了咋办？用集群。一个机房挂了咋办？多机房。一个地区的网断了咋办？多地区。后面几个合起来叫做异地多活。

 

涉及到集群和跨区，就要考虑策略问题。

策略的问题非常难解决，所以业界做异地多活的非常少。拿阿里巴巴来说，他们的异地多活经历了3个阶段。

 

 

　　最后考虑怎么不被队友搞死。

　　别人死我们不死和不被队友搞死的区别在于，队友和我们需要有明确的业务边界，搞清楚哪些是我们负责的，然后就是保证别人死我们不死。

　　

总结与思考：

　　一个失败的leader是自己很牛，却没能带出来牛人。