今天老大跟我讨论说，没有看到过一篇够全面体系的高可用的文章。谈到高可用，基本都是以偏概全的文章。今晚抽空想了一下这个问题。
高可用我另一个更资深老大其实总结的很全面了：别人死我们不死，自己不作死，不被队友搞死。
然后就是怎么别人死我们不死：最好就是别人的东西和我们没关系，就是去依赖。如果实在有依赖呢，那就尽量弱依赖。弱依赖有需要被依赖方的返回结果和不依赖返回结果两种。需要结果就要请求后回调，不需要就直接异步化。另外要做好超时和重试、蓄洪、限流、熔断、降级。如果只能强依赖呢，人家死了，那就我们报错，但是我们不死。这也需要设置合理超时和重试、蓄洪、限流、熔断、降级。人家又复活了，我们也要立即恢复。
基于对依赖的策略总结如下：
依赖策略里涉及到容灾的问题。容灾需要解决两个方面的问题：
这里就怎样快速失败和安全失败举一个例子。java.util包的容器的迭代器，在每次迭代的时候，其内部实现都会去判断modCount变量是否为expectedModCount的值。是的话就继续遍历，否则就抛出异常，终止遍历。这是一个快速失败的典型例子。
而采用安全失败机制的集合容器，在遍历时不时直接在集合内容上访问的，而是先复制原有集合内容，然后在拷贝的集合上进行遍历。所以再遍历过程中对元集合所作的修改并不能被迭代器检测到，不会触发异常。但是这时遍历对原集合的修改是不感知的。
快速恢复有些策略。最简单的比如心跳检测、事件监听等。
安全恢复一般主要是在恢复前对系统或数据先做一些检查、数据还原等。
有依赖的时候要尽量弱化依赖，除了理清业务逻辑之外，技术手段上可以采用异步化和旁路来解决。
再考虑怎么自己不作死。自己不作死，就是要考虑两个关键字：一个作，一个死。
作就是：改出问题？那就要不出问题：规范流程、做好测试、做好演练和压测。不当小白鼠，只用成熟的技术。职责单一化。
死就是：要考虑单个接口挂了咋办？单个接口挂了现场返回错误，同时不扩大影响，用其他服务补数据。单个节点挂了咋办？用集群。一个机房挂了咋办？多机房。一个地区的网断了咋办？多地区。后面几个合起来叫做异地多活。
涉及到集群和跨区，就要考虑策略问题。
策略的问题非常难解决，所以业界做异地多活的非常少。拿阿里巴巴来说，他们的异地多活经历了3个阶段。
最后考虑怎么不被队友搞死。
别人死我们不死和不被队友搞死的区别在于，队友和我们需要有明确的业务边界，搞清楚哪些是我们负责的，然后就是保证别人死我们不死。
总结与思考：
一个失败的leader是自己很牛，却没能带出来牛人。
跑题时间：
炊烟
小时候总爱无故的停下来发呆。有时候是风，想感受风，风的声音、风的力道、风的气息，就这样傻傻的呆站着半天，直到已经走了离我很远的小玩伴们大声在前面叫我。有时候是一座房子，总觉得梦里或者很久很久以前见到过、住过，好熟悉的感觉。而炊烟，是一种心境。袅袅升起的炊烟们，大家觉得自己在毫无规律的完成自己的宿命。而这宿命是由风、由引力、由相互间的碰撞、由炉灶中生的火势，早早已经决定好。大规律是那么一致，各自的曲线又那么不同。努力的想挣脱自己的命运，却又被命运狠狠的捉弄。不是心静的人是看不懂炊烟的。
小巷