归功于云计算的蓬勃发展，业内对基础设施稳定性的关注日益增加。近期举办的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之间，部署混合云。
