美团云的技术演变：先把云主机做稳定了再说别的

2013 年上半年，美团发布了其公有云服务美团云。该产品一开始的背后支撑团队是美团系统运维组，到 2014 年 6 月，美团云业务部从系统运维组独立了出来，专门负责云计算方面的产品研发与运营。

近日，InfoQ 中文站编辑与美团云业务部的三位工程师进行了交流，了解美团云目前的状态、过去的演变历程和下一步发展计划。以下内容根据这次交流整理而成。

背景

独立出来的美团云业务部目前有十几位工程师。虽然部门独立，但工作中仍然跟系统运维组有紧密的配合。美团系统运维组原本就有三分之二的开发工程师，而运维工程师也全部具备编写代码的能力，因此开发与运维工程师能够进行紧密的配合。

美团云的最初版本起步于 2012 年 7 月，一开始是作为私有云计算平台来构建。第一版开发了大约 2 个月的时间，之后用了大概 10 个月的时间将美团的所有业务迁移到云平台上。现在除了 Hadoop、数据库仍跑在物理机上之外，美团网的所有业务都已经运行在美团云上，内部的研发、测试平台也运行在美团内部的办公云平台上。

2013 年 5 月，美团云开始对外提供公有云服务，截止到目前仅对外提供云主机产品。对象存储、Redis、MySQL、负载均衡、监控、VPC 等服务也在研发，部分产品已经在内部以及部分测试客户使用，未来会根据产品的成熟度和客户的需求程度逐步对外开放。

稳定是公有云服务的核心价值。自从公有云服务开放以来，美团云主要的工作都放在提升云主机的稳定性，完善云主机模板、备份、监控、安全等工作上。预计在 2014 年 9 月，美团云将发布其第三个版本的更新，继续打磨其产品细节。

技术架构

美团云最初选型的时候对 OpenStack、CloudStack、Eucalyptus 都做过调研，调研的结果是架构设计使用 OpenStack 的框架，网络架构参考 CloudStack，主要组件由自己开发，部分组件在 OpenStack 原生组件上进行了二次开发。

• 核心的云主机管理系统是自己研发，没有使用 Nova。采用 Region-Zone-Cluster 三层架构，支持跨地域、多数据中心的大规模集群部署。采用了基于 KVM 的主机虚拟化和基于 OpenVSwitch+OpenFlow 的网络虚拟化技术。
• 镜像管理用了 Glance。有一定修改，例如，多数据中心分布式支持，以及镜像替换。
• 身份管理用了 Keystone。有一定修改，例如，高并发性能改进，与美团帐户系统的集成。
• 对象存储用了 Swift，但 Swift 在写延迟方面存在性能问题，同时在 OAM 方面的功能比较薄弱，所以也做了一些修改和研发。Swift 现在已经在为美团网内部存储量几十 TB 量级的业务提供服务。

之所以没有整个引入 OpenStack，是因为当时调研时，感觉 OpenStack 的设计比较脱离美团的实际情况。例如，网络架构需要有较大的调整，同时需要有共享存储的支持。当时对美团来说，现有业务的基础设施已经基本固化，为适应 OpenStack 而做这样的调整基本不可接受。另外，OpenStack 在很多细节方面达不到需要的级别。比如，OpenStack 对跨机房多 Zones 的设计，它假设你机房之间的网络是完备的，这也不太符合我们的网络现状。因此，我们基于美团现有的主机使用模式和网络架构，重新设计了网络、存储和主机管理模型，自主研发了虚拟化管理平台。同时，我们在从单机房做到多机房的时候，在 Zones 之间做了解耦，比如在每个机房里都放置 Glance 服务节点，减少对跨机房网络的依赖。正是由于这些研发工作，使得我们经过不到一年时间的磨练，就实现了美团整个基础设施完全运行在私有云上的目标。

