企业深入使用微服务后会面临哪些问题？云原生全链路灰度给了新思路_apisix 全链路灰度

简介：如何落地可灰度、可观测、可回滚的安全生产三板斧能力，满足业务高速发展情况下快速迭代和小心验证的诉求，是企业在微服务化深入过程中必须要面对的问题。在云原生流行的当下，这个问题又有了一些新的思路与解法。

作者：魁予、十眠

如何落地可灰度、可观测、可回滚的安全生产三板斧能力，满足业务高速发展情况下快速迭代和小心验证的诉求，是企业在微服务化深入过程中必须要面对的问题。在云原生流行的当下，这个问题又有了一些新的思路与解法。

Kubernetes Ingress 网关

我们先从 Ingress 网关谈起，聊一下通过 Ingress 配置路由转发。

Kubernetes 集群内的网络与外部是隔离的，即在 Kubernetes 集群外部无法直接访问集群内部的服务，如何让将 Kubernetes 集群内部的服务提供给外部用户呢？Kubernetes 社区有三种方案：NodePort、LoadBalancer、Ingress，下图是对这三种方案的对比：

通过对比可以看到 Ingress 是更适合业务使用的一种方式，可以基于其做更复杂的二次路由分发，这也是目前用户主流的选择。

随着云原生应用微服务化深入，用户需要面对复杂路由规则配置、支持多种应用层协议（HTTP、HTTPS和 QUIC 等）、服务访问的安全性以及流量的可观测性等诉求。Kubernetes 希望通过 Ingress 来标准化集群入口流量的规则定义，但实际业务落地时需要的功能点要远比 Ingress 提供的多，为了满足不断增长的业务诉求，让用户轻松应对云原生应用的流量管理，各类 Ingress-Provider 也都在 Ingress 的标准下进行各种扩展。

各种 Ingress-Provider 如何路由转发

下面我会简单介绍 Kubernetes 下的各种 Ingress 网关的实现，以及如何配置路由转发规则等。

Nginx Ingress

Nginx Ingress 由资源对象 Ingress、Ingress Controller、Nginx 三部分组成，Ingress Controller 用以将 Ingress 资源实例组装成 Nginx 配置文件（nginx.conf），并重新加载 Nginx 使变更的配置生效。Ingress-nginx 是 Kubernetes 社区提供的 Ingress 控制器，最容易部署，但是受性能限制，功能较为单一，且更新 Nginx 配置需要 reload。

1、基于 Nginx Ingress Controller 配置路由转发

基于部署了 Nginx Ingress Controller 组件的 Kubernetes 集群，可以实现路由转发功能，能够根据域名、路径进行路由转发，也能够支持基于 Ingress 的 Annotations 进行简单规则的灰度流量管理，如权重、Header 等。在当下趋势中，Nginx Ingress 依旧是使用最广泛的。

ALB Ingress

1、ALB 产品介绍

应用型负载均衡 ALB（Application Load Balancer）是阿里云推出的专门面向 HTTP、HTTPS 和 QUIC 等应用层负载场景的负载均衡服务，具备超强弹性及大规模七层流量处理能力。

2、ALB 特性

• 弹性自动伸缩：ALB 同时提供域名与 VIP（Virtual IP address），支持对多台云服务器进行流量分发以扩展应用系统的服务能力，通过消除单点故障来提升应用系统的可用性。ALB 允许您自定义可用区组合，并支持在可用区间弹性缩放，避免单可用区资源瓶颈。
• 高级的协议：支持 ALB 支持应用传输协议 QUIC，在实时音视频、互动直播和游戏等移动互联网应用场景中，访问速度更快，传输链路更安全可靠。ALB 同时支持 gRPC 框架，可实现海量微服务间的高效 API 通信。
• 基于内容的高级路由：ALB 支持基于 HTTP 标头、Cookie、HTTP 请求方法等多种规则来识别特定业务流量，并将其转发至不同的后端服务器。同时 ALB 还支持重定向、重写以及自定义 HTTPS 标头等高级操作。
• 安全加持“ALB 自带分布式拒绝服务 DDoS（Distributed Denial of Service）防护，一键集成 Web 应用防火墙（Web Application Firewall，简称 WAF）。同时 ALB 支持全链路 HTTPS 加密，可以实现与客户端或后端服务器的 HTTPS 交互；支持 TLS 1.3 等高效安全的加密协议，面向加密敏感型业务，满足 Zero-Trust 新一代安全技术架构需求；支持预制的安全策略，您可以自定义安全策略。
• 云原生应用：在云原生时代，PaaS 平台将下沉到基础设施，成为云的一部分。随着云原生逐步成熟，互联网、金融、企业等诸多行业新建业务时选择云原生部署，或对现有业务进行云原生化改造。ALB 与容器服务 Kubernetes 版（Alibaba Cloud Container Service for Kubernetes，简称 ACK）深度集成，是阿里云的官方云原生 Ingress 网关。
• 弹性灵活的计费：ALB 通过弹性公网 IP（Elastic IP Address，简称 EIP）和共享带宽提供公网能力，实现公网灵活计费；同时采用了更先进的、更适合弹性业务峰值的基于容量单位（LCU）的计价方案。

