前言
对灰度发布有所了解的同学应该知道，灰度发布的目的之一，就是能够根据业务规则的调整，交互上呈现不同的形式，举例来说，当前有2个版本，V1.0和V2.0 ，那么可能表现的形式大概有下面几种：
- V1.0，界面上的交互形态为A，V2.0版本界面上的交互形式为B；
- 某个交互，针对同一个接口A来说，V1.0，请求接口A，要求的返回值包括5个字段；V2.0，请求接口A，要求返回值包括10个字段；
- 某个交互，在V1.0和V2.0中，将使用不同的接口；
- …
实际情况可能会更复杂，在微服务广泛使用的今天，一般的思路是，通过一个获取配置的接口，前端拿到所有的参数配置，根据参数配置的不同，具体实现思路如下：
- 比如V1版本下，某个配置的值为1，这时候使用A交互；如果要使用交互B，只需要更改配置中心这个值为2，则前端就可以将交互切位B；
- 或者说，交互不变，但是交互的处理逻辑更复杂了，于是原来的接口无法再满足要求，这时候，可以重新提供一个接口，同样通过配置参数的不同来控制；
于是，从后端接口层面来说，一个比较常用也是通用的处理方式是，通过配置接口来达到切换交互，或者说达到灰度发布的目的，灰度发布的核心本质也正在于通过某种方式从一种数据形态切换到另一种形态；