独立出来的美团云业务部目前有十几位工程师。虽然部门独立，但工作中仍然跟系统运维组有紧密的配合。美团系统运维组原本就有三分之二的开发工程师，而运维工程师也全部具备编写代码的能力，因此开发与运维工程师能够进行紧密的配合。
相关厂商内容
美团云的最初版本起步于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，usbkey的支持等），以及实现系统架构的升级改造（例如，对多机房架构支持等）。另外，我们对使用的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的时候推出。
我们还会提供一些基础架构的咨询服务，这个咨询服务一方面是工程师提供的人工服务，另一方面是以工具+文档的形式，以互联网的方式将我们的最佳实践共享出去。美团网做到现在的几百亿规模，内部有很多经验积累，如果能把这些积累传递给我们的客户，能够帮助客户少走很多弯路。
美团云的架构
美团云的前端后台使用的框架是django，主要处理web业务相关的逻辑，django的社区支持比较丰富，文档健全，本身功能也比较强大。然而有些特性似乎比较多余，比如说django的很多黑魔法是用数据库外键实现的，但是美团内部有自己的一个dba团队，负责审核所有项目的数据库设计，他们则要求不允许用外键，据说是因为最佳实践得出的经验。
后端整个云平台的框架也是用python实现的，在底层包括虚拟化计算、网络、存储三大功能体系，上层则分为资源管理、任务调度、日志、监控、用户管理、通知报警、api、用量计费等模块，同时在垂直方向上，又包括关系型数据库服务、缓存服务、对象存储服务、负载均衡服务、模板和快照服务、虚拟专用网络服务等。尽管后端的业务不尽相同，但架构师们抽象出了一套处理工作流的逻辑，并且用python实现了一个框架。比如，在消息通信机制的选择上，美团云没有采用类似openstack的采用消息队列rabbitmq的方案，而是采用了webserver，主要原因是考虑到webserver在更加久经考验，业界对http协议有着更加成熟的方案。
美团云团队深度定制了tornado，将它由单线程、异步回调的机制修改为同时支持多线程和同步查询的机制。这主要是考虑到在关系型数据库的查询上（比如mysql），没有较成熟的异步查询方案，而单线程的阻塞查询则会影响tornado的主线程。通过精巧的代码整合，将tornado与sqlalchemy这样的数据库orm集成在一起，成功地解决了数据库的问题。同时针对sqlalchemy的特性进行了一些设置，比如关闭auto-commit，这样能够使得orm不会在每次查询的时候都会发出网络连接，而是在一个线程的业务逻辑里将所有的修改操作hold住，只允许查，在线程结束的时候手动commit，关闭session，提交所有的修改。通过这种方式，实现了一个线程级别的数据库事务锁和对象锁，使得程序员们能在一个线程的逻辑里面同时查询和修改多个数据库表，同时保证业务的原子性。陈博说通过这些框架，程序员们在开发上层业务的时候也感觉到更加便捷了。
听众对演讲反应热烈，表示受益匪浅，也对美团产生的敬佩之情。美团能发展到今天这般规模，其技术能力不容小觑。当然，这些只是美团云整个技术的冰山一角。美团是中国第一大的o2o电商，网络流量500t/天，月活跃用户数超过1.3亿。支持这一庞大业务规模的正是美团云。今年3月，美团云获得idc牌照，8月对外开放首个高品质的自建机房。同时，美团云通过第四批可信云认证，并将电商云奖项收入囊中。2015年第四季度，美团云也将推出数据产品及行业解决方案。所有的这些都意味着，美团云致力于为千万用户提供稳定的公有云服务这一愿景，正在成为现实。
