高可用性系统在大众点评的实践与经验

高可用性系统在大众点评的实践与经验

by 井底之蛙, mp.weixin.qq.comJanuary 21

微信号 afroginwell

功能介绍 把你的第一次留在这里,在这里可以也看到别人的第一次

本文主要以点评的交易系统的演进为主来描述如何做到高可用,并结合自己的经验作些分享。高可用性只是一个结果,要更多的关注迭代过程,关注业务发展。

主要从下面几个方面来分享

  • 可用性的理解

1. 理解目标

2目标分解

  • 频率要低

1. 高可用性的设计

2.易运营&测试

3.关注发布

  • 时间要快

1.持续关注运行时

2.充分利用故障时

  • 几点经验

1.珍惜每次大流量机会

2.复盘

3.可用性不只是技术问题

4.可用性最大的敌人

一、可用性的理解

1.理解目标

业界高可用的目标是几个9,对于每一个系统的要求是不一样的,对研发人员来说,要对设计或者开发的系统知道其用户规模及使用场景,知道可用性的目标。

比如59的目标能分解:全年故障5分钟。

2.拆解目标

几个9的目标比较抽象,需要对目标进行合理的分解,可以分解成如下两个子目标

2.1 频率要低:减少出故障的次数。

不出问题,一定是高可用的,但这是不可能的。系统越大、越复杂,只能尽量避免问题,通过系统设计,流程机制来减少这种问题概率。但如果经常出问题,后面的恢复再快也是没有用的。

2.2 时间要快:故障恢复时间要快

故障出现时,不是解决或者定位到具体问题,而是快速恢复是第一要务的,防止次生灾害,问题扩大。这里就要求要站在业务角度思考,而不仅是技术角度思考。

二、频率要低:减少出故障的次数

1.高可用性的设计:根据业务变化不断进行迭代。

以点评交易系统的演进过程举例

1)幼儿时期:2012年前。

使命:满足业务要求,快速上线。

因为2011年要快速的把团购产品推向市场,团队都是临时从各个团队抽取的人才,大部分对.net更熟悉,所以使用.net进行了第一代的团购系统设计,满足业务要求是第一的,还没有机会遇到可用性等质量问题。考虑比较简单,要挂都挂了,量也比较小,出现问题,重启,扩容,回滚就解决问题了。

系统长成下图这样:

2)少年时期:垂直拆分(2012-2013

使命:研发效率&故障隔离

2012年在团单量从千到万量级变化,用户每日的下单量也到了万级时候,需要考虑的是迭代速度,研发效率。所以要做小而美的团队。另外一方面也需要将各个业务相互隔离,比如商品首页的展示,商品详情页的展示,订单、支付流程的稳定性要求不一样。前面可以缓存,可以做静态化来保证可用性,提供一些柔性体验。后面支付系统做异地容灾,比如我们除了南汇机房支付系统,在宝山机房也部署了,只是后来发现这个系统演进太快,没有工具和机制保证双机房更新,所以后来也不好使用了。

系统演进成下图这样:这个就是服务垂直化了,但是数据没有完整隔离开,互相摸。

3)青年时期:服务做小,不共享数据(2014-2015

使命:支撑业务快速发展,提供高效、高可用的技术能力

2013年开始,deal-service (商品系统)偶尔会因为某一次大流量(大促,常规活动)会挂,每几个月总有那么一次。基本上可用性就在39徘徊,这里订单和支付系统很稳定的,因为流量在商品详情页到订单有一个转化率,流量大了详情页就挂了,订单也就没有流量了,后来做了详情的静态化做得比较好了,能减少恢复的速度,能降级,但是deal-service的各个系统依赖太深了,还是不能保证整体端到端的可用性。

所以2014deal-service就做了很大的重构,大系统做小,把商品详情系统拆成了无数小服务,比如库存服务,价格服务,基础数据服务等等。这下商品详情页的问题解决了,所以从2014年低订单系统的压力就来了,前面好了,后面压力就来了。201410月起,订单系统,支付系统也启动了全面微服务化,经过大约1年的实践,订单系统、促销系统、支付系统这3个领域后面的服务总和都快上百个了,后面对应的数据库20多个,这样能支撑到每日订单量百万级。

业务的增长在应用服务层面是可以扩容的,但是最大的单点,数据库是集中式的,这个阶段我们主要是把应用的数据访问在读写上分离,数据库提供更多的从库解决读的问题,但是写入仍然式最大的瓶颈(mysql的读可以扩展,写入QPS 也就小2万)

系统演变成下图这样:这个架构大约能支撑QPS 3000左右的订单量。

4)成年时期:水平拆分(2015-现在)使命:

系统要能支撑大规模的促销活动,订单系统能支撑每秒几万的QPS,每日上千万的订单量。