当然，由于我们不使用 Nova，就意味着 OpenStack 社区的很多依赖 Nova 的组件和功能我们基本无法直接使用。不过，相对于 OpenStack 大而全 / 兼容并包的架构，我们坚持在每一方面都集中精力用好一种技术，如主机虚拟化使用 KVM，网络虚拟化使用 OpenVSwitch+OpenFlow，使得整个系统的开发和维护成本相对较低，同时能深挖这些技术方案的功能特性，最大限度地压榨硬件性能。同时，由于我们掌握了基础系统的代码，使得我们可以较高的效率添加一些新的业务功能（例如，对虚拟 IP，USB KEY 的支持等），以及实现系统架构的升级改造（例如，对多机房架构支持等）。另外，我们对使用的 OpenStack 组件做的一些修改，比如对 Swift 的优化，目前技术委员会也在提议如何回馈给上游社区。当然了，这个还需要看社区对我们的 patch 接受与否，而我们也还是以满足业务需求优先。

其他方面，块存储落在本地的 SAS 盘上并在本地做 RAID。目前我们对美团网自己的业务做 RAID5，对公有云用户做 RAID10。这是考虑到美团网自己的业务在应用层已经做了较完备的高可用设计的，即使掉了单个节点也不会影响到业务；但对于公有云用户而言，他们用的那一台云主机就是一个单点，所以要对他们的云主机做更好的保护。使用 RAID10 当然成本会比较高。我们也在考虑共享存储，当然前提是先解决了上面的稳定性和性能问题。以后会使用 SSD，使块存储的性能有更大的提升。

网络方面做了分布式设计，主机上用了 OpenFlow，通过 OpenFlow 修改二层协议，让每个用户拥有一个独立的扁平网络，跟其他用户的网络隔离。通过 DNS 虚拟化技术，使得不同的用户可以在各自的私有网络上使用相同的主机名字，并在每个宿主机上部署分布式 DNS 和 DHCP 以实现基础网络服务的去中心化。

运维

美团云的运维思路跟整个美团的运维思路是一致的。下面介绍的运维思路既适用于美团云，也适用于整个美团网。

运维框架可以概括为五横三纵。从横向来看，自底向上分为五个层次：

• 物理层，包括机房网络、硬件设施。我们已在开展多机房和城域网建设，从最底层保证基础设施的稳定性。为了应对大规模机房建设带来的运维成本，我们实现了 Baremetal 自动安装部署的 Web 化管理，从服务器上架之后，其他工作均由自动化完成，并可以和虚拟机一样管理物理机。
• 系统层，包括操作系统、虚拟化。我们在虚拟化基础之上采用了模板化（镜像）的方式进行管理，也对 Linux 内核做了一部分定制开发，例如针对 OVS 的兼容性做了优化。
• 服务层，包括 Webserver、缓存、数据库等基础服务。我们基于 Puppet 工具做了统一配置管理，有自己的软件仓库，并对一部分软件包做了定制。统一配置管理的好处，一方面是避免不一致的修改，保证集群的稳定性，另一方面是提高运维效率。
• 逻辑层，包括业务逻辑、数据流。这一层的主要工作是发布和变更。在很多其他公司，业务的发布上线、数据库的变更管理都是由运维来做，我们认为这样对开发、运维的协作成本较高，所以一直往开发人员自助的方向做，通过代码发布平台、数据库变更平台实现开发和运维工作的轻耦合。在发布平台中，每个应用对应独立的集群，有一位开发作为应用 owner 有最高权限，有多位开发作为应用的成员可以自助发布代码。数据库变更平台也有类似的权限控制机制，并在任务执行层面有特殊的稳定性考虑，例如将大的变更任务自动调度到夜间执行，对删除数据表的任务在后台先做备份。
• 应用层，包括用户可见部分。除了跟逻辑层有类似的发布和变更之外，我们有统一前端平台，实现访问流量的进出分离、行为监测和访问控制，这对于整体的安全性有很大的好处。

从纵向来看，有三部分工作，对上述五个层次是通用的：

