一、灰度概念
灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度（概念from百度百科）
二、基本框架和思路
客户端发起请求首先经过ALB（Application Loader Balance），ALB根据分流策略或规则控制引流，从而路由到不同版本的目标服务，基本架构和思路如下图。
三、前台Web灰度实现思路
前台Web应用的灰度发布实现主流实现为nginx+lua+redis，基本思路为请求经过nginx时，根据用户请求cookie或请求header中约定key对应的value来匹配redis中事先存放的关键字，从而判断是否转发到灰度目标前台地址。
四、Web-Service灰度实现思路
服务的路由一般根据服务的版本号来区分，所以在做服务路由，或服务上报时，留着版本号和扩展字段是很必要的，经过前台应用往后台服务路由时，可拿经过nginx获取的userid在redis中过滤，拿到userid对应的服务版本号，该版本号即该用户即将调用的版本服务。
五、全流程灰度
用户发起请求，请求中带上userid,region,env等字段，经过nginx+lua处理时，经过redis过滤是否经过灰度Web，路由至所需Web后，经过redis过滤用户对应使用的服务版本是哪个，由于服务会上报版本到服务管控中心，所以Web端拿到version后，经过ALB去服务管控拿到对应版本的目标服务地址，从而发起调用，实现了全流程的灰度。其中由于涉及到不同环境区域的Web和Service，可在全流程中贯穿的传递userid,region,env等关键字段，可选的为应用所属的appid和subappid。
六、消息系统的灰度
消息的灰度发布实现是比较困难的，因为消息的收发经过消息服务器，没有中介者可以干预路由，但有一个简单的思路，即生产者到消费者的过程中，消费者消费完消息，不做具体的业务逻辑，而是将消息通过服务调用的方式，调用不同版本的服务，在不同的服务中去做不同的业务逻辑，从而实现了消息的灰度。