2015年的917吃货节,流量最高峰,如果我们仍然是前面的技术架构,必然会挂掉,所以在917这个大促的前几个月,我们就在订单系统进行了架构升级,水平拆分,核心就是解决数据单点,把订单表拆分成了1024张表,分布在32个数据库,每个库32张表。这样能支撑到我们能看见到未来了。

虽然数据层的问题解决了,但是我们还是有些单点,我们用的MQ,网络,机房等。举几个曾经我过去遇到的不容易碰到的可用性问题:

1)服务的网卡有一个网卡坏了,没有被监测到,后来发现另一个网卡也坏了,这样服务就挂了。

2)我们使用 cache的时候发现可用性在高峰期非常低,后来发现这个cache服务器跟公司监控系统cat服务器在一个机柜,高峰期的流量被cat跑了一大半,给业务的网络流量就非常少,就影响了业务。

3917大促的时候我们对MQ这个依赖的通道能力评估出现了偏差,也没有备份方案,所以造成了一小部分的延迟。

这个时期系统演进下图这样:

5)未来:思路仍然是大系统做小,基础通道做大,流量分块。

大系统做小,就是把复杂系统拆成单一职责系统,并从单机、主备、集群、异地等架构方向扩展。

基础通道做大就是把基础通信框架,带宽等高速路做大。

流量分块就是把用户流量按照某种模型拆分,让他们聚合在某一个服务集群完成,闭环解决。

系统可能会演变下下图这样:

上面点评交易系统的发展几个阶段,只以业务系统的演进为例,除了这些还有CDN,DNS、网络、机房等各个时期遇到的不同的可用性问题,我们遇到过的问题,比如:联通的网络挂了,需要切换到电信;比如数据库的电源被人踢掉了。

2.易运营

高可用性的系统一定是可运营的,听到运营,大家更多的想到的是产品运营,其实技术的运营指的是线上的质量,流程能否运营,比如,整个系统上线后,是否方便切换流量,是否方便开关,是否方便扩展。这里有几个基本要求:

1)可限流

线上的流量永远有想不到的情况,在这种情况下,系统的稳定吞吐能力就非常重要了,高并发的系统一般采取的策略是快速失败机制,比如系统QPS能支撑5000,但是1万的流量过来,我能保证持续的5000,其他5000我快速失败,这样很快1万的流量就被消化掉了。比如917的支付系统就是采取了流量限制,如果超过某一个流量峰值,我们就自动返回请稍后再试等。

2)无状态

应用系统要完全无状态,运维才能随便扩容,分配流量。

3)降级能力

降级能力是跟产品一起来看的,需要看降级后,对用户的体验的影响,简单的比如,提示语是什么,比如我们支付渠道,如果支付宝渠道挂了,我们挂了50% ,我们支付宝的渠道是旁会自动出现一个提示,这个渠道可能不稳定,但是可以点击;当支付宝渠道挂了100% ,我们的按钮是灰色的,不能点击。也会有提示,比如换其他支付渠道(刚刚微信支付还挂了,就又起作用了)。另一个案例,我们在啊917大促的时候对某些依赖方,比如诚信的校验,这种如果判断比较耗资源,又可控的情况下,可以通过开关直接关闭或者启用。

3.可测试

无论架构多么完美,验证这一步必不可少,系统的可测试行就非常重要。

测试的目的要先预估流量的大小,比如某次大促,要跟产品、运营讨论流量的来源,活动的力度,每一张页面的,每一个按钮的位置,进行较准确的预估。

再测试集群的能力,有很多同学在实施的时候总喜欢测试单台,然后水平放大,给一个结论,但这不是很准确,要分析所有的流量是否在系统间流转时候的比例。尤其对流量模型的测试(要注意高峰流量模型跟平常流量模型可能不一致的)系统架构的容量测试,比如我们某一次大促的测试方法

从上到下评估流量,从下至上评估能力:发现一次订单提交 有20次数据库访问,读写比例高峰期是1:1,然后就跟进数据库的能力倒推系统应该放入的流量,然后做好前端的异步下单,让整个流量平缓的下放到数据库。

4. 降低发布风险

4.1 严格的发布流程

目前点评的发布都是开发自己负责的,通过平台自己完成的,上线的流程,发布的常规流程模版:

4.2 灰度机制

1)服务器发布是分批,按照10%30%50%100%的发布,开发通过观察监控系统的曲线,及系统的日志确定业务是否正常。

2)线上的流量灰度机制,重要功能上线能有按照某种流量灰度上线能力

3)可回滚是标配,最好有最坏情况的预案。

三、时间要快 :故障恢复时间要快