• 监控。从物理层到服务层的监控和报警都是运维来跟进、响应的。对于逻辑层和应用层，也是开发人员自助的思路，运维提供监控 API 的规范，开发可以自己创建监控项、设定报警规则、进行增删改查。监控报警之后的处理，现在有些做到了自动化，有些还没有。尤其是有些基础架构和业务之间的纵向链条还没有打通，包括建立业务容量模型，某种特定的业务形态在多少用户的情况下最高负载多少，不同负载等级下的 SLA 应该是多少，等等，这些模型都建立起来之后就能够进行自动化的处理。
• 安全。我们很早就部署了统一的安全接入平台，所有线上的人工操作都需要登陆 relay 跳板机，每个人有独立的登陆帐号，所有线上操作都有审计日志。更多的安全工作由专门的信息安全组负责。
• 流程。早期基于 Jira 做了一些简单的流程，但仍需要改进。现在正在针对比较集中的需求，开发相应的流程控制系统，方向也是自动化、自助化。从业务部门申请 VM 资源，到业务扩容的整个流程，我们正在进行上下游的打通，未来可以在 Web 界面上通过很简单的操作实现，也提供服务化的 API，方便其他业务平台进行集成。虚拟化覆盖全业务线之后，这些事情做起来都变得很方便。

总之，美团网整体的运维思路就是：保证业务稳定运行，同时推动全面自动化、自助化。涉及开发、运维沟通协作的部分，尽可能通过自动化平台的方式，由开发人员自助完成。运维人员除了基础环境、平台建设之外，帮助业务进行高可用架构的梳理，提高代码的可运维性，以及定位和解决业务中的各类问题。

改进与演变

美团云从对内服务开始到现在两年以来，最大的一次改进就是从单机房到多机房的建设，这是跟美团网的城域网建设同步开展的。

单机房的时候，美团网业务早期曾遇到过运营商网络中断几小时的情况，期间业务不可用，非常痛苦。多机房冗余做到最理想的情况下是，即使一个机房整个断电了，业务也不受影响，当然这就意味着需要 100% 的冗余量，成本是比较高的。不过对于美团网来说，冗余的成本是很愿意承担的，因为业务不可用造成的损失要大于做这些冗余的成本，所以我们现在物理资源都留有 50% 的冗余，带宽一般会预留 30% 的冗余。

因为美团网的发展速度很快，去年我们一度遇到资源不够用的情况，在这上面踩了很多坑之后，开始做一些长远规划。现在美团网业务的双机房冗余已经实施了一部分，美团云也有两个机房，如果公有云客户的业务支持横向扩展，那么也可以做跨机房部署。这种机房级高可用做好了，对稳定性又是一个很大的提升，大大减少网络抖动对业务的影响，可用性 SLA 可以从现在的 4 个 9 做到更高。有些规模比较大的客户对服务质量会有比较高的需求，所以美团的城域网、以及未来的广域网，也会共享给我们的公有云客户。

另外上面说到我们数据库跑在物理机上，这一块现在用的是 SSD，读写性能顶得上早期的三台 15000 转 SAS，瓶颈在千兆网卡上，所以我们现在也在做万兆网络的升级改造。数据库服务以后也会开放给公有云用户使用，基础设施跟美团自身业务一致。

未来的计划

由于使用本地存储，所以现在虚拟机迁移需要在夜间进行，以减少对用户服务的影响。为了提高服务的可用性，在确保稳定性和性能的前提下，共享存储是一个不错的选择，所以我们正在测试万兆网络下的共享存储方案。另外，我们底层虚拟化机制用的 KVM，本身是没有热插拔的功能，这也是我们计划要做的一件事。

现在很多客户问我们，什么时候出 Redis，什么时候出云数据库，一些客户对 Redis 和 MongoDB 会有需求，Web 服务想要 MySQL。我们的计划是由 DBA 团队提供一些模板，相当于是一些专门针对 Redis/MySQL 做好优化的系统镜像，让客户可以直接拿来用。这可能会在下一个版本 release 的时候推出。

我们还会提供一些基础架构的咨询服务，这个咨询服务一方面是工程师提供的人工服务，另一方面是以工具 + 文档的形式，以互联网的方式将我们的最佳实践共享出去。美团网做到现在的几百亿规模，内部有很多经验积累，如果能把这些积累传递给我们的客户，能够帮助客户少走很多弯路。

分享者简介

唐君毅，美团云产品工程师。哈工大毕业，曾任积木恒硕产品总监。现负责美团云的产品研发和运营工作。

邱剑，美团云架构师。清华毕业，曾任安和创新副总经理。现负责美团云的平台研发和架构工作。

朱晏，美团网高级技术经理。清华、中科院计算所毕业，曾任百货网联合创始人。现负责美团网的系统运维、云计算工作。

感谢杨赛对本文的策划。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。