3、基于 ALB Ingress Controller 配置路由转发

ALB Ingress Controller 通过 API Server 获取 Ingress 资源的变化，动态地生成AlbConfig，然后依次创建 ALB 实例、监听、路由转发规则以及后端服务器组。Kubernetes 中 Service、Ingress 与 AlbConfig 有着以下关系：

• Service 是后端真实服务的抽象，一个 Service 可以代表多个相同的后端服务。
• Ingress 是反向代理规则，用来规定 HTTP/HTTPS 请求应该被转发到哪个 Service 上。例如：根据请求中不同的 Host 和 URL 路径，让请求转发到不同的 Service 上。
• AlbConfig 是在 ALB Ingress Controller 提供的 CRD 资源，使用 AlbConfig  CRD 来配置 ALB 实例和监听。一个 AlbConfig 对应一个 ALB 实例。

ALB Ingress 基于阿里云应用型负载均衡 ALB（Application Load Balancer）之上提供更为强大的 Ingress 流量管理方式，兼容 Nginx Ingress，具备处理复杂业务路由和证书自动发现的能力，支持 HTTP、HTTPS 和 QUIC 协议，完全满足在云原生应用场景下对超强弹性和大规模七层流量处理能力的需求。

APISIX Ingress

APISIX Ingress 跟 Kubernetes Ingress Nginx 的区别主要在于 APISIX Ingress 是以 Apache APISIX 作为实际承载业务流量的数据面。如下图所示，当用户请求到具体的某一个服务/API/网页时，通过外部代理将整个业务流量/用户请求传输到 Kubernetes 集群，然后经过 APISIX Ingress 进行后续处理。

从上图可以看到，APISIX Ingress 分成了两部分。一部分是 APISIX Ingress Controller，作为控制面它将完成配置管理与分发。另一部分 APISIX Proxy Pod 负责承载业务流量，它是通过 CRD(Custom Resource Definitions) 的方式实现的。Apache APISIX Ingress 除了支持自定义资源外，还支持原生的 Kubernetes Ingress 资源。

1、基于 APISIX Ingress Controller 的应用路由

如上图所示，我们部署了 APISIX Ingress Controller 组件的集群，能够实现基于Ingress 资源和自定义资源 ApisixRoute 进行路由配置，控制器监听资源的变更事件，调用 apisix-admin api 进行规则的持久化存储。流量经过 APISIX 配置的 LoadBalancer 类型 Service 网关从 ETCD 中同步配置，并将请求转发到上游。

APISIX Ingress Controller 基于 Apache APISIX，支持 Kubernetes 中的 Ingress 资源进行路由配置，也支持通过自定义资源对接到 APISIX 的路由、插件、上游等资源配置。支持动态配置路由规则、热插拔插件、更丰富的路由规则支持，APISIX 云原生网关也能够提供可观测、故障注入、链路追踪等能力。使用高可靠 ETCD 集群作为配置中心，进行 apisix 配置的存储和分发。

MSE 云原生网关 Ingress

MSE 云原生网关是阿里云推出的下一代网关，将传统的流量网关和微服务网关合并，在降低 50%资源成本的同时为用户提供了精细化的流量治理能力，支持 ACK 容器服务、Nacos、Eureka、固定地址、FaaS 等多种服务发现方式，支持多种认证登录方式快速构建安全防线，提供全方面、多视角的监控体系，如指标监控、日志分析以及链路追踪。

1、基于 MSE 云原生网关 Ingress Controller 的应用路由

上图是 MSE 云原生网关在多集群模式下对业务应用进行流量管理的应用场景。MSE 云原生网关与阿里云容器服务 ACK 深度集成，可以做到自动发现服务以及对应的端点信息并动态秒级生效。用户只需简单在 MSE 管控平台关联对应的 Kubernetes ACK 集群，通过在路由管理模块中配置路由来对外暴露 ACK 中服务即可，同时可以按集群维度进行流量分流以及故障转移。此外，用户可以为业务路由实施额外的策略，如常见的限流、跨域或者重写。

