【IT168 技术】在任何一家互联网公司，不管其主营业务是什么，都会有一套自己的账号体系。账号既是公司所有业务发展留下的最宝贵资产，它可以用来衡量业务指标，例如日活、月活、留存等，同时也给不同业务线提供了大量潜在用户，业务可以基于账号来做用户画像，制定各自的发展路径。因此，账号服务的重要性不言而喻，同时美团业务飞速发展，对账号业务的可用性要求也越来越高。本文将分享一些我们在高可用探索中的实践。
衡量一个系统的可用性有两个指标：
1. MTBF (Mean Time Between Failure)即平均多长时间不出故障;
2. MTTR (Mean Time To Recovery)即出故障后的平均恢复时间。
通过这两个指标可以计算出可用性，也就是我们大家比较熟悉的“几个9”。
因此提升系统的可用性，就得从这两个指标入手，要么降低故障恢复的时间，要么延长不出故障的时间。
1. 业务监控
要降低故障恢复的时间，首先得尽早的发现故障，然后才能解决故障，这就需要依赖业务监控系统。
业务监控不同于其他监控系统，业务监控关注的是各个业务指标是否正常，比如账号的登录曲线。大众点评登录入口有很多，从终端上分有App、PC、M站，从登录类型上分有密码登录、快捷登录、第三方登录(微信/QQ/微博)、小程序登录等。需要监控的维度有登录总数、成功数、失败分类、用户地区、App版本号、浏览器类型、登录来源Referer、服务所在机房等等。业务监控最能从直观上告诉我们系统的运行状况。
由于业务监控的维度很多很杂，有时还要增加新的监控维度，并且告警分析需要频繁聚合不同维度的数据，因此我们采用Elasticsearch作为日志存储。整体架构如下图：
每条监控都会根据过去的业务曲线计算出一条基线(见下图)，用来跟当前数据做对比，超出设定的阈值后就会触发告警。
每次收到告警，我们都要去找出背后的原因，如果是流量涨了，是有活动了还是被刷了?如果流量跌了，是日志延时了还是服务出问题了?另外值得重视的是告警的频次，如果告警太多就会稀释大家的警惕性。我们曾经踩过一次坑，因为告警太多就把告警关了，结果就在关告警的这段时间业务出问题了，我们没有及时发现。为了提高每条告警的定位速度，我们在每条告警后面加上维度分析。如下图(非真实数据)，告警里直接给出分析结果。
2. 柔性可用
柔性可用的目的是延长不出故障的时间，当业务依赖的下游服务出故障时不影响自身的核心功能或服务。账号对上层业务提供的鉴权和查询服务即核心服务，这些服务的QPS非常高，业务方对服务的可用性要求很高，别说是服务故障，就连任何一点抖动都是不能接受的。对此我们先从整体架构上把服务拆分，其次在服务内对下游依赖做资源隔离，都尽可能的缩小故障发生时的影响范围。
另外对非关键路径上的服务故障做了降级。例如账号的一个查询服务依赖Redis，当Redis抖动的时候服务的可用性也随之降低，我们通过公司内部另外一套缓存中间件Tair来做Redis的备用存储，当检测到Redis已经非常不可用时就切到Tair上。
通过开源组件Hystrix或者我们公司自研的中间件Rhino就能非常方便地解决这类问题，其原理是根据最近一个时间窗口内的失败率来预测下一个请求需不需要快速失败，从而自动降级，这些步骤都能在毫秒级完成，相比人工干预的情况提升几个数量级，因此系统的可用性也会大幅提高。下图是优化前后的对比图，可以非常明显的看到，系统的容错能力提升了，TP999也能控制在合理范围内。
对于关键路径上的服务故障我们可以减少其影响的用户数。比如手机快捷登录流程里的某个关键服务挂了，我们可以在返回的失败文案上做优化，并且在登录入口挂小黄条提示，让用户主动去其他登录途径，这样对于那些设置过密码或者绑定了第三方的用户还有其他选择。
具体的做法是我们在每个登录入口都关联了一个计数器，一旦其中的关键节点不可用，就会在受影响的计数器上加1，如果节点恢复，则会减1，每个计数器还分别对应一个标志位，当计数器大于0时，标志位为1，否则标志位为0。我们可以根据当前标志位的值得知登录入口的可用情况，从而在登录页展示不同的提示文案，这些提示文案一共有2^5=32种。
下图是我们在做故障模拟时的降级提示文案：
3. 异地多活
除了柔性可用，还有一种思路可以来延长不出故障的时间，那就是做冗余，冗余的越多，系统的故障率就越低，并且是呈指数级降低。不管是机房故障，还是存储故障，甚至是网络故障，都能依赖冗余去解决，比如数据库可以通过增加从库的方式做冗余，服务层可以通过分布式架构做冗余，但是冗余也会带来新的问题，比如成本翻倍，复杂性增加，这就要衡量投入产出比。
目前美团的数据中心机房主要在北京上海，各个业务都直接或间接的依赖账号服务，尽管公司内已有北上专线，但因为专线故障或抖动引发的账号服务不可用，间接导致的业务损失也不容忽视，我们就开始考虑做跨城的异地冗余，即异地多活。
3.1 方案设计
首先我们调研了业界比较成熟的做法，主流思路是分set化，优点是非常利于扩展，缺点是只能按一个维度划分。比如按用户ID取模划分set，其他的像手机号和邮箱的维度就要做出妥协，尤其是这些维度还有唯一性要求，这就使得数据同步或者修改都增加了复杂度，而且极易出错，给后续维护带来困难。考虑到账号读多写少的特性(读写比是350:1)，我们采用了一主多从的数据库部署方案，优先解决读多活的问题。
Redis如果也用一主多从的模式可行吗?答案是不行，因为Redis主从同步机制会优先尝试增量同步，当增量同步不成功时，再去尝试全量同步，一旦专线发生抖动就会把主库拖垮，并进一步阻塞专线，形成“雪崩效应”。因此两地的Redis只能是双主模式，但是这种架构有一个问题，就是我们得自己去解决数据同步的问题，除了保证数据不丢，还要保证数据一致。
另外从用户进来的每一层路由都要是就近的，因此DNS需要开启智能解析，SLB要开启同城策略，RPC已默认就近访问。
总体上账号的异地多活遵循以下三个原则：
1. 北上任何一地故障，另一地都可提供完整服务。2. 北上两地同时对外提供服务，确保服务随时可用。3. 两地服务都遵循BASE原则，确保数据最终一致。
最终设计方案如下：
3.2 数据同步
首先要保证数据在传输的过程中不能丢，因此需要一个可靠接收数据的地方，于是我们采用了公司内部的MQ平台Mafka(类Kafka)做数据中转站。可是消息在经过Mafka传递之后可能是乱序的，这导致对同一个key的一串操作序列可能导致不一致的结果，这是不可忍受的。但Mafka只是不保证全局有序，在单个partition内却是有序的，于是我们只要对每个key做一遍一致性散列算法对应一个partitionId，这样就能保证每个key的操作是有序的。
但仅仅有序还不够，两地的并发写仍然会造成数据的不一致。这里涉及到分布式数据的一致性问题，业界有两种普遍的认知，一种是Paxos协议，一种是Raft协议。我们吸取了对实现更为友好的Raft协议，它主张有一个主节点，其余是从节点，并且在主节点不可用时，从节点可晋升为主节点。简单来说就是把这些节点排个序，当写入有冲突时，以排在最前面的那个节点为准，其余节点都去follow那个主节点的值。在技术实现上，我们设计出一个版本号(见下图)，实际上是一个long型整数，其中数据源大小即表示节点的顺序，把版本号存入value里面，当两个写入发生冲突的时候只要比较这个版本号的大小即可，版本号大的覆盖小的，这样能保证写冲突时的数据一致性。
写并发时数据同步过程如下图：
这种同步方式的好处显而易见，可以适用于所有的Redis操作且能保证数据的最终一致性。但这也有一些弊端，由于多存了版本号导致Redis存储会增加，另外在该机制下两地的数据其实是全量同步的，这对于那些仅用做缓存的存储来说是非常浪费资源的，因为缓存有数据库可以回源。而账号服务几乎一半的Redis存储都是缓存，因此我们需要对缓存同步做优化。
账号服务的缓存加载与更新模式如下图：
我们优化的方向是在缓存加载时不同步，只有在数据库有更新时才去同步。但是数据更新这个流程里不能再使用delete操作，这样做有可能使缓存出现脏数据，比如下面这个例子：
我们对这个问题的解决办法是用set(若key不存在则添加，否则覆盖)代替delete，而缓存的加载用add(若key不存在则添加，否则不修改)，这样能保证缓存更新时的强一致性却不需要增加额外存储。考虑到账号修改的入口比较多，我们希望缓存更新的逻辑能拎出来单独处理减少耦合，最后发现公司内部数据同步组件Databus非常适用于该场景，其主要功能是把数据库的变更日志以消息的形式发出来。于是优化后的缓存模式如下图：
从理论变为工程实现的时候还有些需要注意的地方，比如同步消息没发出去、数据收到后写失败了。因此我们还需要一个方法来检测数据不一致的数量，为了做到这点，我们新建了一个定时任务去scan两地的数据做对比统计，如果发现有不一致的还能及时修复掉。
项目上线后，我们也取得一些成果，首先性能提升非常明显，异地的调用平均耗时和TP99、TP999均至少下降80%，并且在一次线上专线故障期间，账号读服务对外的可用性并没有受影响，避免了更大范围的损失。
总结
服务的高可用需要持续性的投入与维护，比如我们会每月做一次容灾演练。高可用也不止体现在某一两个重点项目上，更多的体现在每个业务开发同学的日常工作里。任何一个小Bug都可能引起一次大的故障，让你前期所有的努力都付之东流，因此我们的每一行代码，每一个方案，每一次线上改动都应该是仔细推敲过的。高可用应该成为一种思维方式。最后希望我们能在服务高可用的道路上越走越远。
本文转载自美团技术团队微信公众号，转载授权请联系原创作者（meituantech）！
