微票儿的 Cloud Native 实践之路

会员服务 ·

微票儿的 Cloud Native 实践之路

2017 年 8 月 31 日 DevOps时代 杨森淼

本篇文章是微影时代技术中心副总裁杨森淼在2016年腾讯“云+未来”峰会Cloud Native专场，分享国内首个O2O领域的Cloud Native实践分享。

微票儿是备受关注的互联网购票平台：估值近百亿、年增长率超4000%、覆盖全国500个城市4500多家影院，日出票达100万张，峰值200万张。而在其业务迅猛增长的背后，一个高速、敏捷、弹性、灵活的技术架构必不可少。

微票儿的Cloud Native实践，采用的是微服务+Docker的方式，以实现从研发测试到部署运维的全系列DevOps。

其技术部分构建在传统Cloud的IaaS、PaaS、SaaS三个层面。在实践的过程中其优点非常明显：业务逻辑简单、耦合小、独立部署、方便隔离、使用不同的技术栈……

但是另一方面，该系统也存在调用开销增加、服务依赖复杂、难以保证数据的一致性、运维成本增加等问题。

为了解决这些问题，微票儿在做微服务的时候针对组织结构进行了变革，2015年研发管理就是前端、平台、运维，到了2016年变成了打散的方式。

微服务对运维的成本成倍的增加，微票儿通过敏捷的基础设施，为微服务提供弹性，按需计算、储存和网络资源能力，所以又有了三个相应的微服务需要执行的点：

第一个是有支撑微服务的平台，我们选择的是OpenStack+Docker+Mesos；

第二个是有符合微服务平台的规范；

第三个是有微服务的核心技术点，需要配置、代码分离、服务注册和发现，路由和容错，还有API的边缘服务，这又增加了很大一部分的工作量。

以上是微票儿整个微服务的平台，将开发、发布、运行这三个阶段严格地做了一个拆分，在不同的环境使用不同的相应的服务。

关于微服务平台规范的APP要符合 12 因子的规范：

首先，对不同的环境参数的配置是通过环境变量进行注入的，代码和配置分离，代码中不允许出现在生产环境的配置信息中，部署相关的 playbook 的时候是公开的，配置中的隐私是不能公开的，部署的过程中经过代码和配置的合并。本身这样又会造成 playbook 也变成了代码，它也需要一定的测试和维护。

其次，日志作为统一的事件流，统一处理服务和进行收集、聚合、搜集、分析，每个程序的开发都要看到数据，他们每天要看所有的数据是否打算，自己的请求耗时大概是多少，自己的请求返回时间是多少，它吃的带宽是多少，都可以通过自己的数据和日志查找到相应的自己服务的相关报表，整个后面还有一系列的报警。

微服务的技术特点 DevOps，是版本控制的分布式配置中心，服务注册和发现，尽早发现问题，尽早解决，成本越小。持续集成保证代码始终处于可用的状态。

微票儿借助于微服务和Docker，实现从研发到运营的全系列DevOps流程，支撑高速增长过程中的敏捷的产品迭代，从而提高整个系统的可维护性和稳定性。

微服务还有很重要的核心技术点就是监控，微票儿有业务单元的监控，红包是否存在异常，是否有黄牛每天不断地在领红包，订单的状态是否一致，是否微信支付会有延长，是否微信支付的回调会有异常。然后还有接口级别的监控，每个接口的成功、错误率，调用的时间。通过业务、接口、基础监控和日志处理分析来监测服务是否异常。

微票儿通过使用Docker，其运维团队可以在某一天随机干掉某几个微服务，还不影响到其它服务。好处就是微服务给我们造成了这样好的环境，能提高你的断路和降级。不再担心它是一条链，没办法隔离。因此提高了断路和降级。

以上所有的Cloud Native实践，都是通过腾讯云来实现的。有人会说，你本身的虚机再铺一层会不会把资源浪费，可能会浪费，但是通过你整体的服务来讲，资源是在下降的，服用是在下降的，而且这里可以看到我们所有的资源开销的占比，看起来最贵的还是带宽，但是这一块就是因为我要有很多的调度系统去实现我的微服务调度和使用资源的调度，都会使用带宽，这一块的成本会增加，但是储存成本和主机成本都在下降。