1、灰度发布解决线上什么问题？
公司项目，每次发布上线都是在晚上时间段进行发布，这严重打乱了个人的作息，尤其是下单业务，每次上线，都是惊心胆颤的，为了消除这【心理】问题，在新项目时，需要把灰度发布引入进来，从而达到，妈妈再也不用担心我的作息了，想什么时候上线，看心情。
灰度发布，个人理解，主要是采用一个切换流量的思路来上线或者用于其他场景（自行百度）
2、灰度发布归类
网上大部分考虑的都不够全面，有的说nginx+lua，有的说kus8，有的spring cloud zuul....太乱了
个人大总结：整个架构面临如下几种情况的灰度发布
a、nginx+upstrem的tomcat的应用，需要实现，禁用流量到tomcat：nginx面临控制灰度发布
实现思路：nginx+lua，openresty
b、spring cloud zuul+一般的web服务/eureka上的服务（未注册到eureka和注册到eureka），需要实现，禁用流量到一般web服务，zuul面临控制灰度发布
c、因为服务与服务之间也存在调用(不一定经过zuul网关)， 注册到eureka的服务，需要实现，各个服务禁用流量，各个服务面临灰度发布
实现思路：eureka的端点， 来禁用注册中心上的实例，然后等待sleep 1-2分钟，然后平滑的shutdown
3、但本文的重点描述，如上第二种(b)情况，详细实现
注意：网上有说采用ribbon-discovery-filter-spring-cloud-starter（https://github.com/jmnarloch/ribbon-discovery-filter-spring-cloud-starter）
请慎重，因为刚开始我也是采用ribbon-discovery-filter-spring-cloud-starter的方式来实现，当采用jemter进行并发测试时，坑坑无数 。
那么怎么来实现：
实现思路：实现自定义rule，通过重写rule来实现灰度发布，但是.......如果我部署多台zuul，也会有问题，从而改进思路： 实现自定义rule，然后将需要禁用流量的服务信息，放于redis里面，来支持，zuul的负载的灰度处理，每次需要上线一个服务时，通过sh脚本在将此实例信息放于redis，此时该服务实例就不会有流量进入，再进行发布
实现代码：
a)、 实现自定义predicate，继承AbstractServerPredicate
b)、 实现自定义rule，继承PredicateBasedRule
c)、 在Configuration类里面，注入自定义rule