如果目标就要保证全年不出故障或者出了故障在5分钟之内能解决,要对5分钟进行充分的使用,对5分钟的拆解:1分钟发现故障,3分钟定位故障出现在哪个服务,再加上后面的恢复时间。就是整个时间的分解,目前我们系统大致能做到前面2步,离整体59的目标还有差距,因为恢复的速度跟架构的设计,信息在开发、运维、DBA之间的沟通速度及工具能力,及处理问题人员的本身能力有关。

生命值:

1.持续关注线上运行情况

1)熟悉并感知系统变化,要快就要熟,孰能生巧,所以要关注线上运营情况。

对应用所在的网络、服务器性能、存储、数据库等系统指标了解。

能监控应用的执行状态、对应用的自己QPS、响应时间、可用性指标,并对依赖的上下游的流量情况同样熟悉。

2)保证系统稳定吞吐 :系统如果能做好流量控制,容错,保证一个稳定的吞吐,能保证大部分场景的可用,也能很快的消化高峰流量,避免出现故障,产生流量的多次高峰。

2.故障时

2.1.快速的发现机制

1)告警的移动化 :系统可用性的告警应该全部用微信、短信这种能保证找到人的通信机制。

1)告警的实时化:目前我们只能做到1分钟左右告警。

3)监控的可视化:我们的系统目前的要求是1分钟发现故障,3分钟定位故障:这就需要做好监控的可视化,在所有关键service里面的方法层面打点,然后做成监控曲线,不然3分钟定位到具体是那个地方出问题,比较困难。点评的监控系统cat能很好的提供这些指标变化,我们系统再这些基础上也做了一些更实时的能力,比如订单系统的我们的QPS 就是开发的秒级的监控曲线。

2.2.有效的恢复机制

比如运维的四板斧:回滚、重启、扩容、下服务器。在系统不是很复杂,流量不是很高的情况下,这能解决问题,当大流量的时候这个就很难解决了,所以更多的从流量控制、降级体验方面下功夫。

四 、几点经验

1.珍惜每次真实高峰流量,建立高峰期流量模型。

2.珍惜每次线上故障复盘,上一层楼看问题,下一楼解决问题。

3.可用性不只是技术问题

系统初期是:以开发为主;

系统中期是:开发+DBA+运维为主;

系统后期是:技术+产品+运维+DBA

4.单点和发布是可用性最大的敌人

Original Page: http://mp.weixin.qq.com/s?__biz=MzIxMjE3NTg2NA==&mid=404115389&idx=1&sn=dc3d81583c4d2c3c07d6a563880235dd&scene=4#wechat_redirect

Shared from Pocket

北京联通光猫华为HG8346R破解方案大公开

