Top
首页 > 智能生活 > APP > 正文

闭关“锤炼”稳定性,多维解读美团云设计思路

发布时间:2016-07-13 16:23        来源:驱动中国        作者:

归功于云计算的蓬勃发展,业内对基础设施稳定性的关注日益增加。近期举办的GITC全球互联网技术大会上,美团云技术负责人王昕溥就分享了美团云的设计思路,和在为企业提供稳定可靠的IT基础设施背后的技术细节。

美团云的由来

美团,已经不是大家印象中只做团购的公司了,美团的业务延伸到生活服务的各个领域,餐饮、外卖、酒店、旅游、票务等等。美团和点评合并以后,其母公司有了一个响亮的名字,叫“China Internet Plus Group”(译为“中国互联网+”)。这说明什么呢?说明美团点评的定位是很清晰的,希望能够通过互联网,把用户和商家、企业连接起来。美团云的发展策略也是紧跟着这个目标来制定的。

2012年5月,美团云就开始进行技术储备和开发。当时的目的比较简单,主要是利用云的特性,将美团的业务部署到云上,从而稳定支撑当时快速膨胀的业务规模。到2013年7月份的时候,整个美团的业务都已经上云,然后一直到今天也是如此。这点很难得,因为目前互联网业内,比美团体量大的公司,都还没有完全做到这一点。

2013年5月,在没有宣传和市场推广的情况下,美团云悄悄地开放了公有云用户注册,当时口碑和反响相当不错。在实际开放的过程中,我们发现把私有云技术移植到公有云,无论是从技术、资源上来讲,还包括一些资质上,都遇到了一些问题。所以,美团云没有急于大规模地市场推广,这几年我们都在技术、资源各个方面沉淀产品,提高用户体验。

2015年,无论是市场对于云的认知,还是美团云产品的打磨,我们认为时机基本成熟,因此从去年9月份开始,美团云连续开放了两个新机房。同时,对很多老用户来说,会有非常明显的感觉,美团云这半年多的发展速度非常快,各种服务和组件都日益完善。

云的发展现状

说到云的发展。游戏行业是云计算落地的先驱阵地,未来,我们预测下一个云服务的爆点垂直行业可能在视频直播领域。视频直播非常依赖CDN,在这个领域,传统的CDN厂商和公有云服务提供商,谁更有优势其实很难说。大家都在拼资源、价格,最后结果可能是看上去很热闹,但是利润都被运营商赚走了,因为CDN依靠流量。所以未来云服务,下一个垂直领域在哪儿,这个问题是云计算业内各家都在思索的问题。

现在整个云计算行业处于一个什么阶段呢?打一个比方,有点类似于手机处在非智能机的阶段。非智能机时候,大家买手机会考虑什么?第一考虑性能,比如通话质量好不好,待机时间长不长,然后性价比。今天放到云服务也是一样,用户挑选云服务首先看它的性能和稳定性,当然也包括价格。那么什么时候,云行业能够出现一个像智能手机一样颠覆性的产品呢?有了智能手机以后,用户考虑就不再是简单的通话质量或者待机时间。整个用户体验包括了更多的维度,出了硬件以外,更包括软件的用户体验。对云计算来说,下一个阶段的发展方向,是通过更完整的生态系统,提高用户黏度,而不单纯某个垂直行业的爆发。

多维解读稳定性

回到现在这个时间点,目前,对于公有云服务商来说,最关注的基本问题就是性能和稳定性。稳定性可以从很多方面来看。

1. 网络

首先从底层的基础网络和硬件条件说起,早期美团云做的比较简单,一台物理机,接三根网线,分别是内网、外网和管理网,然后接交换机。这个架构很好地运行了很久。原因是初期美团云的目标是服务美团内部业务。一来早期业务流量也不是很大,基本上能够满足要求,二来运维之上还有一个SRE团队,工程师能够对一些故障进行及时地响应和处理。三来,美团云的研发团队很有经验,在系统设计的时候就已经考虑到单点的问题,并从更高的业务层面规避了可能的问题。

