【51CTO.com原创稿件】在WOT2016移动互联网技术峰会上，陌陌技术保障部总监张明强老师表示“业务体系越庞大，高可用保障越困难”。会上，张明强老师以整体视角，来完整的归纳一下之前在高可用保障工作上的方方面面，以及每一方面易踩的坑。
张明强，2013年加入陌陌，经历了流量爆发式增长给技术架构、团队管理带来的各种问题及其解决过程。现任技术保障部总监，主要负责基础架构、运维、安全、信息化等工作，致力于提升服务稳定性与团队开发效率。
归类
最常见的故障诱因就是挂，挂的出现形式一般分为三种：彻底消失、假死和闪断。而针对这些故障形式，也有相应的解决方法。在一个复杂的业务架构中，监控是最为核心的一部分，如果没有监控，这个体系无论技术再强大，绝对不会是高可用。在做好监控之后还要准备“后备军”，挂了之后切到另外一个去就行，用多实例来解决挂的问题，多实例可以解决所有管的问题，只要设计得当。拆分是整个架构设计中非常重要的一个思路，当体系复杂的时候挂就像生病一样是无法避免的，这时运用拆分的理念不要让病原体再扩散，这个思路几乎可以解决所有的问题。
因为硬件的完善，挂所引起的故障不算太多。但是代码逻辑写的不好，设计稍有不慎，或者数据库太大，就会引起各种各样慢的问题，慢也有三种表现形式：自身慢、下游慢和上游慢。对于自身慢只要改善自身的问题，完善代码或者结构就可以有所改善。下游慢是日常运维过程中比较容易出现的一种，多见于数据库慢导致依赖的某个服务慢了，这时候就要分析问题是出自自身数据库，还是第三方的问题，分析日志和监控数据变成了很重要的事。上游慢不是很常见，但也不能忽略，其实99%的故障都是非常简单的，只要能在设计阶段能设想到的就能解决掉，主要问题在设计阶段能不能想全。解决思路非常简单，***多实例，第二是缓存，第三是拆分。
还有一种故障诱因是出错，这是能导致问题最多的一种，也是在设计中最容易忽略的一种，这种设计依赖于下游的模块，出错也有两种表现形式：错和空。纯粹的故障性错误是完全可以避免的，但技术却不是***的，技术解决不了的问题就需要通过管理或其他方式来解决，技术和管理这两条线都不能放松。其中流程规范是解决错误的***解决办法，团队中的每个人都有可能犯错，但是流程规范了这类问题就可以尽量避免。多做实例也是一个非常好的办法，当一个实例错了起码还可以从别的地方恢复过来，多做类似的措施以防止整条线全塌。
张明强总结了五种针对这些故障的具体解决办法。
分析
***就是监控，监控是基础，是整个高可用体系的根本。针对监控有三种形式：一个是业务监控，平台/框架监控，还有硬件监控，业务都会采用很多不同的框架，这三者结合起来才能打造一个完整的监控体系。在监控上容易踩的坑有四点：一，监控=数据+报警，所有数据都必须有报警才能称之为监控，否则只能说是统计。二，报警是要看的，要保证报警是有效的。三，靠监控自动处理的设计，小心误报，要依赖多因素验证。四，监控拖垮服务。
第二是多实例，多实例的核心是有备无患，有三种表现形式：冷备、热备和多活。冷备的核心是当服务发生故障之后，备份实例没有办法立即启用，需要人工接入，人工接入是冷备的一个核心特点。热备很简单，比如通常用的LVS、Keepalived，很多内部设计都是热备，热备是出问题之后工程师不用亲自管理，程序能自动切。第三部分是多活，多活是多实例里一个***目标，所有实例都在同时跑业务。在多实例上容易踩的坑有三点：一，首先要时刻记得多实例是用来解决什么级别的问题，把握住自己的需求，针对错误去解决。二、客户端会不会切换失败？要从整体出发，不是只有Server做了就行，客户端的请求必须能切走。三，要明确知道备机容量够不够，这是多实例中最容易出现的问题。
第三个方法是拆分，当所有方法都无计可施了，拆分都可以起作用，把错误的、有问题的拆出来单独部署，这是一个最保底的方案。拆分有两个表现形式：一个形式是拆入口，通过一定的路由规则把请求路由到不同的服务器上，防止一挂全挂；另一部分是拆阶段，把一个同步的请求拆成好多部分，比如常说的异步之类这些词。
第四种方法是缓存，缓存天生就是用来解决性能问题的，将CPU不停加到L1/L3缓存，来提高速度这是***种办法；第二种办法是将单通道改成多核，把一个实例改成多个实例做设计，缓存形式只有一个就是对数据做缓存。缓存容易踩的坑有四点：一，无***率监控，极低而不自知。二，脏数据。三，系统对穿透率支持的太低。四，缓存太散，导致IO次数太多，耗时太长。对于监控来说缓存一定要有***率。缓存还要关心Hits、Miss、性能和容量。
***的方法是流程规范，就像前面讲到的，技术并不是***的，所以要将技术和管理二者结合起来。流程规范有两种形式：一个是强制规范，一个是倡导类的。流程规范容易踩的坑有三点：一，一大堆规范。二，太复杂，难以执行。三，无人遵守，管理上不跟进。对于流程规范来说，上线规范是最重要的，上线规范又是灰度发布最重要的一个环节，这两个是整个高可用体系***的一道屏障，如果能随意突破，前面做再多的工作也白搭。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
