2. 发生频率要低之自己不作死
自己不作死要做到两点：第一自己不作，第二自己不死。
2.1 不作
关于不作，我总结了以下7点：
1>不当小白鼠：只用成熟的技术，不因技术本身的问题影响系统的稳定。
2>职责单一化：不因职责耦合而削弱或抑制它完成最重要职责的能力。
3>流程规范化：降低人为因素带来的影响。
4>过程自动化：让系统更高效、更安全的运营。
5>容量有冗余：为了应对竞对系统不可用用户转而访问我们的系统、大促来临等情况，和出于容灾考虑，至少要保证系统2倍以上的冗余。
6>持续的重构：持续重构是确保代码长期没人动，一动就出问题的有效手段。
7>漏洞及时补：美团点评有安全漏洞运维机制，提醒督促各个部门修复安全漏洞。
2.2 不死
关于不死，地球上有五大不死神兽：能在恶劣环境下停止新陈代谢的“水熊虫”；可以返老还童的“灯塔水母”；在硬壳里休养生息的“蛤蜊”；水、陆、寄生样样都成的“涡虫”；有隐生能力的“轮虫”。它们的共通特征用在系统设计领域上就是自身容错能力强。这里“容错”的概念是：使系统具有容忍故障的能力，即在产生故障的情况下，仍有能力将指定的过程继续完成。容错即是Fault Tolerance，确切地说是容故障(Fault)，而并非容错误(Error)。
3. 发生频率要低之不被别人搞死
3.1 限流
在开放式的网络环境下，对外系统往往会收到很多有意无意的恶意攻击，如DDoS攻击、用户失败重刷。虽然我们的队友各个是精英，但还是要做好保障，不被上游的疏忽影响，毕竟，谁也无法保证其他同学哪天会写一个如果下游返回不符合预期就无限次重试的代码。这些内部和外部的巨量调用，如果不加以保护，往往会扩散到后台服务，最终可能引起后台基础服务宕机。下图是对无限流影响的问题树分析：
解决方法：
- 通过对服务端的业务性能压测，可以分析出一个相对合理的最大QPS。
- 流量控制中用的比较多的三个算法是令牌桶、漏桶、计数器。可以使用Guava的RateLimiter来实现。其中SmoothBurstry是基于令牌桶算法的，SmoothWarmingUp是基于漏桶算法的。
- 核心交易这边采用美团服务治理平台OCTO做thrift截流。可支持接口粒度配额、支持单机/集群配额、支持指定消费者配额、支持测试模式工作、及时的报警通知。其中测试模式是只报警并不真正节流。关闭测试模式则超过限流阈值系统做异常抛出处理。限流策略可以随时关闭。
- 可以使用Netflix的Hystrix或者美团点评自己研发的Rhino来做特殊的针对性限流。
4. 故障范围要小之隔离
隔离是指将系统或资源分割开，在系统发生故障时能限定传播范围和影响范围。
服务器物理隔离原则
① 内外有别：内部系统与对外开放平台区分对待。
② 内部隔离：从上游到下游按通道从物理服务器上进行隔离，低流量服务合并。
③ 外部隔离：按渠道隔离，渠道之间互不影响。
线程池资源隔离
- Hystrix通过命令模式，将每个类型的业务请求封装成对应的命令请求。每个命令请求对应一个线程池，创建好的线程池是被放入到ConcurrentHashMap中。
注意：尽管线程池提供了线程隔离，客户端底层代码也必须要有超时设置，不能无限制的阻塞以致于线程池一直饱和。
信号量资源隔离
- 开发者可以使用Hystrix限制系统对某一个依赖的最高并发数，这个基本上就是一个限流策略。每次调用依赖时都会检查一下是否到达信号量的限制值，如达到，则拒绝。
5. 故障恢复要快之快速发现
发现分为事前发现、事中发现和事后发现。事前发现的主要手段是压测和故障演练；事中发现的主要手段是监控报警；事后发现的主要手段是数据分析。
5.1 全链路线上压测
你的系统是否适合全链路线上压测呢?一般来说，全链路压测适用于以下场景：
① 针对链路长、环节多、服务依赖错综复杂的系统，全链路线上压测可以更快更准确的定位问题。
② 有完备的监控报警，出现问题可以随时终止操作。
③ 有明显的业务峰值和低谷。低谷期就算出现问题对用户影响也比较小。
全链路线上压测的目的主要有：
① 了解整个系统的处理能力
② 排查性能瓶颈
③ 验证限流、降级、熔断、报警等机制是否符合预期并分析数据反过来调整这些阈值等信息
④ 发布的版本在业务高峰的时候是否符合预期
⑤ 验证系统的依赖是否符合预期
全链路压测的简单实现：
① 采集线上日志数据来做流量回放，为了和实际数据进行流量隔离，需要对部分字段进行偏移处理。
② 数据着色处理。可以用中间件来获取和传递流量标签。
③ 可以用影子数据表来隔离流量，但是需要注意磁盘空间，建议如果磁盘剩余空间不足70%采用其他的方式隔离流量。
④ 外部调用可能需要Mock。实现上可以采用一个Mock服务随机产生和线上外部调用返回时间分布的时延。
压测工具上，核心交易这边使用美团点评开发的pTest。
6. 故障恢复要快之快速定位
定位需要靠谱的数据。所谓靠谱就是和要发现的问题紧密相关的，无关的数据会造成视觉盲点，影响定位。所以对于日志，要制定一个简明日志规范。另外系统监控、业务监控、组件监控、实时分析诊断工具也是定位的有效抓手。
7. 故障恢复要快之快速解决
要解决，提前是发现和定位。解决的速度还取决于是自动化的、半自动化的还是手工的。核心交易有意向搭建一个高可用系统。我们的口号是：“不重复造轮子，用好轮子。”这是一个集成平台，职责是：“聚焦核心交易高可用，更好、更快、更高效。”
美团点评内部可以使用的用于发现、定位、处理的系统和平台非常多，但是如果一个个打开链接或者登陆系统，势必影响解决速度。所以我们要做集成，让问题一站式解决。希望达到的效果举例如下：
工具介绍
Hystrix
Hystrix实现了断路器模式来对故障进行监控，当断路器发现调用接口发生了长时间等待，就使用快速失败策略，向上返回一个错误响应，这样达到防止阻塞的目的。这里重点介绍一下Hystrix的线程池资源隔离和信号量资源隔离。
线程池资源隔离
优点
- 使用线程可以完全隔离第三方代码，请求线程可以快速放回。
- 当一个失败的依赖再次变成可用时，线程池将清理，并立即恢复可用，而不是一个长时间的恢复。
- 可以完全模拟异步调用，方便异步编程。
缺点
- 线程池的主要缺点是它增加了CPU，因为每个命令的执行涉及到排队（默认使用SynchronousQueue避免排队），调度和上下文切换。
- 对使用ThreadLocal等依赖线程状态的代码增加复杂性，需要手动传递和清理线程状态（Netflix公司内部认为线程隔离开销足够小，不会造成重大的成本或性能的影响）。
信号量资源隔离
开发者可以使用Hystrix限制系统对某一个依赖的最高并发数。这个基本上就是一个限流策略，每次调用依赖时都会检查一下是否到达信号量的限制值，如达到，则拒绝。
优点
- 不新起线程执行命令，减少上下文切换。
缺点
- 无法配置断路，每次都一定会去尝试获取信号量。
比较一下线程池资源隔离和信号量资源隔离
- 线程隔离是和主线程无关的其他线程来运行的；而信号量隔离是和主线程在同一个线程上做的操作。
- 信号量隔离也可以用于限制并发访问，防止阻塞扩散，与线程隔离的最大不同在于执行依赖代码的线程依然是请求线程。
- 线程池隔离适用于第三方应用或者接口、并发量大的隔离；信号量隔离适用于内部应用或者中间件；并发需求不是很大的场景。
Rhino
Rhino是美团点评基础架构团队研发并维护的一个稳定性保障组件，提供故障模拟、降级演练、服务熔断、服务限流等功能。和Hystrix对比：
- 内部通过CAT（美团点评开源的监控系统，参见之前的博客“深度剖析开源分布式监控CAT”）进行了一系列埋点，方便进行服务异常报警。
- 接入配置中心，能提供动态参数修改，比如强制熔断、修改失败率等。
总结思考
王国维 在《人间词话》里谈到了治学经验，他说：古今之成大事业、大学问者，必经过三种之境界：
第一种境界
昨夜西风凋碧树。独上高楼，望尽天涯路。
第二种境界
衣带渐宽终不悔，为伊消得人憔悴。
第三种境界
众里寻他千百度，蓦然回首，那人却在，灯火阑珊处。
核心交易的高可用目前正在经历第一种：高瞻远瞩认清前人所走的路，以总结和学习前人的经验做为起点。
下一阶段，既然认定了目标，我们会呕心沥血孜孜以求，持续发展高可用。最终，当我们做了很多的事情，回过头来看，相信会对高可用有更清晰和深入的认识。敬请期待我们下一次的分享~~