MSE 云原生网关提供的流量治理能力与具体的服务发现方式解耦，无论后端服务采用何种服务发现方式，云原生网关以统一的交互体验来降低上手门槛，满足用户业务日益增长的流量治理诉求。

上文介绍了 Nginx Ingress、ALB Ingress、APISIX Ingress 以及 MSE 云原生网关Ingress 这五种 Ingress 的路由转发与配置，我们可以按照自己的业务需求与复杂度按需选择合适的 Ingress 实现。

假设我们已经配好了 Ingress 的路由转发，那么在多应用环境下，我们该如何简单地玩转全链路灰度呢？

基于 Ingress 实现全链路流量灰度

我们基于全链路灰度的实践，提出了“泳道”这一个概念，当然这一概念在分布式软件领域并非新词。

名词解释

• 泳道 ：为相同版本应用定义的一套隔离环境。只有满足了流控路由规则的请求流量才会路由到对应泳道里的打标应用。一个应用可以属于多个泳道，一个泳道可以包含多个应用，应用和泳道是多对多的关系。
• 泳道组：泳道的集合。泳道组的作用主要是为了区分不同团队或不同场景。
• 基线：指业务所有服务都部署到了这一环境中。未打标的应用属于基线稳定版本的应用，我们这里指稳定的线上环境。
• 入口应用：微服务体系内的流量入口。入口应用可以是 Ingress 网关、或者是自建的 Spring Cloud Gateway、Netflix Zuul Gateway 引擎类型网关或者 Spring Boot、Spring MVC、Dubbo 应用等。

为什么要区分出入口应用？因为全链路灰度场景下，我们只需对入口应用进行路由转发的规则配置，后续微服务只需要按照透传的标签进行染色路由（实现“泳道”的流量闭环能力）。

从上图中可以看到，我们分别创建了泳道 A 与泳道 B，里面涉及了交易中心、商品中心两个应用，分别是标签标签 2，其中 A 泳道分流了线上 30%的流量，B 泳道分流了线上 20%的流量，基线环境（即未打标的环境）分流了线上 50%的流量。

全链路灰度的技术解析

我们通过在 deployment 上配置注解 alicloud.service.tag: gray 标识应用灰度版本，并带标注册到注册中心中，在灰度版本应用上开启全链路泳道(经过机器的流量自动染色)，支持灰度流量自动添加灰度 x-mse-tag: gray 标签，通过扩展 consumer 的路由能力将带有灰度标签的流量转发到目标灰度应用。

基于各种 Ingress 网关的全链路灰度

基于全链路灰度能力搭配合适的入口路由网关即可实现全链路流量灰度，如上述使用 Ingress-Nginx、Ingress-APISIX、ALB、MSE 云原生网关均可以作为流量入口。

全链路灰度的产品实现

功能性与易用性是产品化必须思考的点，我们需要从用户的视角出发，端到端思考全流程该如何去实践、如何去落地。在阿里云上关于微服务全链路灰度能力有以下两款产品都提供了完整的全链路灰度解决方案。

MSE 全链路灰度方案

全链路灰度作为 MSE 微服务治理专业版中的核心功能，具备以下六大特点：

• 全链路隔离流量泳道

• 通过设置流量规则对所需流量进行'染色'，'染色'流量会路由到灰度机器。
• 灰度流量携带灰度标往下游传递，形成灰度专属环境流量泳道，无灰度环境应用会默认选择未打标的基线环境。
• 端到端的稳定基线环境

未打标的应用属于基线稳定版本的应用，即稳定的线上环境。当我们将发布对应的灰度版本代码，然后可以配置规则定向引入特定的线上流量，控制灰度代码的风险。

• 流量一键动态切流

流量规则定制后，可根据需求进行一键停启，增删改查，实时生效。灰度引流更便捷。

• 低成本接入，基于 Java Agent 技术实现无需修改一行业务代码

MSE 微服务治理能力基于 Java Agent 字节码增强的技术实现，无缝支持市面上近 5 年的所有 Spring Cloud 和 Dubbo 的版本，用户不用改一行代码就可以使用，不需要改变业务的现有架构，随时可上可下，没有绑定。只需开启 MSE 微服务治理专业版，在线配置，实时生效。

• 可观测能力

• 具备泳道级别的单应用可观测能力

• 具备全链路应用的可观测能力，可以从全局视角观察流量是否存在逃逸情况。灰没灰到，一目了然。

• 具备无损上下线能力，使得发布更加丝滑

应用开启 MSE 微服务治理后就具备无损上下线能力，大流量下的发布、回滚、扩容、缩容等场景，均能保证流量无损。

1、创建流量泳道组

需要将泳道中涉及的应用添加到泳道组涉及应用中

2、创建流量泳道

