建网站与发布网站,西安百度seo推广,网站建设哪家公司,福田做商城网站建设哪家便宜引言 在任何一家互联网公司#xff0c;不管其主营业务是什么#xff0c;都会有一套自己的账号体系。账号既是公司所有业务发展留下的最宝贵资产#xff0c;它可以用来衡量业务指标#xff0c;例如日活、月活、留存等#xff0c;同时也给不同业务线提供了大量潜在用户… 引言 在任何一家互联网公司不管其主营业务是什么都会有一套自己的账号体系。账号既是公司所有业务发展留下的最宝贵资产它可以用来衡量业务指标例如日活、月活、留存等同时也给不同业务线提供了大量潜在用户业务可以基于账号来做用户画像制定各自的发展路径。因此账号服务的重要性不言而喻同时美团业务飞速发展对账号业务的可用性要求也越来越高。本文将分享一些我们在高可用探索中的实践。 衡量一个系统的可用性有两个指标 MTBF (Mean Time Between Failure) 即平均多长时间不出故障MTTR (Mean Time To Recovery) 即出故障后的平均恢复时间。通过这两个指标可以计算出可用性也就是我们大家比较熟悉的“几个9”。 因此提升系统的可用性就得从这两个指标入手要么降低故障恢复的时间要么延长不出故障的时间。 1. 业务监控 要降低故障恢复的时间首先得尽早的发现故障然后才能解决故障这些故障包括系统内和系统外的这就需要依赖业务监控系统。 业务监控不同于其他监控系统业务监控关注的是各个业务指标是否正常比如账号的登录曲线。大众点评登录入口有很多从终端上分有App、PC、M站从登录类型上分有密码登录、快捷登录、第三方登录微信/QQ/微博、小程序登录等。需要监控的维度有登录总数、成功数、失败分类、用户地区、App版本号、浏览器类型、登录来源Referer、服务所在机房等等。业务监控最能从直观上告诉我们系统的运行状况。 由于业务监控的维度很多很杂有时还要增加新的监控维度并且告警分析需要频繁聚合不同维度的数据因此我们采用ElasticSearch作为日志存储。整体架构如下图 每条监控都会根据过去的业务曲线计算出一条基线见下图用来跟当前数据做对比超出设定的阈值后就会触发告警。 每次收到告警我们都要去找出背后的原因如果是流量涨了是有活动了还是被刷了如果流量跌了是日志延时了还是服务出问题了另外值得重视的是告警的频次如果告警太多就会稀释大家的警惕性。我们曾经踩过一次坑因为告警太多就把告警关了结果就在关告警的这段时间业务出问题了我们没有及时发现。为了提高每条告警的定位速度我们在每条告警后面加上维度分析。如下图非真实数据告警里直接给出分析结果。 其实业务监控也从侧面反映出一个系统的可用性所谓服务未动监控先行。 2. 柔性可用 柔性可用的目的是延长不出故障的时间当业务依赖的下游服务出故障时不影响自身的核心功能或服务。账号对上层业务提供的鉴权和查询服务即核心服务这些服务的QPS非常高业务方对它们的可用性要求也很高别说是服务故障就连任何一点抖动都是不能接受的。对此我们先从整体架构上把服务拆分其次在服务内对下游依赖做资源隔离都尽可能的缩小故障发生时的影响范围。 另外对非关键路径上的服务故障做了降级。例如账号的一个查询服务依赖Redis当Redis抖动的时候服务的可用性也随之降低我们通过公司内部另外一套缓存中间件Cellar来做Redis的备用存储当检测到Redis已经非常不可用时就切到Cellar上。通过开源组件Hystrix或者我们公司自研的中间件Rhino就能非常方便地解决这类问题其原理是根据最近一个时间窗口内的失败率来预测下一个请求需不需要快速失败从而自动降级这些步骤都能在毫秒级完成相比人工干预的情况提升几个数量级因此系统的可用性也会大幅提高。下图是优化前后的对比图可以非常明显的看到系统的容错能力提升了TP999也能控制在合理范围内。 对于关键路径上的服务故障我们可以减少其影响的用户数。比如手机快捷登录流程里的某个关键服务挂了我们可以在返回的失败文案上做优化并且在登录入口挂小黄条提示让用户主动去其他登录途径这样对于那些设置过密码或者绑定了第三方的用户还有其他选择。 具体的做法是我们在每个登录入口都关联了一个计数器一旦其中的关键节点不可用就会在受影响的计数器上加1如果节点恢复则会减1每个计数器还分别对应一个标志位当计数器大于0时标志位为1否则标志位为0。我们可以根据当前标志位的值得知登录入口的可用情况从而在登录页展示不同的提示文案这些提示文案一共有2^532种。 下图是我们在做故障模拟时的降级提示文案 3. 异地多活 除了柔性可用还有一种思路可以来延长不出故障的时间那就是做冗余冗余的越多系统的故障率就越低并且是呈指数级降低。不管是机房故障还是存储故障甚至是网络故障都能依赖冗余去解决比如数据库可以通过增加从库的方式做冗余服务层可以通过分布式架构做冗余但是冗余也会带来新的问题比如成本翻倍复杂性增加这就要衡量投入产出比。 目前美团的数据中心机房主要在北京上海各个业务都直接或间接的依赖账号服务尽管公司内已有北上专线但因为专线故障或抖动引发的账号服务不可用间接导致的业务损失也不容忽视我们就开始考虑做跨城的异地冗余即异地多活。 3.1 方案设计 首先我们调研了业界比较成熟的做法主流思路是分set化优点是非常利于扩展缺点是只能按一个维度划分。比如按用户ID取模划分set其他的像手机号和邮箱的维度就要做出妥协尤其是这些维度还有唯一性要求这就使得数据同步或者修改都增加了复杂度而且极易出错给后续维护带来困难。考虑到账号读多写少的特性读写比是350:1我们采用了一主多从的数据库部署方案优先解决读多活的问题。 Redis如果也用一主多从的模式可行吗答案是不行因为Redis主从同步机制会优先尝试增量同步当增量同步不成功时再去尝试全量同步一旦专线发生抖动就会把主库拖垮并进一步阻塞专线形成“雪崩效应”。因此两地的Redis只能是双主模式但是这种架构有一个问题就是我们得自己去解决数据同步的问题除了保证数据不丢还要保证数据一致。 另外从用户进来的每一层路由都要是就近的因此DNS需要开启智能解析SLB要开启同城策略RPC已默认就近访问。 总体上账号的异地多活遵循以下三个原则 北上任何一地故障另一地都可提供完整服务。北上两地同时对外提供服务确保服务随时可用。两地服务都遵循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都可能引起一次大的故障让你前期所有的努力都付之东流因此我们的每一行代码每一个方案每一次线上改动都应该是仔细推敲过的。高可用应该成为一种思维方式。最后希望我们能在服务高可用的道路上越走越远。 团队简介 账号团队拥有一群朝气蓬勃的成员堂堂、德鑫、杨正、可可、徐升、艳豪虽然他们之中有些刚毕业不久但技术上都锐意进取在讨论技术方案时观点鲜明大家都充分地享受着思想碰撞的火花这个年轻的团队在一起推进着高可用项目的进行共同撑起了账号服务的平稳运行及业务发展。 招聘信息 如果你觉得我们的高可用仍有提升空间欢迎来大众点评基础平台研发组。如果你想更深入学习高可用的技术细节欢迎来大众点评基础平台研发组。如果你想遇到一群志同道合的技术开发欢迎来大众点评基础平台研发组。简历传送门tangtang.sha#dianping.com。
