【腾讯云峰会 Cloud Native 专场】微票儿的 Cloud Native 实践之路

导读

在今年腾讯云峰会上，开源技术一样是一大亮点。做为开源技术的集成平台，Cloud Native 专场给各家提供了针对 OpenStack 应用以及背后填坑之路做深度探讨的机会。
此文是微票时代技术副总裁杨森淼在现场有关《微票儿的 Cloud Native 实践之路》分享的实录。

杨森淼：《微票儿的 Cloud Native 实践之路》

我跟你们分享的是咱们在实践之路上踩过的坑，咱们作 Cloud Native 已经作了一段时间了，咱们主要以微服务+Docker，加其它的方式，从研发测试到部署总体的实现了咱们的业务流程化运行。咱们在一开始把这个事情想得很美好，咱们是一个电商票务平台，咱们大致的分为两个方向，第一个方向是交易，另一个方向就是作用户信息、电商推荐等等。另外咱们如今的语言也很是多了，咱们要实现持续交付和整个管理的流程化。咱们全部的服务都是在云上。

想得挺好的，可是作起来仍是挺难的，咱们在作的过程当中会发现，云服务确实是挺不错，业务结构简单，耦合度小，独立部署，方便隔离，可使用不一样的技术站，程序员想怎么玩均可以，只要他在本身隔离的环境里面，可是调用开销增长、服务依赖性复杂、数据一致性难保证、运维的成本成倍的增长。

因此首先咱们遇到的问题，组织结构要不要一块儿调，对数据进行改造，不一样的实体业务要不要继续拆分，联合查询变成了屡次的查询，对不一样的业务共享数据单机的事物不够，而后是系统重构期间杂乱无章的依赖，形成数据的不一致，致使人工查询的成本增长，还有就是是否在每个微服务里面要增长 Request-Id，咱们增长完了之后发现，50 多个微服务，300 多个 API，这个微服务到底要怎么作，这变成了咱们如今一个新的坑。

咱们作微服务的时候作了组织结构的变动，以前（2015年）研发管理就是前端、平台、运维，以后（2016年）变成了这种打散的方式：每一个人在相应的微服务里面，由于工做职责的增长，不少人还要跨微服务协做，而后他就开始纠结了。

这是咱们业务层面的微服务的拆分，咱们有 50 多个微服务的模块，300 多个 API，因此咱们又拆分出了一组人专门作服务编排。这个服务编排的人天天作的一件事情就是相互的依赖和相互的关系要让这个接口部门所有去调用，它所有去负责，它要最了解每一个服务之间的关系，可是它还要作整个服务的调用和协调者，这个又是很大的一笔开销。
刚刚说了，微服务有了之后，对运维的成本成倍的增长，咱们就须要有敏捷的基础设施，为微服务提供弹性，按需计算、储存和网络资源能力，因此咱们又有了三个相应的微服务须要执行的点：

第一个是有支撑微服务的平台，咱们选择的是 OpenStack+Docker+Mesos
第二个是有符合微服务平台的规范
第三是有微服务的核心技术点，须要配置、代码分离、服务注册和发现，路由和容错，还有API的边缘服务，这又增长了很大一部分的工做量。

这是咱们整个微服务的平台，咱们将开发、发布、运行这三个阶段严格地作了一个拆分，在不一样的环境使用不一样的相应的服务。

为了作一些资源上的复用，咱们首先把储存和部分本地内存经过 Mesos 铺用了之后，而后在不一样的时间点来调用资源的服务，经过分析一些历史的信息，好比说咱们白天的时候不少业务上的储存运用都不多，费的主要是 I/O，咱们白天能够把大数据的 I/O 和 CPU 都提供出来供业务使用；晚上的时候，当业务所有都停歇的时候，咱们会把全部的 I/O 和 CPU、储存所有都给大数据使用，让他们作离线计算，会在全部的内存下面去跑咱们的 Spark 集群的服务。

微服务这边所说的 12 因子的规范，我就举例说明几个。首先咱们对不一样的环境参数的配置是经过环境变量进行注入的，代码和配置分离，代码中不容许出如今生产环境的配置信息中，部署相关的 playbook 的时候是公开的，配置中的隐私是不能公开的，部署的过程当中通过代码和配置的合并。自己这样又会形成 playbook 也变成了代码，它也须要必定的测试和维护。

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

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

当咱们多点的触发 Image 的时候，咱们保证它和最后要是一致的，当咱们发现 Docker 有变动的时候，会自动触发 Image 的重建过程，依赖这个 Image 物的 Dockerfile 也会重建。

为了保证多点同时触发 Image，咱们为了保证每一个点都是可用的，因此咱们在动态更新的时候，会动态建立、重启、中止的事件通知到服务发现模块，前端的反向代理会自动更新来确保用户访问地址不变。DNS 的域名和模板，在不一样的服务中会有不一样的分支和规则。

咱们使用了微服务之后又用了 Docker 等等，对于咱们来说，真的可能提升了整个系统的可维护性和稳定性，同时又增长了两个的成本，第一个最大的成本是有 50 个微服务，微服务连起来最大的成本就是测试，还有就是运维的成本会增长，这里面有不少的测试环节，每一个服务还有本身的灰度发布，每一个服务大概有三四个灰度发布，天天不一样的灰度有不一样的人选进去，怎么保证灰度和它的测试是一致的，怎么保证咱们指定哪个用户进入哪个灰度，来持续跟踪用户的行为，都成为一个大的话题，咱们专门又有一组人去作灰度，专门又有一组环境去作灰度发布，它来保证灰度的数据的人指定，而后进入发布的灰度，再在灰度出来之后分析灰度的数据，来保证你所须要的灰度的用户就是你所须要的来查看你的问题。

服务还有很重要的就是监控，咱们有业务单元的监控，红包是否存在异常，是否有黄牛天天不断地在领红包，订单的状态是否一致，是否微信支付会有延长，是否微信支付的回调会有异常。而后还有接口级别的监控，每一个接口的成功、错误率，调用的时间。还有咱们很依赖电影院自己的系统，电影院出票系统的错误分布等等，这些接口的监控都经过统一的日志规范来进行处理。还有就是基础监控，服务器自己的 CPU、储存和数据库缓存队列是否有效等等。咱们全部的基础监控也是经过统一的日志处理和分析。

之前的隔离、降级和断路等等基本上已经很难作了，由于它是一条链，没办法隔离，用了 Docker 之后，咱们的断路、降级、隔离就是自然的，咱们的运维团队能够在某一天随机干掉某几个微服务，而后看这些微服务怎么手忙脚乱，而后还不影响到其它服务，这个好的地方就是微服务也给咱们形成了这样好的环境，能提升你的断路和降级。

以上的实践咱们都是用腾讯云来实现的。有人会说，你自己的虚机再铺一层会不会把资源浪费，可能会浪费，可是经过你总体的服务来说，咱们认为资源是在降低的，服用是在降低的，并且这里能够看到咱们全部的资源开销的占比，看起来最贵的仍是带宽，可是这一块就是由于我要有不少的调度系统去实现个人微服务调度和使用资源的调度，都会使用带宽，这一块的成本会增长，可是储存成本和主机成本都在降低。

以上是我给你们分享的咱们的微服务和 Docker 的一些经验，谢谢你们。