首页 > 其他分享 >基于 Istio 的灰度发布架构方案实践之路

基于 Istio 的灰度发布架构方案实践之路

时间:2023-11-13 16:12:31浏览次数:31  
标签:方案 服务 配置 环境 Istio 流量 灰度 架构

1. 背景介绍

灰度发布,又名金丝雀发布,是指能够平滑过渡的一种发布方式。基于系统稳定性和快速业务迭代的综合考虑,业务应用开发团队采取了新版本服务灰度上线的方式,即新版本服务并非全量发布到线上环境,而是发布少数几个实例进行灰度验证,没有问题后再全量发布。在部分核心服务进行接口升级和逻辑迁移时,还会通过在业务逻辑代码中增加黑白名单或者流量百分比控制的方式,逐步将旧版本接口实现迁移至新版本接口实现。尤其是对于toB业务和SAAS类平台,很多情况需要根据租户或用户维度进行灰度控制,实现业务上的A/Best功能。

对于之前我们业务中实现的传统的灰度发布, 较好地权衡了服务稳定性和业务迭代效率,但仍存在以下问题:

a. 系统侵入性强,业务开发人员在服务接口中编码大量与业务逻辑无关的黑白名单或流量百分比控制代码。

b. 当新版本接口出现波动或异常,通常需要业务团队通过紧急修改代码和紧急发布,来更新黑白名单和流量百分比控制策略,时间较长,业务影响较大。

c. 调整黑白名单或流量控制百分比,需要业务团队发布代码或者接入动态配置中心,过程复杂、可复用性差、操作灵活性差.

d. 对于单体应用来说,灰度发布方案实现还算简单,但对于微服务应用,每次发布版本可能不是全部服务需要灰度发布,实现微服务灰度发布的原子维度控制,也是导致微服务框架下灰度方案不能很好落地的原因。

笔者实际业务项目(采灵通系统)采用的是微服务的架构设计,总计服务个数60+,技术底座采用K8s+Istio的服务治理方案。如果采用传统的灰度发布方案,每个服务上下游依赖过多,相对于传统的灰度发布方案,并不能很好满足业务诉求。因此,探索了一条基于Istio的服务流量治理方案下的灵活可配置的灰度发布方案。

2. 方案详情

先上一个方案简介图:

本发明的技术方案以k8s服务部署为基础,以istio服务流量治理为核心,以Mysql为数据存储,同时结合jenkins的自动化部署方案,可以实现低成本动态的高效微服务发布方案,并且带业务服务无代码侵入。

本发明的技术方案以activiti开源工作流引擎为基础, 以Mysql作为数据存储, 通过自定义的一套规则引擎框架, 可以实现流程规则的的快速搭建和动态修改功能.

a. 如图所示,k8s management实现对服务的pod管理,在k8s管理中,正式环境和灰度环境分别隶属两个命名空间,通过deployment实现服务的创建,创建中,灰度和正式的pod实例会打上prod或gray的标签。Deployment创建过程通过jenkins管理,可以实现部署的自动化流程。具体deployment配置方案详情请跳转至3.2.2

b. 如图所示,istio控制平面可以创建虚拟服务,通过对虚拟服务的路由策略的配置不同,可以实现不同的灰度策略,配置下发通过jenkins管理,可以实现配置的自动化下发。具体策略详情请跳转至2.1

c. 如图所示,具体业务请求实现流程如上:

1. 用户首先需要登录请求,请求发动到我们自建的认证中心服务中。如图中1标所示。

2. 认证中心接收到请求会到cookie生成器中获取用户认证的cookie,如图中2标所示

3. Cookie生成器会到数据库中读取灰度白名单信息,来确定是否在cookie中打灰度标签。如图中3标所示。

4. 认证中心拿到cookie后返回给前端用户 ,如图中4,5标所示。

5. 用户带着cookie请求业务请求到虚拟服务A.虚拟服务A中存在istio控制面板下发的的灰度配置信息,通过配置信息,决定当前的请求流量是流入正式环境实例A还是灰度环境实例A。如图中6,7标所示。

6. 服务A中存在调用服务B的业务逻辑,所以服务A会请求到虚拟服务B中,虚拟服务B中存在istio控制面板下发的的灰度配置信息,通过配置信息,决定当前的请求流量是流入正式环境实例B还是灰度环境实例B。如图中8标所示。

通过以上8个步骤,我们完成了灰度方案下的流量管控,该方案对于业务服务A和业务服务B无任何代码侵入,同时,灰度的配置方案可以实时快速的通过jenkins管理页面进行自动化下发,实现灰度发布的动态灵活切换.

