互联网金融时代下，金融产品和服务模式不断创新，金融系统容量需求急剧增长，为进一步满足运维标准提升工作的需求，提升服务连续性水平。中国工商银行（后简称工行）从 2014 年开始分布式架构转型的技术预研工作，通过对开源微服务框架深入调研和技术选型后，确定了基于开源 Dubbo 自主研发建设分布式服务平台，并结合金融场景，工行在 Dubbo 基础上对服务的注册、发现等核心能力进行了三十余项定制，以支持单注册中心超 70 万提供者的超大规模业务场景。分布式服务作为分布式体系的核心能力，助力工行应用架构向分布式、服务化转型，承载未来开放平台核心银行系统。
全链路灰度目前是一个比较热门的技术栈，几乎是服务治理领域中必备的，所以咱们必须要搞清楚它，这样才能为自己的技术硬实力去添砖加瓦。假如现在让你去做好全链路灰度，你会怎么去做了，如果面试官这样去问你，你该怎么去回答呢？建议大家可以从如下三个方面去回答：
近几年，随着有赞用户的迅速增长和业务的快速发展，对业务开发人员要求越来越高，一方面要求为用户提供稳定的服务，一方面要求进行快速业务迭代。然而，随着公司业务复杂度和服务化整体规模的增长，单个业务功能涉及的微服务接口数、服务化调用链路长度都在迅速增加，业务的回归测试越来越难以覆盖到所有的调用链路和业务逻辑，通过仅在测试环境进行业务测试的方式来保证系统稳定性的难度越来越高。
灰度系统是用来帮助 API 服务在上线时按照受众从小到大最终至全量的发布，实现功能的灰度上线，用来保证发布的服务的质量的系统。
随着企业数字化转型进程不断发展，云原生时代的来临，企业应用越来越多，不得不面对应用程序升级的巨大挑战。传统的停机发布方式，新旧版本应用切换少则停机30分钟，多则停机10小时以上，愈发无法满足业务端的需求。
灰度发布并非是近几年才兴起的概念，诞生有一定的年头了，但至今，绝大多数中小型互联网企业的发布流程中仍然缺少对灰度环境的支持，其主要原因在于大家对灰度的认知及成本等方面的综合考虑。我前段时间曾就职于一家初创型互联网企业，就发布流程而言，用“脏乱差”来形容似乎并不为过，并且，大部分人对环境的认知也仅限于开发（DEV）、测试(FAT)，以及生产(PRO)，从严谨性和专业性等2个角度来看，这并不合理。互联网企业的一大特点就是服务的功能变动异常频繁，自然发布的节奏也随之变得急促起来，缺少预发布环境和灰度环境的支撑，高频的服务发布往往会伴随着巨大的风险，以及那令人极度失望的服务质量。因此，本文将重点讨论一种平滑的服务发布方式，以便于帮助企业有效降低风险的影响范围。
蓝绿部署是一种应用发布模式，可将用户流量从先前版本的应用或微服务全量转移到新版本中（两者均保持在生产环境中运行）。
两年前，我在学习K8s的时候有写过一篇基于Nginx Ingress实现灰度发布的博文。这次，我们基于Kong来实践一下。灰度发布的具体实现其实是流量切分，那就让我们先回顾一下流量切分的实现方式。
而且灰度系统支持设置流量的比例，比如可以把走新版本代码的流量设置为 5%，没啥问题再放到 10%，50%，最后放到 100% 全量。
对应到软件开中，则是指在发布新的产品特性时通过少量的用户试点确认新特性没有问题，确保无误后推广到更大的用户使用群体。
框架解耦的流量管理能力作为ServiceMesh的看家本事，一直是大多数团队选择ServiceMesh的主要原因。传统的流量管理大多需要在框架层面集成一种中心化的服务发现中心，通过服务发现中心去做流量控制分发。这对服务发现中心的的稳定性要求很高，同时限制了框架选择和扩展性。而ServiceMesh基于 sidecar 形式通信代理，将服务和流量控制解耦，服务不关心流量从哪里来，去往哪个具体ip，sidecar通过流量劫持的形式，对进出服务的流量进行修改，达到控制流量的目的，类似中间人攻击。
究竟什么才是灰度发布其实并没有一个严格的标准，因为这个东西不是黑的也不是白的是个中间过渡地带，这类的东西定义都会比较麻烦。由于工作的原因看到好多友商所谓的灰度发布产品，有意思的是他们实现的是完全不一样的功能，对外都说自己是灰度发布。我看到的有三种：
“ 关注 前端开发社区 ，回复"1"即可加入 前端技术交流群，回复 "2"即可免费领取 500G前端干货
最近，栈长又参加了腾讯云小伙伴邀请的Techo Day 技术开放日 2.0的线上活动，这一期又是干货满满，主要是云原生和微服务方面的，比如：云原生网关、容器、安全、云监控、灰度发布等等，这些内容都与我们现有的微服务系统息息相关。
导语 在服务实例数量和规模较大的业务场景下，服务路由是系统比较常见的诉求，比如针对业务属性的全链路灰度、测试环境多分支路由、多Region多AZ时的就近路由等。TSF基于标签化能力完成流量染色和标签自动传递，仅通过控制台配置即可实现服务路由、全链路灰度及就近路由功能，快速满足客户的业务分流诉求。服务路由从行为上讲，是将流量进行染色区分，并通过路由规则将流量进行分流，本节将对TSF整体服务路由相关能力进行详细介绍。 作者简介 崔凯
胡弦，视频号2023年度优秀创作者，互联网大厂P8技术专家，Spring Cloud Alibaba微服务架构实战派(上下册)和RocketMQ消息中间件实战派(上下册)的作者，资深架构师，技术负责人，极客时间训练营讲师，四维口袋KVP最具价值技术专家，技术领域专家团成员，2021电子工业出版社年度优秀作者，获得2023电子工业出版技术成长领路人称号，2024年电子工业出版社博文视点20周年荣誉专家称号。
现在全链路越来越火，各大厂商也纷纷推出了自己的全链路压测测试方案。特别是针对全链路压测流量模型，各家方案都有所不同。最近我看了一些这方面的资料，有一些感悟。分享给大家。
作者廖红坤，CODING DevOps 产品策划。从事过多年运维开发，云计算、Kubernetes、云原生深度实践者，有丰富的 DevOps 平台设计经验。
KubeSphere®️ 是在目前主流容器调度平台 Kubernetes 之上构建的企业级分布式多租户容器管理平台，提供简单易用的操作界面以及向导式操作方式，在降低用户使用容器调度平台学习成本的同时，极大减轻开发、测试、运维的日常工作的复杂度，旨在解决 Kubernetes 本身存在的存储、网络、安全和易用性等痛点。
互联网产品需要快速迭代开发上线，又要保证质量，保证刚上线的系统，一旦出现问题可以很快控制影响面，就需要设计一套灰度发布系统。
现在，小程序云开发的云函数版本管理与灰度能力上线。更新至最新版微信开发者工具后，通过云函数版本管理，调整云函数多版本间的流量比例，即可实现云函数的灰度发布、A/B test等场景需求！
开发测试环境通常我们使用染色来区分不同流量，进入不同的开发测试联调分支组成的染色场。
作者 | 小杨互联网 来源 | https://www.toutiao.com/i6910008843955192323 灰度发布的定义 互联网产品需要快速迭代开发上线，又要保证质量，保证刚上线的系统，一旦出现问题可以很快控制影响面，就需要设计一套灰度发布系统。 灰度发布系统的作用，可以根据配置，将用户的流量导到新上线的系统上，来快速验证新的功能，而一旦出现问题，也可以马上的修复，简单的说，就是一套A/B Test系统。 灰度发布允许带着bug上线，只要bug不是致命的，当然这个bug是不知道的情况下，如
概述 软件开发过程中，应用发布非常频繁，通常情况下，开发或运维人员会将系统里所有服务同时上线，使得所有用户都使用上新版本。这样的操作时常会导致发布失败，或因发布前修改代码，线上出现 Bug。 假设一个在线商城，每天都有大量的用户访问，如果直接在所有用户中部署新版本应用，一旦出现问题，所有用户都可能受到影响。相比之下，通过引入灰度发布策略，先将新版本的应用部署到少量的用户中，检查是否存在问题，如果没有，再逐步扩展到更多的用户中，由此解决全量发布的各种弊端。 灰度发布是一种软件发布策略，它允许你在生产环境中渐进
导语 2022腾讯全球数字生态大会已圆满落幕，大会以“数实创新、产业共进”为主题，聚焦数实融合，探索以全真互联的数字技术助力实体经济高质量发展。大会设有29个产品技术主题专场、18个行业主题专场和6个生态主题专场，各业务负责人与客户、合作伙伴共同总结经验、凝结共识，推动数实融合新发展。 今年6月，腾讯宣布内部海量自研业务实现全面上云，成为国内最大规模的云原生实践，累计节省IT成本超过30亿元，充分显示腾讯云的产品、技术和综合服务能力。 云原生技术在云计算 PaaS 的应用已经迈入深水区，腾讯云微服务和中间件
Kubernetes 作为基础平台，提供了强大的容器编排能力。但是在其上部署业务和服务治理上，仍然会面对一些复杂性和局限性。在服务治理上，已经有许多成熟的 ServiceMesh 框架用于扩充其能力，如 Istio、Linkerd、Dapr 等。本文将主要介绍如何使用 Istio 扩充 Kubernetes 灰度发布的能力。
在 Kubernetes 中针对各种工作负载，提供了多种控制器，其中 Deployment 为官方推荐，被用于管理无状态应用的 API 对象。本文将结合 Deployment 的特性，与常见的发布策略，以及我们在分批发布场景下的实践，做一些分享。
笔者之前实习过程中负责过部门稳定性基建工作开展，其中一项任务就是负责流量染色SDK的实现和验证，具体来说，我负责的只是染色全流程中的一环，但是本文我想借助得物技术团队发表的流量染色实践系列文章，结合我自身实际开发经验，来聊聊我个人的一些拙见。
根据2018年的DevOps发展报告来看,目前的DevOps发展速度非常之快,已经逐渐成为企业运维的标准方案.DevOps的核心就是敏捷和高效,敏捷和Scrum开发技术曾被认为是最好的技术. 既然公司用到了CI/CD肯定就肯定避免不了持续部署,所以我们就需要考虑一套适合我们的发布方式,这个时候我们就需要了解一下这几个发布方式到底是什么意思,有很么好处,他们之间的差别在哪个地方.
作者：苏万亮，中国移动云能力中心软件研发工程师，专注于云原生、微服务、算力网络等领域。
随着公司业务的不断发展壮大，需要一套稳妥的发布方案，如果发布的新版本服务有问题能及时撤回，不至于造成太大范围的影响;
在项目迭代的过程中，不可避免需要”上线“。上线对应着部署，或者重新部署；部署对应着修改；修改则意味着风险。 目前有很多用于部署的技术，有的简单，有的复杂；有的得停机，有的不需要停机即可完成部署。本文笔者简单讨论一下目前比较流行的几种部署方案，或者说策略。如有不足之处请指出，如有谬误，请指正^_^。 Blue/Green Deployment（蓝绿部署） 蓝绿部署无需停机，并且风险较小。 (1) 部署版本1的应用（一开始的状态） 所有外部请求的流量都打到这个版本上。 (2) 部署版本2的应用 版本2的代码与版
导语 微服务产品团队为了广大开发者朋友们可以更好的使用腾讯云微服务产品，将持续为大家提供微服务上云快速入门的指引性文档，内容通俗易懂易上手，本篇为本系列的第一篇，欢迎大家收看。 微服务架构 下图是一个典型的微服务架构。从图中可以看到请求从前端进来之后，通常会有一个网关来承接所有的请求，这个网关通常承载的是负载均衡的作用，以及流量路由相关的一些功能。然后网关会把请求转发到后端的微服务中去，那么服务与服务之间互相调用，就会涉及到服务的注册与发现，需要有一个注册中心来管理所有的注册与发现，而服务所有的配置也需要
今天的文章继续聊聊有关Service Mesh微服务架构的话题，如果对之前的聊过的话题还不了解，可以参考文末的推荐阅读。今天要聊的话题是：如何在Service Mesh微服务架构中实现“金丝雀发布”？
之前有篇文章聊聊如何利用springcloud gateway实现简易版灰度路由,里面的主人公又有一个需求，他们有个服务是没经过网关的，而是直接通过nginx-ingress暴露出去，现在这个服务也想做灰度，他知道在同个集群如何利用nginx-ingress进行灰度发布，但是现在这个服务是部署在新的集群，他查了不少资料，都没查到他想要的答案，于是就和我交流了一下，看我这边有没有什么实现思路，今天就来聊下这个话题：不同K8S集群上的服务如何利用nginx-ingress进行灰度发布
灰度发布，对于大厂来说是必不可少的，对于我这种从来没有灰度发布过的，并不是很清楚，估计也有很多人不知道这个东西。以前只是直到灰度发布，这次稍微了解一下。
简介 突然心血来潮想写一下基于lua实现灰度转发的文章。 根据前文内容的openresty处理阶段这一环节，假如要实现灰度流量的转发，需要在balancer这个阶段进行处理。这个阶段类似于nginx的upstream作用域 upstream backend { server test.com test;} 原生的upstream其实是可以实现灰度流量转发的，但是主要策略是基于权重比例来流量的转发，无法实现颗粒度细的流量转发，为此，我使用lua代码实现了四种灰度流量转发策略： 基于权重比例转发； 基于IP
在日常开发中，老大经常要求我们给出一个完善并合理的技术方案之后才能进行开发。并且要求技术方案一定要细，要重点覆盖监控、异常处理、灰度、降级方案。同时要注重边界处理。最初，我的技术方案写的很粗，也没有理解老大说的边界处理到底是怎么一回事。于是乎，辛辛苦苦写了一周的方案，就会在技术方案评审的时候直接打回重做，甚至多次打回。 不过还好，在经历过几次大项目的方案设计后，我的方案设计越来越完善，直到最后老大非常认可并在组内进行参考。随着我的方案设计逐渐完善，也逐渐发现，不但编码效率越来越高，编码时思维更加清晰，而且方案中的每一个模块都贯穿了整个软件生命周期。
作者 ｜张怀龙、张海文 编辑｜邓艳琴 本文整理自中国移动云能力中心高级软件工程师、Istio 社区 Member 张海文和 Intel 云原生开发工程师、Istio 的维护者和 Linkerd 的开发者张怀龙老师在 QCon 全球软件开发大会（北京站）的演讲《移动云服务网格双栈技术的实践之路》。下载完整幻灯片地址如下：https://qcon.infoq.cn/202302/beijing/presentation/4898 背景介绍 众所周知，由于 IPv4 地址的消耗殆尽，且在未来 5G
在Istio中，灰度发布是通过指定不同版本的流量路由规则来实现的。这些规则描述了如何将传入的流量分配到不同的版本中，从而实现逐步推出新版本的目的。
灰度发布是一种发布方式，也叫金丝雀发布，起源是矿工在下井之前会先放一只金丝雀到井里，如果金丝雀不叫了，就代表瓦斯浓度高。原因是金丝雀对瓦斯气体很敏感。灰度发布的做法是：会在现存旧应用的基础上，启动一个新版应用，但是新版应用并不会直接让用户访问。而是先让测试同学去进行测试。如果没有问题，则可以将真正的用户流量慢慢导入到新版，在这中间，持续对新版本运行状态做观察，直到慢慢切换过去，这就是所谓的A/B测试。当然，你也可以招募一些灰度用户，给他们设置独有的灰度标示（Cookie，Header），来让他们可以访问到新版应用，当然，如果中间切换出现问题，也应该将流量迅速地切换到老应用上。
本篇已加入《.NET Core on K8S学习实践系列文章索引》，可以点击查看更多容器化技术相关系列文章。
灰度发布是指在黑与白之间，平滑过渡的一种发布方式。在大流量的系统中，如果一次升级改造范围比较大，或者影响内容不太确定，一般会采用切量的方式进行升级，这样可以减少生产变更带来的影响。
2023腾讯全球数字生态大会已于9月7-8日完美落幕，40+专场活动展示了腾讯最新的前沿技术、核心产品、解决方案。
停机部署其实是最简单粗暴的方式，就是简单地把现有版本的服务停机，然后部署新的版本。在一些时候，我们必须使用这样的方式来部署或升级多个服务。比如，新版本中的服务使用到了和老版本完全不兼容的数据表的设计。这个时候，我们对生产有两个变更，一个是数据库，另一个是服务，而且新老版本互不兼容，所以只能使用停机部署的方式。 这种方式的优势是，在部署过程中不会出现新老版本同时在线的情况，所有状态完全一致。停机部署主要是为了新版本的一致性问题。
小亚，互联网金融公司应用运维主管，参与运维工作九年，涉及领域包含航空、金融、广告等。近两年主要负责金融业务运维的线上业务发布、维护等工作。
在Zuul的工作原理中，我们已经看到Zuul主要采用基于Filter链的工作调用模式，通过自定义Filter机制可以动态扩展网关服务功能。网关的一个重要作用就是提供公共服务组件，而这些组件的功能也大都与Filter的拦截机制有关。下面我们以网关中经常会使用的灰度发布、服务限流为例，来说明如何通过Filter机制结合Ribbon和其他模块来实现。
你需要面对的挑战可能来自商业战略的变化带来的新的产品诉求，而产品的任何改动，哪怕只是界面调整，都将接受无数存量用户的“检阅”。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