在使用泳道功能前，我们默认已经存在了一个包含所有服务在内的基线（未达标）环境。

我们需要去部署隔离版本的应用 Deployment，同时去给他们打上标签，并且给泳道选择对应一一关联的标签（test 泳道关联 gray 标签）

然后需要去配置流量入口的 Ingress 规则，比如访问 www.base.com 路由到 A 应用的 base 版本，访问 www.gray.com 路由到 A 应用的 gray 版本。

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-base
spec:
  rules:
  - host: www.base.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-base
          servicePort: 20001
        path: /

---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-gray
spec:
  rules:
  - host: www.gray.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-gray
          servicePort: 20001
        path: /

EDAS 全链路灰度方案

1、EDAS 产品介绍

EDAS 是应用托管和微服务管理的云原生 PaaS 平台，提供应用开发、部署、监控、运维等全栈式解决方案，同时支持 Spring Cloud 和 Apache Dubbo 等微服务运行环境，助力您的应用轻松上云。

在 EDAS 平台中，用户可以通过 WAR 包、JAR 包或镜像等多种方式快速部署应用到多种底层服务器集群，免集群维护，能够轻松部署应用的基线版本和灰度版本。EDAS 无缝接入了 MSE 微服务治理能力，部署在 EDAS 的应用无需额外安装 Agent 即可零代码入侵获得应用无损上下线、金丝雀发布、全链路流量控制等高级特性。

目前 EDAS 支持微服务应用为入口的全链路灰度能力，下面简单介绍在 EDAS 中的配置全链路灰度流量的方法。

2、创建流量泳道组和泳道

在创建泳道时需要选择入口类型，目前仅支持部署在 EDAS 中的入口应用作为泳道入口应用，需要将泳道中涉及的基线版本和灰度版本添加到泳道组涉及应用中。

在创建泳道时支持基于路径配置规则定向引入特定的线上流量，配置打标流量应用形成灰度环境链路。泳道支持基于 Cookie、Header、Parameter 进行流量控制。

配置泳道成功后，可以在全链路流量控制界面选择目标泳道组进行流量观测，包括入口应用总的监控图、未打标部分监控图和打标部分监控图，及泳道组内所有应用的监控图。

3、应用路由作为流量入口实现全链路灰度

EDAS 平台支持用户为 Kubernetes 应用基于 Nginx Ingress 创建应用路由，结合 EDAS 对全链路流控的支持，用户能够直接在 EDAS 控制台实现使用 Nginx Ingress 作为流量入口网关的全链路灰度。

在 EDAS 平台中部署基线版本应用、灰度版本应用、入口应用后，根据上述创建流量泳道组和泳道的步骤创建灰度泳道后，可以为入口应用绑定 Kubernetes 的 Service 资源以提供流量入口。可以为入口应用配置 LoadBalancer 类型 Service，以提供入口应用的对外访问，也可以基于 Kubernetes 集群中已有的 Nginx Ingress 网关，为入口应用配置 ClusterIP 类型 Service 并配置应用路由，以避免额外分配公网 IP。

下面简单介绍为入口应用配置应用路由作为流量入口的方法。

在部署完成的应用详情页面，支持进行应用的访问方式配置，在这里可以选择为入口应用绑定 LoadBalancer 类型 Service 以直接对外访问，也可以创建 ClusterIP 类型 Service，如下图：

配置成功后，可以在 EDAS 应用路由页面点击创建应用路由，选择该入口应用所在的集群，命名空间，应用名称，上述步骤创建的服务名称及端口以配置 Ingress 资源，如下图：

配置成功后，即可使用该 Ingress 资源配置的域名和路径并结合在泳道中配置的灰度流量规则实现全链路灰度。

4、更进一步

EDAS 中的全链路流量控制目前仅支持部署在 EDAS 中的入口应用作为流量入口，在Kubernetes 主导的云原生化趋势下，EDAS 将支持使用 Ingress 作为流量入口，用户不需要额外部署网关应用，直接使用 Ingress 资源配置转发规则即可作为流量入口。不仅如此，EDAS 也将支持 ALB Ingress、APISIX Ingress 以及 MSE 云原生网关 Ingress，并且在这个基础上全链路灰度能力也会进一步升级，支持基于各种 Ingress-Provider 网关的全链路灰度能力。

尾

我们发现在云原生抽象的 Ingress 下，再谈全链路灰度，一切问题都变得更加标准化与简单起来。本文通过介绍各种 Ingress 网关实现的路由转发能力，再配合上基于“泳道”实现的 Ingress 全链路灰度方案，企业可以快速落地全链路灰度这个微服务核心能力。

原文链接

本文为阿里云原创内容，未经允许不得转载。