开发者学堂课程【微服务治理实践之金丝雀发布：微服务治理实践之金丝雀发布】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/972/detail/14893
3.EDAS 金丝雀部署
针对上述问题， 总结了该部署的优点如下：
（1）简单易用的应用部署流程。
有一个非常简单的应用部署的流程。
（2）控制台修改规则灰度动态生效。
在控制台上面直接配一些规则，如head中有什么，或可以配一个比例。
（3）完善的监控体系。
有非常完善的监控的体系，可以看发布前后，如 qbs 是多少，kbs 比例是多少，凑了比例是多少，是开元层面完全没有的。
（4）ECS & K8S 场景全部覆盖。
无论是在 ecs 还是 K8S 场景下都是覆盖的，因为如基于固定IP的，其实在 K8S 这个产品是不能服用的。
（5）基于 Agent 技术无需修改代码。覆盖dubbo 2.5.0 ，spring cloud D 以上。
第五点是基于 Agent 的技术做的，契约型的技术类如 dubbo 不同的版本，可能规则不一样，同样Spring cloud ，如果是通过 Agent 技术去做，则不用关心因为 Agent 把所有事情都解决，不需要修改一行的代码。
（6）使用有问题？功能不够？微服务团队帮你解决。
如果认为 EDAS 金丝雀部署功能不够强，微服务团队会帮解决这些问题。
下面演示一下 EDAS 金丝雀部署，应用列表里可以新建一个应用。如可以基于Kubernetes 集群创建一个 JAVA 应用。应用名叫 canary-provider ，需要上传对应的加包，已经准备好了，是一个 Spring cloud G版本的 provider ，版本先选1.0，pod 先选两个，金丝雀灰度一半。
可以简单的看一下应用部署的详情，如可以看有多少监控信息，总需求量，平均响应时间包括错误数，full GC 的次数，微服务中对应的服务，具体的监控信息，这一套监控信息提供的是非常详细的。
把 Canary-consumer 也创建
此时因为选了两个 pod ，会自动帮我们分配两个 pod ，有对应的 IP 。
provider 有一个服务查询的界面，可以看 provider 部署了哪个服务。如 Spring cloud ，刚才部署了一个canary-provider ，里面有个服务叫 canary-service-provider ，对应的是两个IP，可以通过服务查询去看在各个框架上分别部署了哪些服务。
Consumer 创建好了，可以进入pod ，可以简单的尝试部署有没有成功，端口是18091 user rest 。调成功后返回 IP 为144和83，因为内部会有默认的负载策略。
144和83的 provider 就是144和83。
此时如果要做金丝雀部署，应用界面里的部署
点进去之后有多种部署方式，如分批部署就是一开始介绍过的，即每次部署一批直到部署所有人，分批部署也是支持的。另外一个是金丝雀发布。
用金丝雀发布演示一下，用2.0版本，出于简便包不改变，因为里面返回的是 IP 。
看代码，如 consumer 刚才调的，调了user rest ，会传一个 name 参数，会调provider ，把 name 参数传进去。
@Autowired
private Provider1 providerl;
@Autowired
private DiscoveryClient discoveryClient;
@RequestMapping(value = "/user/rest", method = RequestMethod.GET)
public String rest(HttpServletRequest request) {
String name = request .getParameter(s:”name”);
if(stringutiis，isEmpty(name) ) {
name ="gg";
}
String str1 = restTemplate . getForObject ( url:"http://canary-service-prow
String.class);
return str1;
}
@RequestMapping(value = “/service", method = RequestMethod.GET)
"ovider1;
ient discoveryclient;
je = "/user/rest", method =RequestMethod.GET) ittpServletRequest request ) {
equest.getParameter( s:“name");
isEmpty(name)) {
estTemplate.getForObject( url:"http://canary-service-provider/usename=" + name.
如传一个 name ，叫 test 。
每次返回 IP 是对应 provider 上的两个pod ，是正常现象，因为现在还没做部署。
此时做一次金丝雀部署，因是一个parameter ，名字是 name ，等于 test 之后就是一个灰度，即满足了这个条件之后会路由到灰度的节点。
此时做一个部署，继续调因为还在部署，完全下线，所以仍一直返回这两个 IP 。
直到只返回了83，说明金丝雀生效了。
如果再改一下对应的参数，因为设置的为 name 等于 test 时会路由到灰度的节点，那如果为 testi 。
85是第一次部署灰度
因为85还没上线，所以 Agent 会有无损参与的保护措施。所以第一次部署的是85，一个灰度节点。到灰度结点以后 test 是满足的，所以一直返回的是85。
可以看对应的监控，因为永远返回的是85，所以新老版本的对比是100:0。
运行一段时间后看对比会不会变化。现在永远都是新版本。
再开一个窗口去调老版本，叫 test1 ，会调不是85的那一台，会调到83。
一个是永远返回非灰度的实例，一个是永远返回灰度的一个实力。一个是85，一个是83。微后看一监控会不会变化。因为监控有延迟，里面可以比较新老版本的错误数、RT等，会精确到对应的接口。因为代码中访问的是 user ，所以会自动解析出 pass 请求的数据。由图新老版本一个是62，一个37。
因为一开始是较早跑的，所以数据会稍大一点，若跑久了，大概是5:5的概率。
