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

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 如何落地可灰度、可观测、可回滚的安全生产三板斧能力,满足业务高速发展情况下快速迭代和小心验证的诉求,是企业在微服务化深入过程中必须要面对的问题。在云原生流行的当下,这个问题又有了一些新的思路与解法。

作者:魁予、十眠


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


Kubernetes Ingress 网关


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


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


1.jpeg


通过对比可以看到 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 配置路由转发


2.jpeg


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


ALB Ingress


1、ALB 产品介绍


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


3.png


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 配置路由转发


4.png


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 进行后续处理。


5.png

image.gif

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


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


6.jpeg


如上图所示,我们部署了 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 的应用路由


7.png

image.gif

上图是 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 应用等。


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


8.png

image.gif

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


全链路灰度的技术解析


image.gif9.png


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


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


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


10.jpeg


全链路灰度的产品实现


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


MSE 全链路灰度方案


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


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


  • 端到端的稳定基线环境

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


  • 流量一键动态切流

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


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

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


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


11.png

image.gif

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


12.png

image.gif

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

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


1、创建流量泳道组


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


13.png


2、创建流量泳道


在使用泳道功能前,我们默认已经存在了一个包含所有服务在内的基线(未达标)环境。image.gif


14.png


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


15.png

image.gif

然后需要去配置流量入口的 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 等微服务运行环境,助力您的应用轻松上云。image.gif


16.png


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


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


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


17.png


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


18.png


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

19.png


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


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


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


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


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


20.png


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


21.png


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


22.png


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


4、更进一步


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




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


点击文末“此处”,了解更多产品相关~

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
26天前
|
Cloud Native Devops 持续交付
构建未来:云原生架构在现代企业中的应用与挑战
【2月更文挑战第31天】 随着数字化转型的加速,云原生技术已经成为推动企业IT架构现代化的关键力量。本文深入探讨了云原生架构的核心组件、实施策略以及面临的主要挑战。通过分析容器化、微服务、DevOps和持续集成/持续部署(CI/CD)等关键技术,揭示了如何利用这些技术实现敏捷性、可扩展性和弹性。同时,文章还讨论了企业在采纳云原生实践中可能遇到的安全性、复杂性和文化适应性问题,并提供了解决这些问题的策略和建议。
|
1月前
|
云安全 安全 Cloud Native
企业如何做好云原生安全
云原生安全不仅仅关注云计算普及带来的安全问题,它更强调以原生的思维来构建云上的安全建设、部署与应用,推动安全与云计算的深度融合。将安全能力内置于云平台中,实现云化部署、数据联通、产品联动,这有助于充分利用安全资源,降低安全解决方案的使用成本,实现真正意义上的普惠安全。
|
22天前
|
运维 Cloud Native 持续交付
云原生架构的未来演进:打造灵活、高效的企业IT基础
随着数字化转型的不断深入,企业的IT基础设施正经历着从传统架构向云原生架构的根本转变。本文将探讨云原生技术的最新发展趋势,分析其在提高业务敏捷性、降低运维成本以及促进技术创新方面的关键作用。我们将重点讨论如何借助容器化、微服务、DevOps和持续交付等核心技术,构建一个能够适应快速变化市场需求的云原生生态系统。通过实际案例分析,揭示企业在迁移到云原生架构过程中面临的挑战与解决策略,为读者呈现一幅云原生技术赋能企业未来的蓝图。
|
4天前
|
Kubernetes 监控 Cloud Native
构建高效云原生应用:基于Kubernetes的微服务治理实践
【4月更文挑战第13天】 在当今数字化转型的浪潮中,企业纷纷将目光投向了云原生技术以支持其业务敏捷性和可扩展性。本文深入探讨了利用Kubernetes作为容器编排平台,实现微服务架构的有效治理,旨在为开发者和运维团队提供一套优化策略,以确保云原生应用的高性能和稳定性。通过分析微服务设计原则、Kubernetes的核心组件以及实际案例,本文揭示了在多变的业务需求下,如何确保系统的高可用性、弹性和安全性。
11 4
|
19天前
|
Java fastjson 数据安全/隐私保护
【Dubbo3技术专题】「云原生微服务开发实战」 一同探索和分析研究RPC服务的底层原理和实现
【Dubbo3技术专题】「云原生微服务开发实战」 一同探索和分析研究RPC服务的底层原理和实现
38 0
|
19天前
|
Cloud Native Dubbo 应用服务中间件
【Dubbo3技术专题】拥有新时代的通信协议,引领云原生迈向更高的舞台 | 解密Dubbo3是如何从微服务升华到云原生领域
【Dubbo3技术专题】拥有新时代的通信协议,引领云原生迈向更高的舞台 | 解密Dubbo3是如何从微服务升华到云原生领域
36 1
|
27天前
|
Cloud Native 安全 Devops
构建未来:云原生架构在现代企业中的应用与挑战
【2月更文挑战第30天】 随着数字化转型的深入,企业正迅速采纳云原生技术以适应不断变化的市场环境。本文探讨了云原生架构的关键组成部分,包括容器化、微服务、持续集成/持续部署(CI/CD)和DevOps实践,并分析了它们如何促进企业的敏捷性和可扩展性。同时,文章也识别了企业在采用云原生技术时面临的安全、文化和技术挑战,并提出了相应的解决策略,以帮助企业在云时代保持竞争力。
|
27天前
|
监控 Cloud Native 云计算
构建未来:云原生架构下的微服务治理
【2月更文挑战第30天】随着云计算的不断演进,云原生技术逐渐占据了软件开发与运维的核心地位。本文深入探讨了在云原生生态系统中,如何有效管理和治理微服务,确保系统的高可用性、可扩展性和安全性。通过对容器化技术、服务网格、以及微服务框架的剖析,我们展示了在云平台上构建和管理微服务的先进策略和实践。
|
9天前
|
API 数据库 开发者
构建高效可靠的微服务架构:后端开发的新范式
【4月更文挑战第8天】 随着现代软件开发的复杂性日益增加,传统的单体应用架构面临着可扩展性、维护性和敏捷性的挑战。为了解决这些问题,微服务架构应运而生,并迅速成为后端开发领域的一股清流。本文将深入探讨微服务架构的设计原则、实施策略及其带来的优势与挑战,为后端开发者提供一种全新视角,以实现更加灵活、高效和稳定的系统构建。
16 0
|
23天前
|
负载均衡 测试技术 持续交付
高效后端开发实践:构建可扩展的微服务架构
在当今快速发展的互联网时代,后端开发扮演着至关重要的角色。本文将重点探讨如何构建可扩展的微服务架构,以及在后端开发中提高效率的一些实践方法。通过合理的架构设计和技术选型,我们可以更好地应对日益复杂的业务需求,实现高效可靠的后端系统。