API网关灰度发布
能力目标
理解APP灰度发布策略
理解Gateway负载均衡源码执行流程
掌握Api网关权重分流策略
能扩展SpringCloud Gateway源码编写灰度发布流程控制
能基于SpringCloud Gateway+Nacos元数据实现多种灰度发布策略
提娶码：o4na
小知识点：Nacos也 V:（cmL46679910）
支持配置灰度发布，操作简单，如下图：
1 APP如何灰度发布
我们前面讲解了配置文件灰度发布、IP切流、静态页灰度发布，但如果是APP该如何灰度发布呢？APP的灰度发布比较简单，也比较传统，不像我们其他程序能完全自动化操作。
1.1 APP灰度发布流程
上面这张图是国内某家知名公司的灰度发布流程图，主要针对Android和IOS 应用，但应用都是客户端，我们可以把它想象成页面，不过和页面不同的是大多数APP都需要用户主动下载升级，运营人员要做的事情是找到他们，让他们更新产品，后端灰度发布还和以前一样。相对来说Android投放门槛低，但IOS投放门槛高。
1.2 APP灰度发布策略
选取平台：一般选取Android作为灰度平台，ios要做灰度很难绕开appstore的发版规则，由于appstore不支持灰度功能，所以手段要么是选取越狱设备，要么是testflight作为灰度包的安装渠道，但是明显实现成本都很高，覆盖的用户群很瘦限制。比例一般可根据产品用户数量来决定，10%、20%、30%甚至50%，视产品具体阶段而定。抽取规则可以通过用户id、手机号、设备id的尾号来抽取。还有一种方式是选取某一渠道投放灰度包，但是这样有几个缺点：1.渠道的大小决定了覆盖用户量，但是这个很难做到精细比例的控制。2.容易被其他渠道抓包，导致比例不可控，同时干扰正式版的正常发布。
数据打点：决定灰度包要不要推广到市场，最直观快捷的方案是观测数据。所以针对灰度包的打点要保证全面，同时要能够与正式版本区分开。用来对比数据
版本控制：由于灰度版本是针对部分用户的beta版本，功能难免会不稳定，所以最好不要占用正常的版本号，而是单独细分颗粒度更细的版本号用在灰度版本上。
回收能力：灰度包要具有能把发布出去的版本全部回收、即清洗为正式版本的能力。这样做是为了保证一旦灰度包出现重要bug，不会有部分用户的版本停留在有bug的版本导致后续整体的数据表现受到这部分bug的影响。一般手段为强制用户升级
2 Gateway源码分析
Gateway在执行路由前会先选择指定的服务，指定的服务选择涉及负载均衡算法，我们先对源码进行剖析一次，然后再模仿源码编写一个过滤器，让过滤器最后执行。
2.1 Gateway负载均衡
我们这里只探究SpringCloud Gateway涉及负载均衡中的源码部分，如上图：
1:请求会执行一个过滤器ReactiveLoadBalancerClientFilter，获取一个真实调用的服务实例信息。
2:filter()方法执行过程：
1):获取url
2):调用choose()方法获取要调用的真实实例，服务的IP、端口号、服务名字
3):在url构建出的基础上构建出访问的真实地址 http://192.168.1.103:18081/car
4):进入下一个调用链路
3:choose()方法调用RoundRobinLoadBalancer的choose()方法获取实例。
2.2 Gateway负载均衡源码
负载均衡过程中涉及到2个重要对象 ReactiveLoadBalancerClientFilter 和RoundRobinLoadBalancer ，我们接下来对这2个对象源码展开分析。
2.2.1 ReactiveLoadBalancerClientFilter
1)ReactiveLoadBalancerClientFilter
创建过程中，会初始化一个负载均衡器工厂对象，通过它可以创建负载均衡器
RoundRobinLoadBalancer 。
2)filter()方法
filter()方法完成了主要的服务筛选过程，筛选过程如下：
1:调用choose()获取指定实例。
2:真实实例获取后，把用户请求地址替换成真实服务地址信息。
3)choose()
choose()方法调用了LoadBalancerClientFactory工厂对象创建了负载均衡器，真实实例选择其实是在负载均衡器中完成。
2.2.2 RoundRobinLoadBalancer
1)choose()
该方法只是获取所有有效的实例，并封装成集合对象，然后再调用getInstanceResponse()方法。
2)getInstanceResponse()
该方法通过一定算法获取指定实例，并将指定实例封装成DefaultResponse对象，并返回。
