前言大家好，我是堆栈管理员。近日，栈管家参加了腾讯云小伙伴邀请的TechoDay2.0线上活动。本期干货满满，主要是云原生和微服务，比如：云原生网关、容器、安全、云监控、灰度发布等，这些内容和我们现有的微服务体系息息相关。最让堆栈管理员印象深刻的是微服务灰度发布的主题。腾讯开源的北极星让我大开眼界。不仅涵盖微服务的多种解决方案，还包括开源一站式灰度，这在市场上是少见的。发布解决方案。看到这里，你可能会有以下疑问：什么是灰度发布，它能给我们的业务带来什么好处？我知道灰度发布，但是实现灰度发布的方式那么多，我该如何选择呢？Polaris是什么，它和我现在用的灰度发布框架有什么区别？针对大家的问题，我觉得有必要专门跟大家分享一下，包括灰度发布的基本认识和分类，特别是腾讯开源的Polaris项目，看看它是如何轻松解决灰度发布的。什么是灰度发布？说到灰度发布，就不得不提“全量发布”。全面发布是指所有系统同时推出新版本，即所有用户同时使用新版本。这会造成什么问题？全量发布的各种弊端：影响用户体验：比如某系统在双十一前上线了一个新功能，需要给符合条件的用户发放优惠券。结果是程序的一个bug导致所有用户发出...或者新版本系统有问题，影响到所有用户...系统异常扩散的风险：比较快的一个内存溢出异常系统上线后，流量转移到系统其他实例，导致系统所有实例内存溢出。实例都处于不可用状态……影响服务可用性：全量发布一般需要全部停机升级，保证要么是新版本，要么是旧版本。这显然会造成业务中断，也会影响服务可用性（SLA），就是我们经常看到互联网公司喊口号，今年一定要做到3个9、4个9，也就是99.9%、99.99%等等。SLA是衡量系统服务可用性的保证。9越多，全年提供的服务就越多。时间越长，服务越可靠，停机时间越少，反之亦然。……知道了全量发布的种种弊端，就不得不提到灰度发布的重要性。这里定义一下灰度发布：灰度发布是对“全量发布”的改进，即按照一定的策略推出一些新的发布。版本，同时保留老版本，然后让部分用户体验新版本，收集一段时间对新版本的反馈，比如：功能、性能、稳定性等指标，再决定是否要逐渐升级，直到完全升级或回滚到旧版本Version。灰度发布的好处：减少发布的影响：即使有问题，也只会影响部分用户，这样可以提前发现新版本中的问题/bug，在下一个之前提前修复灰度发布，避免影响更多用户；提升用户体验：除了提前发现bug，还可以在新版本中收集用户反馈，从而提前优化系统，提升用户体验，为后续产品演进带来参考价值。灰度发布分类灰度发布的主要分类：金丝雀发布、滚动发布、蓝绿发布，相信大家或多或少都听过这些名词的概念，但是很多人并不知道其背后的原理和发布流程，下面stack我画了几张长图，让大家对这些灰度发布有更深入的了解。1）金丝雀发布据说以前有个典故。在挖矿之前，矿工们会放下一只金丝雀，看金丝雀有没有活下来，用来检测有没有毒气。金丝雀版本也是由此衍生而来。姓名。这个典故用在金丝雀发布中也是一样的道理，就是先升级服务的一个实例，如果这个实例没有问题，再升级剩下的所有实例，有问题就回滚。金丝雀发布成本低，只需要一个实例，降低新版本风险。适用于缺乏足够的发布工具开发能力和成长性的小型和成长型公司。但是，金丝雀发布也有缺点。在升级所有剩余实例时，如果流量过大，可能会导致服务中断。2）滚动发布滚动发布是在金丝雀发布的基础上进行的改进和优化。金丝雀发布也是首次使用，其余实例将在后续分批次分批发布。每批之间都会观察，如果有问题就回滚。滚动发布相对平稳，可以将风险降到最低。虽然改进了金丝雀发布，但整体发布时间会更长，回滚时间会更慢，整体流程会更复杂。适用于具有一定发布工具开发能力的大公司。3）蓝绿发布蓝绿发布比较简单，只是对fullrelease的优化。不是在发布之前关闭所有实例，而是部署新版本的所有实例，然后将所有流量切换到新版本。蓝绿发布虽然提升了服务可用性，但并没有解决新版本可能出现的问题，所以核心业务肯定不推荐。建议滚动发布结合金丝雀发布，降低发布风险。4）如何选择以上三种灰度发布模式，那么企业应该如何根据自身业务场景的需求，选择采用哪种模式进行灰度发布呢？以下是各种发布模式的比较，以及常见的选择指南列表，供大家参考。Strategy零宕机生产流量测试针对回滚时间对特定用户机器资源成本的负面影响demand)Fast,low,medium,fulllinkgrayscale√√√Medium(ondemand)Fast,low,high,fullrelease：不推荐，除非真的没办法，比如什么都缺的创业公司，老板催促。蓝绿发布：适用于资源预算充足的业务，或者单体应用比较简单，可以快速实现系统的整体变更，适合传统企业。金丝雀和全链路灰度：适用于需要对特定用户或人群进行现网请求验证的业务，可显着降低风险，推荐成长型企业使用。业界灰度发布实现方案Nacos/ZK+SpringCloud/dubboNacos和ZK组件提供纯注册功能，不含灰度发布能力。如果用户需要实现灰度发布，需要在框架层通过编码进行扩展，比如实现SpringCloudGateway/Dubbo插件等。主要有两个问题：不同业务需要重复造轮子，这带来不必要的工作量和质量风险不同的框架有不同的实现方法和规则，存在互操作性问题。istioIstio通过服务网格提供灰度发布能力。用户无需自行实现灰度发布逻辑，但也存在以下问题：istio的数据平面不支持SpringCloud/Dubbo等常用微服务框架的接入。istio+envoy的Proxy模式在运行时会带来额外的资源和网络开销。腾讯云实施方案（北极星）基本介绍先简单介绍一下腾讯云引擎（TSE）：腾讯云服务引擎为云上所有场景提供开箱即用的微服务解决方案。支持开源增强型云原生注册配置中心（Zookeeper、Nacos、Etcd、Consul、Eureka、Apollo）、服务治理中心（腾讯自研开源PolarisMesh）、云原生网关（NginxIngress、Kong）)和微服务应用托管弹性微服务平台。微服务引擎完全兼容开源版本的使用，在功能、易用性、可操作性等多方面进行了增强，帮助用户快速构建微服务架构。PolarisMesh是腾讯的开源服务发现和治理中心。在注册配置中心的基础上，扩展了服务治理功能和相应的控制面。各部分功能可独立使用，支持非侵入式接入方案。用户无需更改一行代码即可访问所有服务管理功能。基础：服务发现、服务注册、健康检查、配置管理；扩展：流量调度（动态路由、负载均衡）、熔断降级（实例、接口、服务三级熔断）、访问控制（限流、鉴权）、观察（调用指标、链路跟踪）表明Polaris不仅是一个注册中心和配置中心，也是微服务架构中容错、流控、安全问题的综合解决方案。虽然业界已经有一些组件可以解决其中的一些问题，但是缺乏一个标准的、多语言的、框架无关的实现，Polaris应运而生。实现方案Blue-green,canary,rollingreleases可以通过Polaris实现：Phase1:Instancemarking实例标记是指实例在发布前标记成一个新的版本标签，这样新版本和稳定的旧版本可以结合起来应用程序是有区别的。常用的实例标记方式有两种：实例自注册：在项目的配置文件中配置标签，一般是指SpringCloud的配置文件，然后在应用时自动将标签注册到注册中心;k8s部署标签同步：将实例标签配置为k8s的部署标签，应用部署完成后自动同步到注册中心。Phase2:GatewayRouting服务网关，即服务的网关，是所有服务的单一接入点，充当微服务的顶级代理。通俗地说，就是外部请求需要先经过服务网关，然后才能到达微服务。服务网关实现统一访问，外部请求无法直接访问微服务。一般的访问顺序是：用户>Nginx（集群，Keepalive）>服务网关（集群）>微服务（集群）因此，要进行灰度发布，必须在网关层进行路由控制。在网关层，可以根据一定的策略将流量分配给不同的实例版本。常用的灰度策略包括百分比、用户属性、省份和地区等，比如你可以先把广东省深圳市30%的用户路由到新版本。一般的服务网关需要自己配置路由规则，而且都是硬编码配置。有很多复杂的配置项。非专业技术人员很难理解其配置的真正含义，这也带来了出错的概率。在腾讯云Polaris方案中，采用了云原生网关，支持图形化配置云原生路由规则，支持直连注册中心，直接将流量拆分到不同版本的实例中，大大简化了配置难度和improves提高了配置项的可读性和易用性。Phase3：微服务路由看一张普通的路由流程图：流量经过服务网关后，需要路由到具体的微服务，而灰度发布后，每个微服务都有一个旧版本的V1和一个新版本V2的，因此需要确保路由过去的多个微服务调用链也必须是同一版本，否则可能会导致灾难性的故障。腾讯云北极星服务治理中心提供路由定制能力，支持通过图形化配置规则自动托管，实时监控服务调用流量，精准把握灰度发布全流程，实现微服务化。灰度流量调度。阶段四：标签透传在上一步中，网关层会对灰度流量进行着色。在接下来的微服务调用过程中，还需要标签透传，即在各个微服务之间传输彩色标签，以便微服务服务识别灰度流量并进行处理。使用SpringCloud微服务框架需要用户自己在项目中实现编码，而腾讯Polaris方案可以配合腾讯的SpringCloud腾讯微服务框架自动完成标签透传，支持跨线程透传模式，无需用户感知。第五阶段：灰度完成1）灰度发布验证灰度发布后，如何验证灰度发布已经完成/成功？一般需要进行以下确认操作：1）确认流量是否按计划切换到灰度发布实例；2）确认灰度发布实例上的请求是否正常执行；腾讯云Polaris解决方案提供了服务治理监控能力，支持可视化查看流量的实时切换和流量的成功率、时延等关键指标，大大简化了灰度发布的后期验证工作。2）灰度完成后的处理事项，根据不同的灰度发布形式进行处理：金丝雀发布：稳定版服务群全面升级到新版本。滚动灰度：将稳定版本组中的多项服务按一定比例批量升级到新版本。蓝绿发布：流量已经全部切换到新版本集群，老版本集群实例可以下线。Polaris开源版体验PolarisMesh官网：https://polarismesh.cn/PolarisMesh已经开源，点击首页右上角进入试用版：按照提供的默认用户名和密码登录，你可以去“服务网络去网格>动态路由>灰度发布”找到灰度发布：来体验金丝雀发布。运行流程如下：第一步：实例标记Polaris的SpringCloud腾讯微服务集成流程。具体可以参考以下链接进入文档：https://polarismesh.cn/zh/doc...然后在bootstrap.yml配置文件中指定版本标签：spring:cloud:tencent:metadata:content:version:2.0.0服务实例所在的操作在系统中添加环境变量也可以标注，例如：SCT_METADATA_CONTENT_version=2.0.0。由于SpringCloud框架默认不会透传所有请求标签，所以需要添加SpringCloud透传标志，灰度标志（gray:true）可以通过添加环境变量（SCT_PROTOCOL_CONTENT_TRANSITIVE_HEADER=gray）透传.第二步：部署应用SpringCloud腾讯的接入方式支持虚拟机、DockerComposer、K8S等多种部署方式，注意需要保证业务进程与Polaris服务之间的网络连通。部署完成后，可以在Polaris服务列表中看到注册成功的服务实例：第三步：微服务路由通过配置微服务路由，灰度版本流量的调用只在新版本的服务组中进行。可以在“ServiceMesh>DynamicRouting>CustomRouting”中新建路由规则，首先配置灰度规则：该灰度规则只对信用服务生效，这样header中带有gray:true灰度标签的请求就会只流向version=2.0.0的Instance分组。接下来配置catch-all规则：该灰度规则只对信用服务生效，所以header中没有gray:true灰度标签的请求只会流向version=1.0.0的实例组。第四步：观察灰度发布通过Polaris的观察能力，可以准确的看到不同群体流量切换的过程和服务调用的成功率。当灰度组的相关指标没有问题时，即表示灰度验证完成。观察路径：“可观察性>路由监控”第五步：灰度发布完成灰度验证完成后，需要做的是：如果灰度验证成功，按照旧版本分组的实例将升级到新版本滚动方式；否则，回滚；删除Polaris控制台中的自定义路由规则；可以看到，Polaris提供了一套完整的灰度发布解决方案，适用于各种灰度发布流程，灰度规则的配置可以直观的轻松实现。提供灰度可视化观察，让灰度发布更方便，更可控。总结看到这里，想必大家对灰度发布有了一定的了解，尤其是腾讯云提供的Polaris一站式解决方案，通过其独特的架构理念和可视化平台解决了微服务应用过程中的各种问题。困难，如果没有灰度发布的加持，全量发布带来的风险将变得困难重重。由于用户数量或研发成本，现在很多公司甚至不使用灰度发布。且不说完全释放对SLA的影响，一旦损失不可估量，那么无论公司处于什么成长阶段，都必须释放。灰度发布是对用户负责，也是公司可持续发展的重要保障。这里是Polaris的Github地址。欢迎大家点击Github：https://github.com/polarismeshPolaris作为微服务的综合开源解决方案，在腾讯内部也得到了广泛的应用：从数据可以看出，Polaris在腾讯内部的应用非常广泛腾讯，几乎涵盖了所有业务。经过这么多年的洗礼，Polaris也是一个成熟稳定的项目。所以可靠性还是有保证的，不管适不适合，闭着眼睛都能用。值得大家去体验一下。最后，通过参加腾讯云的TechoDay2.0技术开放日活动，栈长最大的感受就是在技术领域，腾讯云确实走在了前列。该解决方案涵盖了我们日常开发的方方面面。不仅可以学习和接触新兴技术，还可以对技术有更多更深入的了解，尤其是stackmanager推出的Polaris灰度发布，真正帮助企业提升项目质量，规避发布风险。近期热点文章推荐：1.1000+Java面试题及答案（2022最新版）2.厉害了！Java协程来了。..3.SpringBoot2.x教程，太全面了！4.不要用爆破爆满画面，试试装饰者模式，这才是优雅的方式！！5.《Java开发手册（嵩山版）》最新发布，赶快下载吧！感觉不错，别忘了点赞+转发！