至于灰度环境的低成本,当代码完成灰度拉平线上后,通过更改灰度下发策略,可以实现灰度环境和正式环境的负载均衡,共同承担正式环境的业务流量,保证了灰度环境的主机资源不会被浪费。

2.1 k8s Management管理

在k8s管理方面,要创建两个命名空间,一个是prod环境,一个是gray环境,通过命名空间隔离正式环境和灰度环境资源,主要原因是可以更好的管理。当然此处并不强制。同时,需要配置一下deployment的标签项,在标签项增加一个profile键,根据场景,profile可以配置为prod和gray,具体配置demo如下图所示。

2.2 基于istio灰度整体配置方案

灰度整体方案流程图如上图所属,该流程图中主要分为三大整体方案,包括:基于用户白名单的灰度方案,按照流量百分比灰度方案,灰度拉平线上的负载均衡方案。以上灰度环境可以满足之前提到的多场景,低成本,动态,无侵入的灰度方案要求。

以下2.3,2.4,2.5将分别详细介绍三种灰度方案的具体配置策略。

2.3 基于用户白名单的灰度方案策略

1. cookie中打标签。

通过认证中心,可以实现业务维度的灰度控制,cookie中会根据用户白名单,进行灰度打标签。Cookie格式如下:

cookie:tenantGray=0;rememberMe=*********;channel=

当tenantGray=0时,表示当前用户不是灰度用户,当tenantGray=1时,表示当前用户是灰度用户。

2. 当选择根据cookie动态配置灰度服务时,根据选中的服务,virtualService配置如下:

如图所示,当请求的cookie信息匹配到tenantGray=1时,根据istio的虚拟服务规则,走test-A.gray.svc.cluster.local路由,然后请求会打到灰度环境的服务实例上。当tennatGray=0时,根据istio的虚拟服务规则,走test-A.prod.svc.cluster.local的路由,然后请求会打到正式环境的服务实例上。

3. 如果用户选择根据灰度标签进行灰度方案选择,配置方案如下:

在k8s集群中我们之前创建灰度服务的deployment时,当时增加过一个标签,标签为profile: pray,用来标记该服务为灰度服务。

如图所示配置,match条件为,当请求来源是来自带有灰度标签的deployment服务时,走test-A.gray.svc.cluster.local路由,然后请求会打到灰度环境的服务实例上。反之,走test-A.prod.svc.cluster.local的路由,然后请求会打到正式环境的服务实例上。

4. 然后把所有需要灰度发布的服务对应的vistualService的配置信息通过jenkins的自动化流程下发到k8s集群中。

2.4 按照流量百分比的灰度方案

当我们的业务场景不需要针对具体的用户进行灰度时,尤其是我们只是在一定范围内做A/Btest,这样的话,我们可以更改配置信息,实现业务的按照流量比例进行灰度控制,具体的配置virtualService方案如下:

2.5 灰度拉平线上的负载均衡方案

该灰度方案比较明确,就是当该服务不再需要灰度时,为了不浪费服务器资源,将灰度服务跟线上服务代码拉平,然后通过流量管理,正式环境的流量实现负载均衡的目的。假设灰度服务跟正式服务的服务实例数比率为1:1,具体virtualService配置如下:

2.6 微服务灰度发布治理方案

众所周知,对于单体应用来说,灰度发布只需要对单一服务进行灰度控制就会要了。但是到了微服务框架下,会存在众多服务,服务之间存在复杂的网络拓扑关系,所以当我们进行服务的灰度发布时,需要控制服务之间的灰度调用关系,实现灰度发布的服务治理功能,解决了微服务框架下动态管理多服务之间的灰度方案串联问题。

以下举例三种不同的灰度治理场景。

a.以下实例场景是,服务A采用基于灰度白名单的灰度策略,服务B采用灰度拉平线上的灰度策略,然后服务A访问服务B,可以实现服务A的灰度发布,服务B为正式环境。

b. 下图实例场景是,服务A采用基于灰度白名单的灰度策略,服务B采用基于服务灰度标签的访问策略,然后服务A访问服务B,可以实现灰度服务A的流量访问灰度服务B,正式服务A的流量访问正式服务B。

c. 图实例场景是,服务A采用基于流量比率的灰度策略正式环境和灰度环境的比率为8:2,服务B采用基于灰度白名单的灰度策略,然后服务A访问服务B时,在灰度白名单中的用户,在灰度服务B,不在灰度白名单中的用户,走正式服务B。

3. 总结

