开发者学堂课程【微服务治理实践之金丝雀发布：微服务治理实践之金丝雀发布】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/972/detail/14893
微服务治理实践之金丝雀发布
内容介绍：
一． 微服务治理
二． 安全生产三板斧
三． 可灰度
四． 微服务动态路由
五． 金丝雀部署原理
六． 金丝雀下一步规划
七． EDAS 演示金丝雀资料
八． 无损下线
一.微服务治理
微服治理最近上线了些新功能，如 Spring Cloud ，可以 Spring Cloud 的服务的查询，调用链，离群摘除，还会上线服务健全，也会分享 Spring Cloud 无损下线以及金丝雀发布。
Dubbo 类似，如会介入 Dubbo Admin 。
HSF 会继续做支持。阿里云上有微服务治理各个的功能点，如金丝雀发布。进入后分 ecs 集群和 k8s 集群，根据自己的集群选择对应的集群，因为每种集群的部署策略是不一样的。
具体功能如下：
1.Spring Cloud
（1）查询 Spring Cloud 服务
（2）查询 Spring Cloud 服务调用链
（3）使用离群实例摘除保障Spring Cloud 应用的可用性
（4）使用服务鉴权实现Spring Cloud 应用的访问控制
（5）无损下线 Spring Cloud应用
（6）金丝雀发布 Spring Cloud 应用
2. Dubbo
（1）查询 Dubbo 服务
（2）查询 Dubbo 服务调用链
（3）使用离群实例摘除保障Dubbo 应用的可用性
（4）使用服务鉴权实现Dubbo 应用的访问控制
（5）无损下线 Dubbo 应用
（6）金丝雀发布 Dubbo 应用
（7）使用 Dubbo Admin 治理 Dubbo 服务
3. HSF
（1）查询 HSF 服务
（2）查询 HSF 服务调用链
（3）使用离群实例摘除保障 HSF 应用的可用性
（4）无损上线 HSF 服务
（5）查看 HSF 服务报表
二.安全生产三板斧
1.可灰度
阿里内部有全生产三板斧的概念。第一个是可灰度，如下图，有两个版本，一个Old version 一个 New version ，New version 新版本可以灰度一批用户，如可以灰度5%的用户，先观察这个新版本上线是否有问题，即可灰度。
2.可观测
第二个是可观测，类似监控，新版本上线，需做监控，确定新版本是否有问题，如系统的负载，CPU使用率，内存使用率等就是可观测，发布前后可以做对比。
3.可回滚
可回滚很重要，当新版本发布后，如果出问题，第一件事是回滚这个新版本，因为排查问题需的时间是无法预估的，此时就需要将新版本新回滚到老版本，回滚确定为什么发生故障，继续进行排查，等待下一个时间点继续发布。以上为阿里集团安全生产三板斧的概念。
三.可灰度
灰度分很多种类型。
1. 蓝绿发布
蓝绿发布较简单，一套系统会在两个环节上做部署。用户开始访问的是老环境，当新环境准备好后，在统一入口将流量切到新版本。这种发布的问题如下：
（1）简单
只需多部署一套系统就可以，两套系统一起跑，非常简单。
（2）资源成本高
因为多部署了一套系统，底层的资源进行了一定的浪费，成本较高，多花一倍的资金去运行。
（3）切换快（回滚|升级）
当新版本出现问题或要升级时，过程非常快，在统一路口前做一个流量切换即可，所以切换的速度包括升级回滚非常快。
（4）影响广
如果发生了问题会影响所有用户，因为这个缺点是针对新老系统的切，全切到新的或全部是老的，影响范围非常广。
给大家演示什么是蓝绿部署。配了一个host，是本地的一个域名，认识到本地，后台配了一个NGX。如最开始，同一个域名，它是2.0版本。
package com.alibaba.cloud;
import…
@SpringBootApplication
public class BlueGreenDeploymentApplication {
public static void main(String[ ] args){SpringApplication.run(BlueGreenDeployment
@RestController
class MyController {
@GetMapping("/status")
public String status() { return "version3.@"; }
}
}
然后如在8080上面即另外一套资源，又部署了一套，如改到3.0，此时因为切流的动作还没做，所以还是2.0这个版本。
package com.alibaba.cloud;
import…
@SpringBootApplication
public class BlueGreenDeploymentApplication {
public static void main(String[ ] args){SpringApplication.run(BlueGreenDeployment
@RestController
class MyController {
@GetMapping("/status")
public String status() { return "version3.@"; }
}
}
然后改一下统一进入层的NGX。把端口改成9090。重启一下这个NGX。此时访问同样的域名，同样的入口，它的版本就升级为了3.0，这个就是蓝绿发布的概念，优缺点也做了简单的总结。
upstream my-upstream {
server 127.0.0.1:9090;
keepalive 64;
}
server {
listen 80;
server_name spring-cloud-alibaba.io;
location / {
proxy_pass http://my-upstream;
}
}
2. 金丝雀发布
第二种灰度发布策略是金丝雀发布。
（1） 灵活，规则多样化
金丝雀比较灵活，不单按照图上5%的用户访问的是新版本，95%的用户访问的是老版本。也可以做每次请求的参数，整个路由的规则是非常灵活的，具有多样化，不单可以按比例也可以按内容参数做一些灰度。
（2）搭建成本高
金丝雀分布搭建成本比较高，蓝绿分布只要简单的搭两条系统，统一记录做切流就可以。金丝雀搭建成本总体来较高的，如NGX 要做一些参数的解析或微服务里要对double 等做路由规则的解析。
（3）没有覆盖所以用户
金丝雀没有覆盖到所有用户，因为如按比例到了5%的用户，但是这5%的用户不一定会触发一些 bug ，可能90%的客户覆盖之后才会出一些 bug ，所以有一些缺点。
（4）影响范围小
虽然有缺点，没有覆盖到所有的用户，但如新的版本出现了问题，只会影响这5%的用户。
3. 滚动发布
滚动发布是金丝雀发布的一个变形，如图有九台实例，第一个步骤先在三台实例上做部署，后面每三台每三台的部署直到全部部署完，即部署三次，是一个按比例的灰度，按照1/3的比例去灰度。因此滚动发布其实是金丝雀发布的变奏。
滚动发布的一个缺点是发布/回滚周期长，如每次发三台，然后隔一两天或一个小时再后面的三台，但发布时间长每次回滚时间也会比较长，每次回滚三台。
以上就是三种灰度策略，蓝绿发布、金丝雀发布和滚动发布。
四. 微服务动态路由
对于微服务，如 Spring Cloud 底层是 rest 协议，所以其实是 hddp ，如一个 consumer 调 provider 的，根据parameter ，若 name ＝ jim ，会路由到192.168.1.1的这个 provider 上，如果header 中有 test ，会路由到192.168.1.2 的provider 上，包括 cookie ， Dubbo 也同样，可以根据 Attachment 里面有什么路由到对应的实例上，如果方法的参数 Arguments ，如第几个参数它的值等于什么会路由到对应的实例上，又或者 Dubbo 中某个接口中的某个方法,可以对其做灰度，也会精准的路由到对应的节点上。这是微服务的相关的动态路由，开软的微服务动态路由问题还是较大的。
1.Dubbo 动态路由
Dubbo 动态路由，下面是 Dubbo Admin ，是条件路由，可以配 jason ，如 house 不等于 IP 。
下面是 Dubbo 中，可以对 return 做扩展，如判断第零个参数是1，会返回 IP 。
public class CanacyRouter extends AbstractRouter {
private List<string> grayIps = new ArrayListe< >( )；
public CanaryRouter( ) {
grayIps.add("192.168.0.1");
grayIps.add(“192.168.0.2");
}
@Override
public <T>List<Invoker<T>> route(List<Invoker<T>> invokers,URL url
Invacation invacation)throws RpcException{
if ("1"".equals(invocation.getArguments(()[0].toString())){
return invokers.stream(()
.filter(invoker => grayIps.contains(invoker.getUrl().getHost())
collect(Collectors.toList())；
}
return invokers;
}
}
Dubbo 动态路由缺点如下
（1）Dubbo 不版本路由功能不一致
不同版本，它的路由功能是不一样，如2.7加了很多的新的特性，包括路由规则，这些特性在2.5 ，2.6是不支持的，所以不同的版本，路由功能是不一样的。
（2）Dubbo Admin 操作不友好
创建一个新的路由规则，体验不是特别好，理解成本也较高。
（3）固定IP，不够云原生
IP 是固定的，如 router ，写死了192.168.0.1和0.2，IP是固定的，不会云原生，在K8S环境下重启后IP会变，所以这个规则会失效。所以不够云原生。
（4）对技术人员要求较高
如 router ，对 Dubbo 要较熟悉，若不熟悉的 router 不会写。所以对技术人员要求非常高。
2.Spring Cloud 动态路由
public class SanacyRule extends AbstractLoadBalancerRule {
private List<String> grayIps=new ArrayList<>)
private Random random=new Random();
@Override
public void initwithNiwsConfig(IClientConfig clientConfig){
grayIps.add(“192.168.0.1");
grayIps.add(“192.168.0.2");
}
@Override
public Server choose(Object key){
List<Server> allServer=getLoadBalancer().getAllServers(): List<Server>grayServers=allServerstream()
.filter(server ->grayIps.contains(servergetHost()))
.collect(Collectors.toList());
grayServers.get(random.nextInt(grayServers.size()));
return null;
}
}
Spring Cloud 没有 Spring Cloud Admin的，因此 Spring Cloud 没有对应的 ops ，因此写代码，Spring Cloud 新出了一个客户端返回的组件，新出的组件也要做一些对应的规则的适配， server做一些过滤，判断是否为对应的 IP ，如果是返回 IP ，是灰度的一些实例，在灰度的实例里再根据一个算法去获取，代码稍有点问题。
Spring Cloud 动态路由有一下问题：
（1）Netflix Ribbon & SCL 两套客户端路由组件。
首先，它有两套路由组件，要实现两套，因为 Spring Cloud load balance 刚出来，未普及，所以要做两套规则的适配。
（2）没有 ops 界面。
Dubbo 有一个 Dubbo Admin ，Spring Cloud 没有 ops 界面，所以只能写代码。
（3）Netflix & SCL 规则类获取不到请求信息。
Rule 里面没有 request 信息，只能做一些路由。request 信息在 Spring Cloud 客户端链，所以参数的解析需要通过第三方做规则的透传，因此对技术人员的要求较高，即第4点。
（4）对技术人员的要求较高。
（5）破坏原有的负载均衡规则。
用了 rule 之后它会覆盖用户一开始给的rule ，因此会破坏代码程序上原有的负载规则。
（6）固定 IP ，不够云原生。
同样也是固定 IP 的，不够云原生。
（7）不同客户端获取参数方式不一样。
获取参数的代码是不一样的，因为是两套客户端的实现。
