面向业务的立体化高可用架构设计Word格式.docx
- 文档编号:13539476
- 上传时间:2022-10-11
- 格式:DOCX
- 页数:11
- 大小:507.96KB
面向业务的立体化高可用架构设计Word格式.docx
《面向业务的立体化高可用架构设计Word格式.docx》由会员分享,可在线阅读,更多相关《面向业务的立体化高可用架构设计Word格式.docx(11页珍藏版)》请在冰豆网上搜索。
阿里九游游戏接入系统(以下简称“游戏接入系统”)负责所有九游平台游戏的接入(包括用户的登录、注册、支付等业务,也包括游戏开发商(以下简称“CP”)用户验证、支付等业务),对可用性的要求非常高,一旦故障,大量用户就不能愉快的玩游戏,投诉就会满天飞,论坛就被报障的帖子刷爆了,因为对于很多用户来说,不上微信可能问题不大,但要是几小时不能玩游戏,那就要爆粗口了。
如何保证游戏接入系统的高可用,让用户能够愉快的玩游戏,成为了我们的一个巨大的挑战。
为了实现游戏接入业务的高可用,我们跳出传统的面向系统的高可用的思路,转而从业务的角度来整体考虑高可用,最终实现了一套“立体化的高可用架构”。
接下来我将逐一展示这套立体化高可用架构的一些具体实践。
一、面向业务的高可用目标
业界高可用的通用指标是几个9,例如5个9代表一年业务不可用的时间是5分钟,4个9代表一年业务的不可用时间是50分钟。
我们最初也是使用这个指标来作为我们高可用的目标,但是在实际的操作和讨论过程中,发现这几个指标虽然简单,但是并不能直观的理解,而且对于我们分析问题和设计方案没有很强的指导意义,因此我们决定找更加容易理解和操作的目标。
但说起来容易做起来难,高可用本身就是一个主观色彩比较强的概念,不同的人理解都不一致,要确定一个更加容易理解和操作、大家又能达成一致意见的目标,竟然成了我们首要面对的难题。
我们先后讨论了多次,前后使用了“提高可用性”、“具备XX能力”、“解决存在的可用性问题”……等多个目标,但这些目标最后都被否决了,主要原因就是我们的BOSS认为这些都没法量化,没法评估,不能认为做了事情就一定能够达到目标。
当时研发团队和BOSS还有一点小分歧:
研发团队认为除了几个9外,高可用没法量化;
而BOSS认为一切都可以量化,只是我们还没找到方法。
不得已,团队又继续头脑风暴,功夫不负有心人,终于在一次讨论中想出了一个可量化可衡量的高可用目标:
3分钟定位问题、5分钟恢复业务、平均最多2个月发生一次问题,这样计算下来一年不可用的时间大约就是50分钟,正好契合4个9的业界通用的可用性目标。
在后来的项目执行过程中,我们发现这个目标真的是非常有用,非常具有指导意义,具体表现为:
目标聚焦于业务,而不是聚焦于技术,确保最终效果不会走偏
将目标自顶向下分解,很容易就得出要做的事情了
设计和讨论方案时,目标就是一根准绳,是否可行,拿这个目标一衡量就很清晰了
后来的项目总结时,我们都认为这个目标是项目成功的第一关键。
二、立体化的高可用架构设计
将我们的高可用目标分解一下,其实有3个子目标:
1.尽量避免发生问题
不出问题当然是高可用的首要目标了,不然的话天天出问题,处理再快也没意义。
2.快速定位问题
出了问题要能够快速发现和定位,不要报警或者用户投诉过来后还要花半天才能定位问题,在问题发生后尽快定位初步的原因所在,尽快处理问题,防止问题恶化。
3.快速恢复业务
特别注意这里我们强调的是“恢复业务”,而不是“解决问题”。
很多人在处理生产问题或者故障的时候有一个误区:
那就是一定要找到问题根因,然后解决。
实际上大部分的时候这样做都很难的,也很耗费时间。
比如说某个机器响应很慢,可能的原因有:
机器磁盘有问题、机器的CPU被耗光了、这台机器上的程序陷入死循环、jvm垃圾回收时间较长......要在短短几分钟内排查这么多可能的原因是很难的,但我们不知道真正的原因也可以恢复业务,比如说最简单的是直接把这台机器立刻下线,让流量分配到其它的机器。
当我们审视这3个目标的时候,就会发现没有哪个系统的架构能够独立的满足这目标,必须从业务的角度全方位、立体化的来分析和设计高可用方案。
结合我们的业务,最终的架构实现方案如图1所示。
通过这个图我们可以看到,这个架构设计方案并不是传统意义上的软件架构,而是一个高可用的业务架构,真正和传统系统架构相关的就只有“异地多活”,其它的功能或者系统并不属于狭义上的架构设计范畴,但这些功能和系统组合起来,共同保障了业务的整体高可用。
三、客户端重试+HTTP-DNS
当我们的业务发生问题的时候,用户侧肯定是感知最快的,如果能够在用户侧感知并立刻处理,问题的影响将大大降低。
用户侧最简单的处理问题就是重试,当遇到某些错误的时候用户侧再重试一次,错误可以是通用的错误,例如HTTP404/500,也可以是业务上的错误码,只需要客户端和服务端预先约定即可。
用户侧重试是处理问题速度是最快的,但一个最大的问题就是DNS的不可靠性。
简单来说,如果通过DNS拿到了错误的主机地址,即使重试也一样同样是错误的。
导致DNS错误的原因主要有如下几种:
1.用户侧DNS被劫持,hosts被篡改
如下是我们的域名在用户机器上被篡改的实例,可以看到我们的域名被篡改成了127.0.0.1。
2.缓存DNS服务器污染,返回客户端错误IP
2014年1月21日下午3点,国内顶级域的根服务器出现异常,许多知名网站的域名均被劫持到一个错误的IP地址上,至少有2/3的国内网站受到影响,用户无法正常访问。
根服务器恢复后,由于DNS缓存问题,部分地区用户“断网”现象仍持续了几个小时。
3.DNS缓存时间较长,短则10分钟,长则几小时
DNS的解析机制为了提升效率,在很多地方会有缓存,例如本机的缓存,DNS服务器上的缓存。
缓存带来了效率上的提升,但同时却给故障处理带来了不小的麻烦,即:
当我们将故障的机器下线或者将DNS指向的主机地址修改以后,用户并不能立刻感知新的主机地址,在缓存有效期内还是会继续访问旧的主机。
DNS的这几个问题虽然我们都很清楚,但是也无能为力,因为我们不能控制DNS的设备,也不能修改DNS的实现机制。
要想解决这个问题,只能另想办法,我们的解决方案就是HTTP-DNS。
故名思议,HTTP-DNS就是通过HTTP的方式来自己实现一套DNS的功能,简单来说就是客户端通过HTTP接口来获取指定域名对应的主机地址,而不再通过传统的DNS设备来获取主机地址。
相比传统DNS,HTTP-DNS具备如下优势:
1.自己实现,控制力度强,可以根据业务特点灵活实现
可以根据业务进行细粒度的调度,例如发现A业务某个集群请求量较多,可以动态的将请求分配到其它集群。
2.更新快,故障处理及时
当更新域名对应的主机信息后,客户端能够立刻拿到最新的信息。
例如下线一台机器后,客户端再来获取主机地址就不会获取已经下线的机器地址,能够实现秒级的故障处理速度。
当然,HTTP-DNS的这些优势是在特定场景下才能体现的,并不能完全取代传统的DNS。
因为如果每次访问都先通过HTTP-DNS拿取主机地址的话,效率和性能都太低,对于手机类智能设备还会导致耗电和流量增加。
因此我们需要结合传统DNS和HTTP-DNS的优势,既要保证大部分情况下的性能和效率,也要保证异常情况下的故障快速处理。
具体的做法为:
正常情况下我们通过传统DNS完成业务请求,异常重试的时候通过HTTP-DNS完成请求。
如图3所示简要的说明了整体流程。
四、功能分离+功能降级
我们的高可用目标中,首要的目标就是“尽量避免发生问题”,但对于如何避免发生问题,刚开始的时候团队并没有明确的方向,有的同学从项目管理角度提出“结对编程”、“上线评审”等流程保障机制;
也有同学从测试角度提出“加强测试力度”、“自动化测试”等测试手段;
我们甚至还想到了“提升人员水平”这些人力资源措施......但这些措施都强依赖于人的因素,而人的因素往往是最不可控的,相比之下,我们认为通过技术的手段是更可控的,所以制定了“技术驱动”的整体策略。
通过对系统业务的仔细分析,以及对过往线上故障的问题的分析,我们制定了“功能分离+功能降级”的方案,具体解释如下;
1.功能分离:
划分核心功能和非核心功能,将核心功能和非核心功能物理隔离
这里有两个关键点:
首先要区分核心功能和非核心功能。
例如我们的游戏接入业务中,登录、注册、校验是核心功能,消息推送、日志上报等是非核心功能。
核心功能是用户玩游戏必须的,核心功能一旦有问题,玩家就不能玩游戏了;
而非核心功能即使有问题,暂时也不会立刻影响玩家玩游戏,而往往非核心功能的变动反而比较频繁。
因此,优先保证核心功能正常,是我们首要的目标。
其次是物理隔离。
包括数据库、服务器、缓存等都要隔离,因为只要核心功能和非核心功能存在共享的资源,就有可能因为非核心功能影响核心功能。
举个最简单的例子,如果数据库共用一套,那么非核心功能如果出现了大量的整表查询,核心功能同样受到影响。
整体的架构示意见图4。
2.功能降级:
当出现故障的时候,可以将非核心功能直接降级,保护核心功能不受影响
拆分为核心功能和非核心功能后,虽然物理上两者隔离了,但有的业务还是需要核心功能和非核心功能配合才能完成,这就存在了一定的风险。
比如说消息下发(非核心功能)需要获取用户的信息(核心功能),如果大量消息下发的话,就会给核心业务系统产生较大的压力。
这种情况下我们可以通过将非核心功能停掉,以保证核心功能不受影响。
将某个功能停掉的传统方式就是打patch,但做过的同学都知道,这样做的效率太低了:
研发改代码、测试验证、运维部署,一路走下来,至少1小时以上,还容易出错,而且事后还要打另外一个patch恢复功能。
为了实现“5分钟恢复业务”的目标,我们开发了一个后台管理程序,当需要停用某个功能的时候,只需要在后台上点击一个按钮就能够完成,花费时间只需要几秒钟。
五、异地多活
通常我们讲系统架构的时候,异地多活往往都是最吸引人的,因为异地多活看起来很美好,一个机房故障,其它机房能够完全接管业务,故障处理简单快速。
但异地多活往往实现都是很复杂的,其复杂性不是体现在业务处理层面,而是体现在数据处理层面。
简单来说:
异地多活需要保证数据的一致性和实时性,但异地机房间的距离天然决定了了数据的一致性和实时性是无法保证的。
目前业界常见的异地多活方案总体上可以分为两种:
1.跨城多机房
在不同的城市搭建多个机房,机房间通过网络进行数据复制(例如MySQL主备复制),但由于跨城网络时延的问题,业务上需要做一定的妥协和兼容,不需要数据的实时强一致性,保证最终一致性。
例如微博类产品,B用户关注了A用户,A用户在北京机房发布了一条微博,B在广州机房不需要立刻看到A用户发的微博,等10分钟看到也可以。
这种方式实现简单,但和业务有很强的相关性,例如微博可以这样做,支付宝就不能这样做。
2.同城多机房
同一个城市多个机房,距离不会太远,可以投入重金,搭建私有的高速网络,基本上能够做到和同机房一样的效果。
这种方式对业务影响很小,但投入较大,如果不是土豪公司,一般
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 面向 业务 立体化 可用 架构 设计