通过本次基于Istio的灰度方案的实践,最大感触就是基于服务网格的第二代微服务架构的优秀潜力。Service Mesh对流量的管理可以下沉至运维维度,并且灵活度是第一代微服务架构不可比拟的。通过这次时间,很好的解决了笔者现实业务中的灰度发布问题,实现了通过配置自动化下发,无代码侵入,实现动态切换等多种灵活策略

4. 名词解释

k8s:kubernates的简称。k8s是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes提供了应用部署,规划,更新,维护的一种机制

istio:Istio 是一个开源服务网格,它透明地分层到现有的分布式应用程序上。

负载均衡:意思是将负载(工作任务,访问请求)进行平衡、分摊到多个操作单元(服务器,组件)上进行执行

virtualService:istio内置的一种配置类型,叫做虚拟服务,可以设置单独的路由指向。通过virtualService可以实现istio的流量管理。

灰度拉平:是指将正式环境的服务代码跟灰度环境的服务代码拉成一致的。

来源:

https://www.modb.pro/db/618095

标签:方案,服务,配置,环境,Istio,流量,灰度,架构
From: https://www.cnblogs.com/gaoyanbing/p/17829377.html

相关文章

  • VPC终端节点的实现架构和原理
    本文分享自天翼云开发者社区《VPC终端节点的实现架构和原理》,作者:云云生息什么是VPC终端节点?在传统的VPC架构中,为了使VPC内的资源能够与云服务提供商的各种服务进行通信,通常需要通过公共Internet进行访问。这种方式存在一些问题,比如安全性、可靠性、访问速度等。为了解决这些问......
  • 微服务架构【原理】
    一、架构图        微服务访问大致路径为:外部请求→负载均衡→服务网关(GateWay)→微服务→数据服务/消息服务。服务网关和微服务都会用到服务注册和发现来调用依赖的其他服务,各服务集群都能通过配置中心服务来获得配置信息。二、服务网关(GateWay)   ......
  • 第十一章、web前端架构师
    目录二十四、自研统计服务,使作品能实现分渠道统计1、二十四、自研统计服务,使作品能实现分渠道统计1、......
  • 从混乱到优雅:基于DDD的六边形架构的代码翻新指南 | 京东物流技术团队
    前言趁着双十一备战封板,终于又有一些时间可以梳理一下最近的心得。最近这半年跟同事讨论比较多的是分层架构,然后就会遇到两个触及灵魂的问题,一个是如何做好分层架构,二是DDD在架构层面该如何落地。为了说好分层,我们需要了解架构的意义。良好的架构是为了保证一下两点:治理应用复杂度,......
  • 《大型网站技术架构--核心原理与案例分析》阅读笔记
    这本书组织的很不错,语言精练,篇幅也不长,对网站架构的要点讲的狠清楚透彻,思路清晰。主要围绕架构的五个要点:性能、高可用、伸缩性、扩展性、安全性。令人印象非常深刻。而且李智慧老师深谙职场之道,后面一些关于技术人的建议也让人受用无穷。事物发展到一定阶段,就会拥有自身的发展冲......
  • Service Mesh:微服务架构的救世主还是多余的花招?
    ServiceMesh的前世今生在前面,我们提出了一个问题:随着模块和节点的增多,微服务之间难免会遇到各种网络问题。为了解决这些问题,目前有一个解决方案,即使用SpringCloud中的各个组件。然而,这种解决方案不仅需要更多的学习成本,而且对代码有一些要求,比如必须使用Java开发。这就导致了系......
  • 系统架构性能优化之Tomcat
    ......
  • 解锁清晰代码-每位开发者的20个架构技巧
       清晰架构原则对于任何希望创建健壮、可维护和可扩展软件的软件开发者来说都至关重要。理解并实施这些概念可以显著提升你的编程技能。以下是对20个基本架构洞见的深入探讨:依赖规则:清晰架构的核心是依赖规则。它规定源代码的依赖关系应始终指向内部。这种内向的方向确保了......
  • 云原生架构实战07 Kubernetes的核心实战 下
    7、存储抽象pod如果挂掉,在其他的机器启动新pod,原来pod的数据是无法迁移到新机器的;所以使用单独的存储层来解决。将节点上的文件或目录挂载到pod上,此时该目录会变成持久化存储目录,即使Pod被删除后重启,也可以重新加载到该目录,该目录下的文件不会丢失。nfs卷能将NFS(网络文件系统)挂载......
  • 分布式亿级流量整体架构设计原则
    架构目标高可用性整体系统可用性最低99.9%,目标99.99%。全年故障时间整个系统不超过500分钟,单个系统故障不超过50分钟。高可扩展性系统架构简单清晰,应用系统间耦合低,容易水平扩展,业务功能增改方便快捷。低成本增加服务的重用性,提高开发效率,降低人力成本;最终......