大话高可用
今天老大跟我讨论说，没有看到过一篇够全面体系的高可用的文章。谈到高可用，基本都是以偏概全的文章。今晚抽空想了一下这个问题。
高可用我另一个更资深老大其实总结的很全面了：别人死我们不死，自己不作死，不被队友搞死。
然后就是怎么别人死我们不死：最好就是别人的东西和我们没关系，就是去依赖。如果实在有依赖呢，那就尽量弱依赖。弱依赖有需要被依赖方的返回结果和不依赖返回结果两种。需要结果就要请求后回调，不需要就直接异步化。另外要做好超时和重试、蓄洪、限流、熔断、降级。如果只能强依赖呢，人家死了，那就我们报错，但是我们不死。这也需要设置合理超时和重试、蓄洪、限流、熔断、降级。人家又复活了，我们也要立即恢复。
基于对依赖的策略总结如下：
依赖策略里涉及到容灾的问题。容灾需要解决两个方面的问题：
这里就怎样快速失败和安全失败举一个例子。java.util包的容器的迭代器，在每次迭代的时候，其内部实现都会去判断modCount变量是否为expectedModCount的值。是的话就继续遍历，否则就抛出异常，终止遍历。这是一个快速失败的典型例子。
而采用安全失败机制的集合容器，在遍历时不时直接在集合内容上访问的，而是先复制原有集合内容，然后在拷贝的集合上进行遍历。所以再遍历过程中对元集合所作的修改并不能被迭代器检测到，不会触发异常。但是这时遍历对原集合的修改是不感知的。
快速恢复有些策略。最简单的比如心跳检测、事件监听等。
安全恢复一般主要是在恢复前对系统或数据先做一些检查、数据还原等。
有依赖的时候要尽量弱化依赖，除了理清业务逻辑之外，技术手段上可以采用异步化和旁路来解决。
再考虑怎么自己不作死。自己不作死，就是要考虑两个关键字：一个作，一个死。
作就是：改出问题？那就要不出问题：规范流程、做好测试、做好演练和压测。不当小白鼠，只用成熟的技术。职责单一化。
死就是：要考虑单个接口挂了咋办？单个接口挂了现场返回错误，同时不扩大影响，用其他服务补数据。单个节点挂了咋办？用集群。一个机房挂了咋办？多机房。一个地区的网断了咋办？多地区。后面几个合起来叫做异地多活。
涉及到集群和跨区，就要考虑策略问题。
策略的问题非常难解决，所以业界做异地多活的非常少。拿阿里巴巴来说，他们的异地多活经历了3个阶段。
最后考虑怎么不被队友搞死。
别人死我们不死和不被队友搞死的区别在于，队友和我们需要有明确的业务边界，搞清楚哪些是我们负责的，然后就是保证别人死我们不死。
总结与思考：
一个失败的leader是自己很牛，却没能带出来牛人。
跑题时间：
炊烟
小时候总爱无故的停下来发呆。有时候是风，想感受风，风的声音、风的力道、风的气息，就这样傻傻的呆站着半天，直到已经走了离我很远的小玩伴们大声在前面叫我。有时候是一座房子，总觉得梦里或者很久很久以前见到过、住过，好熟悉的感觉。而炊烟，是一种心境。袅袅升起的炊烟们，大家觉得自己在毫无规律的完成自己的宿命。而这宿命是由风、由引力、由相互间的碰撞、由炉灶中生的火势，早早已经决定好。大规律是那么一致，各自的曲线又那么不同。努力的想挣脱自己的命运，却又被命运狠狠的捉弄。不是心静的人是看不懂炊烟的。
小巷
总是会被看上去神秘的小去处吸引，一条蜿蜒的小路、一片树林，一扇断墙，最逃不过的吸引力是古朴的小巷。总能感觉到他们蕴藏的故事和哀怨。每次想到自己在日本新宿时特别想进去的那条“思い出の町”，就想起给别人带来的危险。当时是一群同事一起去的，我好想进去看看，但是被他们叫住，说不知道里面有什么，出了危险怎么办，我只好作罢。然而想来从那以后我也从来没断过把自己置于危险的境地。我终究不会甘于岁月静好，偏爱波澜起伏的人生。这是命运，逃也逃不掉。
峡谷
现在看电影电视剧到底谁爱上了谁，终究与我无关，爱情之于我仿佛是桌面的落灰，遥远而轻浅。我更关心的是里面的兄弟之情、亲子之情，这些是更永恒纯粹的。那年我回家小姨家，每天睡醒了就去峡谷里的小溪边坐着，看着日光、山涧、青草、山花。后来弟弟给我写信我才知道，这时候他总是在山上，远远的看着我的背影。记得他带我寻访住在山间的书法家，告诉我将来他也要归隐过这样的日子。跟别人，更多的是“欲诉无人能懂”，而血脉之间，无需言语，看到对方就找到了自己。
我喜欢的风景从来都不是特意去某个地方，而是做某件事情过程中的路过。中午出去买水果时伸手接住的雪花、出差到达的另一个国度、坐火车转车干脆订个酒店在附近看到的冰灯…… 也许有一天，你会陪我一起看彼此眼中的风景