菜鸟 CPaaS 平台微服务治理实践

背景

CPaaS（cainiao platform as a service）是以公有云为基座，结合先进的云原生理建设的企业级 DevOps 的 PaaS 平台，CPaaS 主要目前主要支持的场景：菜鸟生态的云上研发运维、菜鸟公有云 SaaS 化的能力透出、菜鸟商业化输出支撑，部署到客户的公有云、专有云环境。

在服务了菜鸟多家生态公司及部分商业化输出的产品过程中，深入客户业务场景，解决业务研发及部署痛点的过程中，积累了一些宝贵的经验。这里我们主要对规范云上研发流程，提升研发效率为目标建设的环境治理（云上项目环境）及减少线上版本发布风而险建设的灰度平台的实现过程进行展开介绍。

目标

1、通过项目环境，为多分支并行开发场景提供流量隔离及快速联调的能力。

2、生产环境实现服务灰度发布（金丝雀发布），降低变更风险。

3、微服务应用具备优雅上下线能力，避免启停过程中带来的服务调用出错问题。

调研阶段

微服务流量管控

我们首先调研了开源自建的方案。在调研时我们发现，开发和维护开源 SDK 方案的成本非常大。需要对 Spring Cloud 和 Dubbo 这些微服务框架以及 RockeMQ 这类消息中间件非常了解，才能准确地找到各个框架的增强点进行定制化开发。

除此之外，业务方使用的微服务框架版本也是跨度很大，维护这些不同版本的微服务框架适配，也需要投入大量的精力。

最重要的一点是，使用开源 SDK 自建的方案，开发业务的同事，需要在应用的开发和部署运维的流程都感知到 SDK 的存在，对开发、构建、运维的侵入性很大，很难进行推广。

后来我们也找到了阿里集团负责中间件的同事寻求支持，了解到中间件团队已经推出了一款面向公有云的微服务治理产品 MSE，于是我们进行了调研。

MSE 作为公有云的微服务治理产品，具备云上的服务管控、微服务测试、标签路由、离群摘除、优雅上下线等能力，与我们的诉求完全吻合，并且通过 agent 方式实现，对应用代码无侵入，更适合 PaaS 平台对业务应用增加扩展。

图 1.1

经过与 MSE 团队同时的几次电话和会议沟通之后，逐渐对 MSE 产品有了一些功能上的认知。其中在微服务治理中，我们结合实际的业务需求，落地实现了下面 MSE 的部分能力。

图 1.2

落地场景

项目环境

在多分支开发的场景下，我们通常需要同时部署多个分支。但是多个分支同时部署之后，如何将开发自测流量与日常环境的测试流量分开，以及如何让各个分支拥有自己独立的流量，都是需要解决的问题。

流量隔离

调研和验证 MSE 的标签路由的能力之后，实现思路：通过标签路由能力，将流量进行隔离。

相同应用的不同分支，使用不同的 deployment 实现对版本和容器标签的管理。图 2.1 中 core 应用项目环境 c1 和项目环境 c2 均使用独立于日常环境的容器单独部署，各自的路由标签为 joint1 和 joint2。通过对流量携带流量标记的方式，完成项目环境流量的控制。

接入层应用则通过 K8s-Ingress 实现流量路由，只需要在请求流量的请求头中携带 x-mse-tag的标签，则可以将流量路由到对应标签的入口层应用。入口应用设置标签传递的开发，可将流经此容器的流量打标传递到上有服务。如此反复，则实现流量在整个调用链路的封闭。

图 2.1

服务测试

在研发过程中，除了分支之间的相互干扰需要隔离之外，还需要从业务侧研发的角度解决服务测试的效率问题。MSE 平台提供了微服务测试平台，可以快速的帮助开发者实现服务自测，并且我们通过集成方式集成到自身的 PaaS 平台中，免去自身重建的痛苦。

测试平台支持按照服务提供者 IP 的维度进行服务测试，刚好与流量隔离相互契合，可以对自身关注的项目环境的应用容器发起服务测试完成服务自测。

图 2.2

灰度环境

灰度环境的目的是为了降低线上应用版本发布的风险，减小问题爆炸半径。同样可以通过 MSE 提供的标签路由功能基础上完成对流量灰度的实现。

图 2.3

想要流量实现灰度，那么需要对流量的所有入口实现流量路由。通常我们所感知的流量入口包括：HTTP 接入层、RPC 下游调用、MQ 服务消费、Task 任务调度。当前在 MSE 的灰度能力支持范围内，微服务云网关、金丝雀发布、MQ 灰度均可以组合实现。

当然，这里我们只实现了 HTTP 接入层+RPC 的灰度能力，因为历史的原因，在接入层使用了另一个接入层（MSHA 的 MSFE，本质上是一个 tengine）实现接入层的灰度。但这里丝毫不影响与 MSE 的灰度能力完成流量的串联，这得益于 MSE 产品自身拥有良好的对其他产品的兼容性。我们只需要在入口层的应用上设置流量经过此容器时带标，即可完成灰度流量的传递。