北京联通光猫华为HG8346R/HG8321R破解方法介绍
北京联通的华为HG8346R是我接触的第一个光猫,因为2015年7月初刚刚进行了光改。原以为光纤安装完毕后就很简单,哪料到此光猫为路由模式了,客户只有普通用户权限,里面的设置就是供你看看,想加点常用的诸如端口映射、开UPnP等都是不行,PT下载就不给力了,于是决定破解。 去X宝上问了问,发现都说这个猫很难破解,只有一个人说可以,叫价80元。 本来我以前就是搞软件的,反正最近也不是很忙,求人不如求己。经过20多天的研究,终于搞定此光猫,同时还学习和掌握了较多的华为光猫的设置以及破解知识。
北京联通华为HG8346R固件基本的情况
固件版本为 V300R013C10S112
此猫破解的难点: 
① hw_ctree.xml 配置文件里面没有超级管理员账户,即使长按RESET恢复出厂模式后也是一样。 没有电信光猫那样恢复出厂模式后有 telecomadmin 超级管理员账户,也没有像其它地区联通光猫那样有 CUAdmin 账户。
以下摘自解码后的hw_ctree.xml配置文件:
-<X_HW_WebUserInfo NumberOfInstances="1">
<X_HW_WebUserInfoInstance InstanceID="1" Enable="1" Password="h559fvxj" ModifyPasswordFlag="0" UserLevel="1" UserName="user"/>
</X_HW_WebUserInfo>
可以看到web登录只有一个 user 账户,用户密码为明文,并且没有更改过。
另一台光猫:
-<X_HW_WebUserInfo NumberOfInstances="1">
<X_HW_WebUserInfoInstance InstanceID="1" Enable="1" Password="5930f2851b57a9d83d341882b97f66480abbce1821fe0bb55a592412175045fa" PassMode="2" ModifyPasswordFlag="1" UserLevel="1" UserName="user"/>
</X_HW_WebUserInfo>
可以看到web登录只有一个 user 账户,用户密码是用MD5+SHA256双重加密的,这是以后一段时间华为光猫配置文件解码出来的主流了。 MD5和SHA256是不能逆向破解的,只能暴力破解。所以如果密码的明文是复杂密码的话,想破解几乎不可能。
② 配置文件解密后,其中凡是存放密码的部分仍然是密文的形式存在的。因此也无法通过解密hw_ctree.xml方式后看到诸如语音鉴权密码等重要信息。
ManagementServer Password="$1I!xxEnCH.)l’k:*fsfL72g%!$" Username="cpe" X_HW_DSCP="0" X_HW_CertPassword="$16haQJY=:U’R`cLQi}aR>2g%!$" 
ConnectionRequestPassword="$17sy(~.fgSLvGQX3$2R<G2g%!$" ConnectionRequestUsername="acs"
+<SIP URI="+861063551238" AuthPassword="$15p’W*q[of4x|[dK*_RI+1g%!$" AuthUserName="+861063551238@bj.ims.chinaunicom.cn">
上面这个是与语音功能非常相关的鉴权密码部分
破解北京联通华为HG8346R所需要的工具软件
① 华为光猫ONT维修使能工具
由于北京联通华为HG8346R的固件是V300R013C10S112,因此随便在网上搜寻一下都可以找到2014年12月出的使能工具并下载(本论坛上也有,不过需要猫粮),就可以打开此光猫的Telnet。 而如果你的光猫已经是R013C10S121及以后和R015版本的固件的话,需要使用更新版本的ONT使能工具了。
② tftp32
用于备份配置文件,可以到: tftpd32.jounin.net 下载。 
③ Windows下的华为配置文件解密和加密工具
这个工具可以在Windows下对华为hw_ctree.xml进行处理,可以解密解压缩成为明码的形式,同时也可以加密压缩还原为原始的形式。相当于华为光猫中的 aescrypt2 命令。
④ su密码算号器 (R015版本不需要)
用于计算su密码,进入su_wap模式。 
破解北京联通华为HG8346R方法
① 使用华为光猫ONT使能工具打开Telnet
② 进入Telnet后 (用户名:root 密码:admin),使用backup cfg 命令备份出自己光猫的配置文件 hw_ctree.xml (配合tftp32)
备份配置文件对于无损破解光猫,还原你光猫原有设置起非常重要的作用。它至少有以下几方面的用途:
⒈ 光猫破解完成后,将稍加修改(主要是超级用户的密码部分)的配置文件重新导入回光猫里面,使光猫恢复原先光猫里面所有的设置,因此再不用担心语音不行、ITV不行、上网不行了。
⒉ 你要是自己换猫的时候,如果更换的也是华为基本同类型的猫的话,直接将原来的配置文件导入新猫里面去,原来猫里面的所有设置一下就在新猫里面设置好了。
⒊通过对原配置文件以密文形式存放的诸如语音鉴权密码等信息进行解密得到密码明文,即使在你更换其它厂家,比如中兴、烽火的光猫的时候,同样可以配置成功,保留原猫的所有功能。
因此我个人感觉:如果自己光猫的配置文件在手,有走到哪里都不怕的赶脚啦。因此备份配置文件非常重要。
③ 得到配置文件后可以使用SU命令,然后输入su的密码提权后,通过一些命令将光猫恢复为华为界面。
④ 使用hw_ctree.xml配置文件解密工具将其解码后,将其中的UserLevel="1"修改为 UserLevel="0" ,即将user用户变更为管理员权限用户
<X_HW_WebUserInfoInstance InstanceID="1" Enable="1" Password="h559fvxj" ModifyPasswordFlag="0" UserLevel="0" UserName="user"/>
其中的Password项也可以修改为自己需要的密码。 然后再使用配置文件工具将配置文件加密压缩还原成为华为光猫里面的状态,从而便于今后导入光猫中。
其中C2为配置文件加密解密工具(命令行使用), guo.xml 是从光猫导出的hw_ctree.xml 配置文件, 通过C2工具先解码成为 guojiemi.xml 然后用记事本修改后,再通过c2工具加密还原成为guojiami.xml文件。
⑤重新启动光猫后,已经恢复为华为登录界面,并且有telecomadmin超级用户权限,登录进去以后,使用配置文件导入功能将上面生成的guojiami.xml配置文件导入即可。光猫重新启动后,以前的所有设置全部恢复回来了。
恢复到华为界面后功能强大(同时比电信和联通界面下超级管理员的功能还多一些)。
路由和桥接可以自由选择
端口映射可以设置
有些人很关心的连接电脑台数的限制可以修改,也可以不启用。
其实经过这段时间研究后才发现,这个北京联通的华为HG8346R在破解上算是不难的,而X宝上只有很少人能够破解,说明X宝上光猫破解人的水平大部分也都一般。经过进一步深入的研究,目前可以说即使安装了最新固件版本的猫(比如R013C10S123或者R015),也有方法搞定,同时光猫的语音鉴权密码也有方法可以解码。有需要技术支持的可以PM。

新的光猫安装的是 V300R015C10S109 或 V300R015C10S111 版本的固件,用同样的方法也可以搞定。