【腾讯云峰会 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 的一些经验，谢谢大家。

关键字：腾讯云, 云计算, openstack, mesos

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！