开发者学堂课程【微服务治理实践之金丝雀发布：微服务治理实践之金丝雀发布】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/972/detail/14893
下面看 Dubbo ，同样也需要创建一个provider 和 Consumer 。provider 创建如下
再创一个 dubbo 的 consumer 。
Dubbo 整按比例灰，按比例看起来更清晰一点，如灰度比例的90%，检测新老版本的比例是否为90%。因为两边一直在跑，所以监控会变化。进入 Dubbo 的 Consumer ，看有没有成功，对外报录为 Sayhello 的方法，如叫 test 。端口为17080是145和86，因为有两个 pod 。
写一个脚本
可以看到86和145之间有对应的负载的策略。
此时对 dubbo 的 provider 做一个按比例的金丝雀发布。
同样进行部署
选择金丝雀发布
对应2.0
然后按照比例，如90%的比例，90%的流量会路由到灰度的节点。
灰度规则还未生效，还在部署，所以还是145和86，基本上是55开的比例。
触发了对应的下线逻辑，所以只会路由到正常的 IP 上。
等金丝雀部署过程中新创建的三年之后会恢复正常。从比例上看9:1比较明显。
88基本是灰度节点，比例较高，145是正常的节点。可以看一下88是否是对应的灰度的一个破的 IP 。第一个灰度的 IP 就是88。
因为是按90%的比例去灰度的，可以看一下对应的监控，后面会出来1:9的比例。同样会显示 dubbo 对应的接口，因为报录的是 helloservice ，调的是 sayhello 方法。
同样可以看代码，其实调用的是helloservice的 sayhello 的方法。
Public interface IHelloService {
调用的是 sayhello 对应的 name 。
@RequestMapping9“/sayHello/name)”
其实调用的是helloservice的 sayhello 的方法。
可能现在请求还不是很多，所以监控还不是特别准确，可以看到这个点，新版本与老版本灰度的比例是 90% 。
因为数据量不算特别大，所以监控稍有不准，数据量大了之后，监控会比较准。
如果灰度发布没问题了，可以点击下一批。
同样还是90%的灰度
点了下一步之后，又触发了无损象限。后面负载会正常。
点了下一步，在做部署。执行成功变成了88和146。回到了原来的负载策略，变为正常两个 pod ，基本为五五开的比例。
简单看代码，是基于是dubbo 2.7.3、2.7.2的。没有加任何对应的依赖，完全是通过 Agent 技术去帮助 double 达到灰度路由的结果。
现在根据监控，基本回到了五五开的比例。
五.金丝雀部署原理
首先用户在控制台上配对应的一些规则，规则会下发到配置中心里，如配了一个 a＝1 ，Consumer 去调 provider ，如果满足 a＝1 ，会路由到灰度的节点里。如果等于2，不满足条件，会路由到非灰度即正常的实例上。
对于怎么判断这些实例哪些是灰度哪些不是灰度，是通过启动参数去添加的，当 Deployment 里面有一个 Java 的启动参数，会把这些 pod 注册到注册中心上，注册时会设置一些特殊的属性到注册中心里，表示这些 pod 是灰度 pod ，若没有设置说明是一个正常的 pod 。每次路由会拿到配置中心里的配置，解析这些配置去判断是否要路由到灰度的节点上，这大致就是金丝雀部署的原理。因为这种这种方式无论是在 K8S 或是在 ecs 下面都没有问题，因为没有对应的 IP 绑定，最重要的一个点是每次注射以后，会表示这个节点是不是灰度节点。
六.金丝雀下一步规划
1.支持更多打标方式
如配置里如果满足某些配置等于什么，则表示这是一个灰度的节点。目前支持启动参数、环境变量。
2.支持更多的灰度规则，更友好的使用方式。
Dubbo 里现在只支持参数的对比，后续如会做 Attachment 对比，path对比。通过Agent 技术去上报 controller 对外暴露了哪些 path ，对这些 path 进行展示，可以选，不填，因为填易出错。
3.支持更多的组件
Spring cloud 把客户端这一层做的像网关Spring cloud gateway 、Netflix Zuul ，目前还没有做这个支持，后续会把金丝雀这个功能完善的更好。
七. EDAS 演示金丝雀资料
1.帮助文档 https://help.aliyun.com/document detail/150109.html
EDAS 上有金丝雀部署的一个文档
2.金丝雀发布 https://martinfowler.com/bliki/CanarvRelease.html
金丝雀部署的原理，什么是金丝雀部署
3.EDAS 产品https://cn.aliyun.com/product/edas
EDAS 整个产品的首页
4.Dubbo 路由规则 http://dubbo.apache.org/zh-cn/docs/user/demos/routing-rule.html
Dubbo 开源的路由规则，是如何实现的
5.Spring Cloud LoadBalancer https://spring.io/guides/gs/spring-cloud-loadbalancer/
Spring cloud 两个负载均衡组件
6. Netflix Ribbon https://github.com/Netflix/ribbon
八.无损下线
最后一个 EDAS 提供了一个无损下线的功能。即一个 provider 有四个实例，但下线一半，在下线的过程中，要确保不会调用到另外两个下线的实例，如果调了会掉失败，因为已经下线了，这就是无损下线。
开源的无损下线 Spring cloud 有一个办法是需要调一个 Endpoint ，要打开 Actuator ，但是调endpoint 也有一个问题，因为注册中心怎么下线这个实例是对应的注册中心决定，但注册中心有没有真的下线是不知道的，如里面有一些缓存导致虽然下线，但是没有下线成功。Dubbo 同样，QOS也是根据注册中心去做对应的相应操作。还有一点是这两个操作都是需要手动做一些改动的。EDAS对无损下线做了如下增强：
1.所有的流程是完全自动化
2.增强了下线逻辑，不会依赖注册中心。因为刚才提到注册中心的下线并不一定是真的下线，里面可能有一些缓存，导致后续请求有可能会得到已经下线了的 IP ，下线并不完美，因为依赖注册中心。
3.同样是基于 Agent 技术去做，覆盖了Dubbo 2.5 及 Spring cloud D 以上的版本，只要是这个版本之内一行代码都不用改，就可以体验无损下线的功能。
4.在 K8S 或 ECS 场景下都是覆盖到的。
5.不需要 Actuator ，因为开源实现 spring cloud 是需要 Actuator 的，需要加对应的依赖，还要做一些安全性的配置，因为Actuator 不是每个人都可以访问的，可以做一些安全措施。
6.Netflix Ribbon 里面有一个客户端刷新时间，默认是30秒。如果服务上线、下线是。
实时的，但是客户端的刷新时间还是30秒，则只能等30秒。当然也可以配置，EDAS 会增强刷新时间，会增强这个特性，如果有实例上限或实例下限，客户端一定会感知，跟刷新时间没有太大的关系。
简单演示一下，无损下限就本地演示。同样是一个 Consumer 调 provide 的一个例子，是刚才在 EDAS 上跑的例子。脚本写好了，因为目前只有一个实力，再起一个。
如果此时一台实例下线，出现报错，这就是有损下线，下线的过程中客户端拿到了已经下线的实例，导致连接被拒绝，所以并不是一个无损的下线过程，下线过程中造成了一定的资损，就是有损下限。
EDAS 上把这个功能强化了，可以简单看一下。EDAS 现在有一个 provider 和 Consumer 。
先看一下 Consumer ，此时访问的是80和8 1。
provider 也是80和81，此时若做一个缩容，两个pod变成一个，则只会变成80，自动把81屏蔽掉。这就是 EDAS 无损下线的功能。
