中国数字经济资讯与服务平台

想要多活又心疼钱?咋不瞧瞧青云的真正多活呢?

太阳每天照常升起,如果哪天太阳也出了故障,跟往常不一样了,那绝对是世界级大新闻,首先得庆幸这样的事情通常只会出现在科幻电影里。

Github是程序员的世界里类似的存在。2015年的统计数字显示,Github托管了5700万个代码仓库,有2800万个用户活跃在Github上,Github的用户对故障不陌生,每次Github出故障都能引起一番热议。最近一次故障中,Github的中断持续了24小时,用户无法提交代码更新,也没办法从Github下载最新版本的代码,正常的工作节奏完全被打乱了。

“星轨”可能是中国互联网服务商创造的新名词,说是新浪微博衡量服务器抗压能力的新单位,一星轨表示一个一线明星出轨给新浪微博所带来的流量,据说微博的服务器现在能同时抗击8星轨,类似的描述常见于描述楼梯的抗八级地震一样。不久前的“官宣”事件又一次突破了新浪微博服务器的承重,服务部分中断了,广大网友把官宣玩坏了,也顺带把新浪微博的技术人员又吓了一跳。

说了这么多,就只是想说,故障,宕机什么的,离我们普通人真的很近,这些上了新闻的只是其中一少部分,更多故障宕机之类的事件广大网友根本察觉不到,系统就被修复到能对外服务了,这类专门应对故障宕机的系统常见的就有多活系统。

多活系统通常是为了增强系统的可靠性、业务的连续性,使用业务运行不受故障/灾难影响。

Github也搭建了多活系统,结果多活系统出了故障。Github的两个机房的网络出现中断,服务发生切换中由于多活系统考虑不全,导致系统发生脑裂,两个机房的数据不一致。为了保证用户数据的一致性不得不停服,24小时之后数据才得以恢复。青云QingCloud运营副总裁林源向笔者介绍说。

故障之后多活系统就开始发挥作用了,评价多活水平的是RTO和RPO。RTO是指业务恢复时间,就好比玩游戏时卡的时候到恢复的时间段,游戏时最常见的应该是网络故障。RPO表示故障丢失的数据量,刚才完成的操作系统给丢了,比如你买了装备,一转眼故障后装备没了钱也没了,也可能是你击杀了别的玩家,一眨眼回来显示你输了。

玩游戏还好,要是偶尔银行故障的RTO、RPO的水平低了,也来这么一回,那事情可就大了。

双活虽然好,但是贵,建造也麻烦,好在不是谁都需要双活,比如你手里的手机偶尔莫名重启一下,那没啥事儿。

要是双十一的时候,明明零点抢到了特价iPhoneX MAX,一眨眼,钱也付了,订单丢了,店家说看不见,你说你付了钱,那不得哭啊。要是双十一的时候,下单的按钮始终点不了,钱一直付不了,每秒几十万、几百万、几千万订单额的商家不得哭晕在厕所吗?

要是银行的大型机也莫名其妙的重启了,那叫超级大事故,经济秩序可能就乱掉了。银行、保险、重型制造、电力等涉及国计民生的业务系统如果出现不可恢复的故障,那后果真实不堪设想。所以,这些场景要求数据不能丢。

林源介绍说,像银行的IT架构都需要符合银监会的规定,需要有两地三中心。所谓两地三中心,两地是指两个城市,三中心是指三个数据中心。同城的数据中心相互间是双活系统,异地的一个数据中心则主要负责备份,以此保障数据的安全性,业务的连续性。

两地三中心固然好,缺点就是贵。

前期投入在两个城市建三个数据中心,贵!三个机房的软硬设备,连接设备,贵!业务上线后,需要很多专门的运维人员,贵!

林源介绍说,建这么一套复杂的系统下来至少得一两年,时间就是金钱企业绝对。青云在构建北京大区、广东大区和上海大区的时候,每个区域、每个城市至少需要一年时间,就这还算快的。

通常所说的多活是指业务的多活,业务的多活是最终要求。他需要数据中心网络互通、数据安全、负载迁移等层面层层递进,底层任意一个环节出现问题,整套多活系统可能会崩溃。

GitHub多活系统也是煞费苦心,GitHub投入巨大,在两个数据中心间买了100G光纤做互联,做了非常充足的准备,结果还是出了问题。服务于技术人的网站也出现技术问题,听起来挺讽刺的,其实这也正说明了多活系统的复杂性。

从技术上来讲,多活的实施很难,从需求上来看,多活的需求很普遍。于是,公有云便开始提供共性的多活服务,青云就有这样的多活服务。

青云的多活服务有基础架构、基础设施和分布式应用三个层次组成。

其中,基础设施是指数据中心本身,指的是青云在北京,上海和广东建立的数据中心,一个地区的数据中心算一个Region,一个Region有多个可用区,比如北京有北京3B,北京3D,北京3C这样三个可用区。3个可用区之间的距离(30-50公里之间)可以满足银监会对银行数据中心的要求,另外,机房之间还需要有高速低延迟带宽支持。

在基础设施之上的是IaaS基础架构,IaaS层的多活服务一般都指的构建于多个数据中心之间的负载均衡服务,负载均衡器将接收到的负载分发到多个数据中心,任何单个数据中心故障都没什么影响。另外,多活系统的网络也很麻烦,没关系,青云自己的数据中心已经做好了。

多活系统最上一层的是分布式应用。其实这里说是应用不是特别合适,应用一般都是用户自己开发的,而青云所提供的通常来说是数据库(如果非要说数据库也是应用也可以),数据库很难,分布式数据库更难,有了分布式数据库之后数据库的多活就方便多了,将数据库分布在不同的可用区就能提供很好的多活数据库服务。青云的平台上支持自研的分布式数据库MySQL Plus,另外也支持MongoDB。

有了这三层服务之后,用户在青云的平台上,只要选择了三个可用区之一,使用了负载均衡器,然后部署了分布式数据库,然后部署自己的分布式应用之后就算构建了自己的多活服务。这套系统下来,即使是初创公司也能享受到高大上的多活服务,对青云这样的云服务商来说,也没有太多额外的成本,因为这服务是通用的。

所以,对于选用公有云多活服务的用户来说,额外的成本并不明显,远远低于自己搭建的多活服务。

搭建多活系统,这是公有云的天然优势之一,所以很多公有云服务商都有多活服务,不过,与一些友商相比,青云的多活的服务能力更全面一些。(见下图)

最近,AWS发布了混合云的产品方案Outposts,让AWS云平台连接到企业数据中心内部,让用户在本地也享受到跟云端一样的服务体验。这一思想和类似的描述在恰好正式青云的宣传描述,青云自一开始就比较重视企业用户本地的使用体验,公有云和私有云两条腿走路,笔者也认为这是青云能实现较快盈利的一个重要原因。

正因为如此,青云的多活不仅可以用在公有云,也用在企业混合云环境,照顾了许多企业用户的实际需求,也能为企业用户搭建多活方案。

无论如何,我们是看到,云服务商提供的多活有明显优势,成本上,实施门槛上都大大降低,用户不会因为使用多活服务而承担太多额外成本。理论上不存在绝对不出问题的架构,但多活架构可以把风险降低再降低,相信未来,会有更多不那么关键,但是对服务体验有要求的企业也都会主动寻找云的多活服务。

未经允许不得转载:DOIT » 想要多活又心疼钱?咋不瞧瞧青云的真正多活呢?
分享到: 更多 (0)

评论 抢沙发

评论前必须登录!