但是如果把这套私有云直接移植到公有云上,就非常容易出现问题。大多数公司并不具备庞大的运维和开发部门来随时进行故障响应,因此他们对于公有云的稳定性要求非常高。今天,用户使用的所有美团公有云服务的架构,都基于稳定性做出了很多改变。

网络层面,美团云网络全面升级了万兆的环境。每台服务器都是两个万兆口,交换机、核心都是堆叠双万兆上联,所以整个链路上没有单点。

另外,原先三根网线,如果要做冗余,每根网线都变成两根的话,就是六根网线,成本上来说很高。随着技术的发展,我们在底层物理链路上使用了两根网线,那么把管理网,外网内网都overlay在这两根线上,然后基于vxlan技术来做我们整个的基础网络,这样的话就是一个比较简单清晰明了的架构。

除了机房内部,我们还需要考虑如果整个机房出现问题应该怎么办。美团云在北京地区有两个机房,机房之间也做了光纤互联,保证一个机房出问题之后,流量能够切换到另一个机房。同时,美团云的网络采用了五线BGP网络接入,所以当某个运营商网络不稳定的时候,也可以把流量暂时切到其他运营商。这种情况下延时会稍微大一些,但是能够包括保障用户服务的不中断。

2. 物理机

除了网络,物理机有可能会宕机,这是一个绕不开的问题。

首先一些比较简单的情况下,比如物理机有一些设备坏掉需要更换。现在很多硬件设备都支持热插拔,但为了避免不可预期的问题出现。我们一般采取的方案是,首先通过热迁移,把这个物理机上的用户,迁移到其他物理机上去,然后再对这台机器进行下线处理,这种情况比较好,因为还有足够的时间来进行迁移。

另外一种比较糟糕的情况下,比如这台物理机宕机了,但是还能重启。这可能需要花几分钟时间来重启、系统恢复,这段时间用户的使用会受到影响的。更糟糕一点的情况是这台物理机彻底坏了。这种情况下就比较被动,我们的方案是,由运维人员把这台物理机上的硬盘拔下来,插到其他的物理机上,然后来给用户恢复服务,我们目前能够做到的是在工作时间内两个小时,非工作时间内四个小时做到这种更换硬盘级别的故障恢复,当然这都是极其罕见最糟糕的情况下。

为了避免糟糕的情况,我们建议用户,尽量选择公共组件,比如选择美团云的数据库产品,而不是在自己的云主机内搭建数据库,这就可以避免因为磁盘损坏,或者是物理机宕机造成一些不可控的情况。

早先的数据库,主从故障切换很多时候都是通过手工来操作的,这个过程中可能会有一些数据丢失。现在我们通过DBHA来进行主备的切换,一般会在几秒时间内能够自动地完成这个数据库的主备的切换。

另外我们还通过这个在数据库前面加了一层proxy,为用户提供数据库的读写分离服务。就是用户可以有一个主库,同时创建多个从库,写的操作都是在这个主库上完成的,然后根据访问情况,创建多个从库来进行读的操作。

这样的话一方面就是说提升了性能,另一方面避免读和写同时都在主库上,也确实提高了稳定性。但是我们引入的proxy这一层服务,同时引入了风险。所以就要考虑说如果proxy发生故障之后应该怎么做。所以我们在前面又加了一层MGW,就是美团的四层负载均衡设备,然后用它来剔除底层的proxy宕机之后的影响。

那么MGW本身发生了问题又应该怎么办呢?我们做了一个集群,通过OSPF上连到交换机,这样的话一旦宕机,就能通过这个路由协议,自动地把它剔除掉,这个应该算是一个正常的高可用的集群的标准设计。但是对于数据库来讲,其实还有一些特殊的地方,因为数据库现在越来越多的都是使用长链接的,超时设置一般很长,比如说可能长达一个小时甚至更多,程序的使用方法一旦有问题,比如当这个链接断掉之后,他不能够很快地检测到这个连接已经失效了,就会对业务会造成很大的影响,这个问题在美团内部也发生过。

专门针对这个问题,我们在MGW上开发了session同步的功能,就是当一个链接建立到一台服务器上之后,我们会把它同步到其他的服务器上去,这样的话一旦这台服务器发生了故障,上面链接就会迁移到其他的服务器上继续提供服务,这样的话对用户来讲是没有感知的,就能够很好地保护这个长链接的用户。

