对于一般的小系统并不需要单独的灰度发布引擎，可以参考A/B测试中做法，在页面JavaScript或服务器端实现分流的规则即可。但对于大型的互联网应用而言，单独的用于管理用户分流的发布引擎就很有必要了。
灰度发布
灰度核心要素
主流发布方案
1、蓝绿发布
存在AB两个集群，先将A集群从负载均衡中摘除，进行新版本的部署。B集群仍然继续提供服务。A集群升级完毕，重新接入负载均衡，再把B集群从负载均衡，再把B集群从负载均衡中摘除，进行新版本的部署，A集群重新提供服务。最后B集群都已经升级完成，并且都对外提供服务。
特点：发布策略简单、回滚速度快、需要两套物理环境，有一定资源成本。
2、滚动发布
滚动发布一般取出一个或多个应用实例停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。
特点
发布策略复杂、只需一套环境，节约资源、无确定OK的环境，不易回滚。
3、灰度发布
灰度发布是指在黑白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上而来。
特点：切换新旧并存版本之间的理由权重、整体系统的稳定性有保障、问题影响范围可控。
灰度典型使用场景
通常发布一个新版本可以概括为两种倩况
》 功能性发布，此种发布会直接影响终端用户的操作行为、产品使用体验等
》 非功能性发布，如修复系统 BUG 、提高系统稳定性、提升系统交互速度等
灰度发布在以上两种倩况下都是非常重要的，对于第一种，如在互联网场景下，产品功能迭代速度快，我们需要及早获得用户的意见反馈，让用户参与产品测试，加强与用户互动，同时降低产品升级所影响的用户范围
灰度典型使用场景
当应用上线前，无论进行了多么完善的测试，都无法保证线下测试时发现所有潜在故障。在无法百分百避免版本升级故障的情况下，需要通过一种方式进行可控的版本发布，把故障影响控制在可以接受的范围内，并支持快速回退。
安全生产（可灰度）
灰度平台设计实践
由此可见．实现灰度发布，需要一整套系统和流程的支沛但灰度发布禽要的一些能力是通用的，企业也可以借助其他平台．减少自身的研发运维成本。
灰度策略
EDAS支持两种灰度策略
>按流繼比例灰度
>按清求内容灰度
Spring Cloud :包含Cookie、Header和Param
