自己建站的网站,wordpress数据库文件导入,怎么免费制作企业网站,在线做ppt简介#xff1a; 本文介绍了微服务治理下金丝雀发布的能力#xff0c;解决了发布期间少量流量验证新功能的问题。
前言
本文#xff0c;我们继续聊聊《揭秘大流量场景下发布如丝般顺滑背后的原因》中的另外一环#xff0c;灰度发布#xff0c;也叫金丝雀发布。 很多互…简介 本文介绍了微服务治理下金丝雀发布的能力解决了发布期间少量流量验证新功能的问题。
前言
本文我们继续聊聊《揭秘大流量场景下发布如丝般顺滑背后的原因》中的另外一环灰度发布也叫金丝雀发布。 很多互联网公司在半夜发布的另外一个重要原因是不具备可灰度能力新版本存在 bug 或者其它原因会影响线上的客户无奈之下只能选择在半夜进行发布来减少影响面。
我们知道默认情况下无论是 Kubernetes 还是 ECS新老版本都存在的情况下会根据特定的负载均衡算法随机地路由到不同的实例上随机意味着出问题也会随机出现。我们需要一套动态路由来完成灰度发布的解决方案。
在 RPC 领域我们称灰度发布为动态路由动态路由的意思是指流量可以动态地路由到指定的实例上。
动态路由场景
动态路由是微服务里非常核心的功能流量动态路由意味着可以做非常多的事情。由此衍生出各个场景:
金丝雀发布只有满足特定规则(比如 Query Parameter、HEADER、COOKIE 中某些 KEY 满足一些条件)或者是固定流量比例的流量才会进入新版本其它流量都路由到老版本上。同机房优先路由当公司规模扩大之后应用会跨机房部署来达到高可用的目的。由于异地跨机房调用出现的网络延迟问题需要确保服务消费方能优先调用相同机房的服务消费方这就需要同机房优先路由的能力。标签路由金丝雀发布的新场景。金丝雀发布一般只有新和老两个版本标签路由可以在线上部署多个版本每个版本都对于一个标签。 全链路灰度在业务比较复杂服务调用链路较长的场景下每个应用都需要设置路由规则会显得非常繁琐全链路灰度在金丝雀/标签路由的基础上加上了 标签透传 的能力让灰度流量只在灰度版本之间路由。 接下来我会分几篇文章详细讲一下这几个场景今天我们先来聊聊金丝雀发布。金丝雀发布可以让我们在白天流量高峰喝着茶吃着瓜子进行线上发布不需要在半夜为发布的事情而苦恼。
大流量下的应用部署现状
应用 Demo
Demo 以 Spring Cloud 为例服务调用链路如下图所示 流量从 Netflix Zuul 对应的 Ingress 进来会调用 SC-A 应用对应的服务SC-A 应用内部调用 SC-B 应用的服务SC-B 应用内部调用 SC-C 应用的服务。SC-A 有线上版本和灰度版本这两个版本。
Helm 部署 Demo
Demo 为纯开源 Spring Cloud 架构项目地址https://github.com/aliyun/alibabacloud-microservice-demo/tree/master/microservice-doc-demo/traffic-management。
部署完毕后阿里云容器服务上的工作负载情况如下 我们通过 while true; do curl http://{ip:port}/A/a;echo;done shell 命令不断地去访问 Spring Cloud 服务各个服务的作用仅仅是打印当前服务的IP这样我们可以看到整体调用链路:
while true; do curl http://{ip:port}/A/a;echo;done
A[10.0.0.73] - B[10.0.0.180] - C[10.0.0.72]
A1[10.0.0.20] - B[10.0.0.180] - C[10.0.0.72]
A1[10.0.0.20] - B[10.0.0.180] - C[10.0.0.72]
A[10.0.0.73] - B[10.0.0.180] - C[10.0.0.72]
A[10.0.0.73] - B[10.0.0.180] - C[10.0.0.72]
A1[10.0.0.20] - B[10.0.0.180] - C[10.0.0.72]
A[10.0.0.73] - B[10.0.0.180] - C[10.0.0.72]
A1[10.0.0.20] - B[10.0.0.180] - C[10.0.0.72]
A[10.0.0.73] - B[10.0.0.180] - C[10.0.0.72]
...
从这个过程我们明显可以看出 Netflix Zuul - SC-A 这条链路是随机访问的由于 SC-A 的线上版本和灰度版本各只有 1 个 Pod所以随机打印了这两个 POD 的 IP。
开源金丝雀的实现
动态路由的本质就是寻址过程中去找符合条件的实例地址。
Apache Dubbo 提供了 RouterChain 的能力去过滤 Invoker 列表RouterChain 内部维护着 Router 列表每个 Router 都会做过滤 Invoker 的逻辑最后将 Invoker 列表交付给 LoadBalance 做负载均衡获取最后的 Invoker。
ScriptRouterConditionRouter 和 TagRouter 这些内置的 Router 内部都是 Dubbo 自带的动态路由能力。
Spring Cloud 的路由能力由 Ribbon 实现。Ribbon 设计了 ILoadBalancer 接口用于获取 Server 列表最后将这个列表交付给 IRule 做负载均衡策略获取最后的 Server。这块在设计上跟 Dubbo 相比是有缺陷的。
Spring Cloud Ribbon 里的 ILoadBalancer 相当于是 Dubbo RouterChain 里的一个 RouterIRule 相当于是 Dubbo LoadBalance。
最新版本的 Spring Cloud 新增了 Spring Cloud LoadBalancer 组件代替 Ribbon 用于做负载均衡Spring Cloud LoadBalancer 里的 ServiceInstanceListSupplier 用于获取实例列表信息ReactiveLoadBalancer 使用负载均衡策略获取最后的实例。
这是 3 者对应组件的说明: Apache Dubbo 虽然内置了各种 Router但实际使用下来却有非常多的问题。比如 TagRouter 跟 IP 绑定在 Kubernetes 下无法工作ScriptRouter 用了 ScriptEngine 去做脚本的处理会有性能问题Dubbo Admin 的使用体验非常糟糕等等。
Spring Cloud 官方并没有提供动态路由的能力只有社区上的一些开发者自己去扩展了这个能力社区上也没有任何的 UI 交互界面。
这时候 MSE 告诉你MSE 的微服务解决方案提供了动态路由的能力不需要做任何的代码和配置的修改就能使用 OPEN API 或者 UI 交互去完成金丝雀发布。只需将您的应用接入 MSE 服务治理您就能享受到金丝雀能力。
只要你的应用是基于 Spring Cloud 或 Dubbo 最近五年内的版本开发就能直接使用完整的 MSE 微服务治理能力不需要修改任何代码和配置。
无需任何代码修改就可以做到动态路由的能力这不香吗
MSE 金丝雀能力
应用接入 MSE 即可享受 MSE 提供的动态路由能力无需任何代码修改。
引入标签概念
MSE 引入了标签的概念可以针对每个标签设置路由规则满足该路由规则的流量会路由到这个标签对应的实例下。我们将 Spring Cloud Demo 进行一点改造给 SC-A 的灰度版本打上 blue 标签( Helm 已经完成了这个步骤)。 接入 MSE 后MSE 默认会给应用分配一个 100% 路由到未打标实例的路由规则。此时我们继续通过 while true; do curl http://{ip:port}/A/a;echo;done shell 命令去执行这个时候调用 SC-A 全部返回线上版本的 IP:
while true; do curl http://{ip:port}/A/a;echo;done
A[10.0.0.73] - B[10.0.0.180] - C[10.0.0.72]
A[10.0.0.73] - B[10.0.0.180] - C[10.0.0.72]
A[10.0.0.73] - B[10.0.0.180] - C[10.0.0.72]
A[10.0.0.73] - B[10.0.0.180] - C[10.0.0.72]
A[10.0.0.73] - B[10.0.0.180] - C[10.0.0.72]
...
设置金丝雀路由规则
我们在 MSE 上的应用详情页里的金丝雀 Tab 页里设置 HEADER 里 env 这个 KEY 的值为 test 的金丝雀路由条件: 传入 HEADER 继续使用 shell 执行:
while true; do curl -H env:test http://139.196.200.40/A/a;echo;done
A1[10.0.0.20] - B[10.0.0.180] - C[10.0.0.72]
A1[10.0.0.20] - B[10.0.0.180] - C[10.0.0.72]
A1[10.0.0.20] - B[10.0.0.180] - C[10.0.0.72]
A1[10.0.0.20] - B[10.0.0.180] - C[10.0.0.72]
A1[10.0.0.20] - B[10.0.0.180] - C[10.0.0.72]
A1[10.0.0.20] - B[10.0.0.180] - C[10.0.0.72]
A1[10.0.0.20] - B[10.0.0.180] - C[10.0.0.72]
A1[10.0.0.20] - B[10.0.0.180] - C[10.0.0.72]
A1[10.0.0.20] - B[10.0.0.180] - C[10.0.0.72]
...
这个时候我们发现满足金丝雀规则的流量都去了 SC-A 的灰度版本。
金丝雀路由规则解析
大家看到金丝雀路由规则界面上有两种分别分别是流量比例和流量规则: 流量规则表示满足该规则的流量会路由到对应标签(本文使用 blue 作为灰度标签)实例上。比如本文例子中 HEADER 里 envtest 的流量一定会去 blue 标签对应的实例。
流量比例不满足任何流量规则的流量会按照流量百分比进行路由。比如本文例子中不满足 HEADER 里 envtest 的流量会以 100% 的规则路由到未打标的实例上由于是 100%所以那些不满足规则的流量全部都去了未打标实例上(本文未打标表示线上版本)。
MSE 提供的流量规则里的条件支持 HEADER、Query Parameter、COOKIE 以及 Request BODY。
Query Parameter、HEADER、COOKIE 和 Request Body 除了支持常规的运算符外还支持 in(白名单)对 100 取模和百分比。这里的百分比并不是比例规则中的总流量百分比而是指对应参数的 hash 值取模这样就可以让固定的值永远满足路由条件(如果按照流量比例用户 A 这次访问的是线上版本下次可能会访问灰度版本)。举个例子如果 HEADER 中带有用户 ID我让想部分用户永远能够访问灰度实例这个时候可以对用户 ID 的 hash 值取模去完成(当然这个也可以通过白名单去操作白名单的缺点并不随机需要输入各个名单)。
Request Body 目前支持解析 json 字符串比如如下字符串:
{ a: aa,b: [1,2,3],c: [{d: dd}],e: {f: ff}
}
JSON 访问表达式 .a 的值为 aa。 JSON 访问表达式 .b[0] 的值为 1。 JSON 访问表达式 .c[0].d 的值为 dd。 JSON 访问表达式 .e.f 的值为 ff。
总结
本文介绍了微服务治理下金丝雀发布的能力解决了发布期间少量流量验证新功能的问题。您的应用只需接入 MSE 服务治理无需任何操作即可享受到动态路由的能力。除了 MSE微服务引擎金丝雀发布还被 EDAS、SAE 等云产品集成。
原文链接
本文为阿里云原创内容未经允许不得转载。