另外考虑到proxy可能有一些例行的,比如说升级,也会影响到长链接,那么我们还提供了一个后端的平稳下线的功能。就是当做了一个标记之后,新的链接就不会再到proxy上了,旧链接会继续提供服务,直到这个服务完成之后,彻底把它摘掉。这也为长链接提供了较好的保护。

除了数据库,对于对象存储来说也是一样。我们的对象存储集群是分布在同城多个机房之中的,可以保证,比如某一个机器发生了故障,或者说某一个机房发生了故障之后,用户的数据不会丢失,访问也可以正常进行。然后就像刚才说的,前端我们也部署了ELB,就是这个四层加七层的负载均衡,来为用户提供服务,彻底解决底层的宕机问题。

3. 性能稳定性

刚才我们讨论了物理机的情况,都是基于故障切换,我们应该怎么做。但是更多的情况下,其实没有故障,但是性能能不能够稳定输出,是运维人员面临的一个最复杂,也是最难解决的问题。这可以从三个方面来考虑,比如说计算、磁盘和网络的问题。

计算—做公有云的话大家都绕不开的一个问题就是说,我们是不是超售,那运气好的话,超售这个瓶颈没有被遇到,一直都很空闲。但是有一种情况,超售比可能不高,只是一个瞬间用户都开始使用,这时候计算资源怎么保持稳定?

被动一些的办法是,通过实时监控,把用户迁到一些负载不是很高的机器上去。但这要依赖于网络的速度,因为毕竟有实时数据的传输,网络资源越有保证,用户受到的影响的时间就越短。

然后说到磁盘,对于单一用户的读写来讲,写本地磁盘和写EBS其实差别不大。对于多用户同时运行来写的话,EBS的总带宽一定是比这个单一物理机上的带宽磁盘是要大的,但是要依赖于网络的稳定和带宽。对于网络来说,其实它也是依赖于计算资源,因为当网络开销增加,必然要消耗更多的计算资源。所以计算、网络、存储也三个环节其实是环环相扣的,大家相互依赖和影响。

我们的思路是先从网络入手,先解决最根本的网络传输的问题,然后再以网络来带动其他环节的问题的解决。早期我们为什么选择OVS?OVS早期版本其实性能不是很好。原因在于OVS2.3的megaflow特性,有一个类似于通配的功能,能够极大地减小流表的数量,同时提高命中率。当在一台宿主机上频繁地创建和删除链接的时候,这对性能提升是很有效的。但是对于单一的流的传输性能,这个提升并不是很大。

所以我们采用了一些目前来讲算是更先进的办法。网络的瓶颈根本原因在于内核协议栈。我们选择DPDK结合OVS的方案。这个方案中,会单独隔离出一部分资源,比如说10%的资源来运行DPDK,处理网络资源。DPDK会直接绕过内核,把网卡的流量转到用户态来。所以它的性能会很高,两个核的计算能力就足够处理一个物理机上,比如说10G或者20G的小包流量。

在这种情况下,剩余的资源,就可以完全分配给用户来使用。也就是说,不管网络流量负载多高,都不会影响用户的CPU资源。

使用DPDK和OVS之后,可以说解决了底层网络数据平面转发的问题,但是更复杂的部分在于上面的控制平面。美团云采用了OVS的控制方式,即配置流表的工作,交由控制器处理。控制器决定是否放行,动态地下发对应流表。在OVS控制器对数据包进行过滤和处理过程中,美团云开发了软件层面的解决方案,从而提高了网络性能。下一阶段的迭代,美团云会在硬件层面进行隔离,通过VXLAN对用户进行隔离,从而彻底解决积压问题。

开放共赢

除了以上这些方面,美团云的建议用户选择1-2家云服务商为业务做好备份,在这个方面,美团云的心态是非常开放的。

美团云一直在降低用户迁移的难度。首先,美团云的开放API兼容性很好,无论是主机API还是对象存储API,都便于用户数据导入和导出。同时,美团云有成熟的vpc方案和专项解决方案,方便用户在不同的云之间,或者不同的IDC之间,部署混合云。

专题访谈

合作站点
stat