服务的灰度控制方案简述及示例

前置阅读：现网升级部署——给高速行驶的汽车换轮子

通用灰度控制能力

1、 根据请求的网络及传输层来控制灰度：通过感知请求的Ip信息，可以支持按IP段或解析出地理区域进行灰度 （四层负载均衡支持）

2、 根据请求的应用层来控制灰度：通过感知http请求协议的url、header、body进行灰度。客户端在请求中带上客户端信息或用户信息，进行业务定制灰度（七层均衡均衡支持）

应用层常用的灰度规则：

按设备灰度：app客户端上，可以按照 UID、IMEI、尾号（UID、IMEI）

按版本灰度：请求中，携带版本号进行控制

按用户灰度：请求中，携带用户标识/或业务属性进行控制

hack式灰度：请求中，访问者手动指定携带

灰度控制的参数位置：

url查询参数、http-header、http-body-json、body-form、cookie

灰度控制配置实例

情景	众测/放量策略
App请求	指定版本号进行放量 (header)
Web请求	针对用户进行放量（header/cookie）
Web资源	访问路径、url查询参数、cookie
外部API开放	按调用API的appId进行放量 (header/body-json/body-from)
内部API互调	API版本（url查询参数）

这里，主要针对web服务的灰度，进行一下详细的说明。

示例1：对web商户管理系统进行灰度控制

商户登录到管理系统时，后台登录接口响应里，会在cookie中携带商户号mercNo返回到前台。后续同域下的前后台请求都将携带该cookie，负载均衡上便可以根据cookie里的商户号进行灰度转发。

说明：该方法仅支持商户登录后的请求进行灰度，但不需要前端感知灰度。

示例2：外部商户拉起web收银台

这里有两个灰度场景，一个是开放给外部商户的下单API，一个是web收银台的服务访问。

针对外部商户的下单API。在接口请求中，会携带商户号。负载均衡器可以根据对应的商户号进行灰度转发。

在调用下单API后，前台会得到web收银台的跳转地址，或直接跳转到web收银台。在这里，web收银台的访问地址会携带服务版本号。

web前台资源（css/js/font等），在打包发布时可在html资源里引用时也携带相应的版本号，保证后续的前台资源也转发到对应的灰度机器。

web后台请求，在对应的前台页面控制逻辑里，可统一在请求header或url上携带版本号参数，保证后台请求也转发到对应的灰度机器。

说明：该方法首先在外部API入口处根据调用方判断是否进入灰度，然后在前后台请求中携带版本信息，后续通过版本号进行灰度控制。

在本场景下，版本号灰度比前文设置cookie的方式更好用。 因为如果后续的前后端web请求依旧通过cookie进行灰度控制。那么，当一个用户，在两个商家先后下了两次单，则会出现cookie里的商户号mercNo被覆盖的情况，导致灰度转发混乱。 而通过该方法，在各自拉起web收银台之后，不同收银台的灰度控制是独立的。（控制逻辑在前台）

示例3：App内嵌的H5页面

对于这类H5页面。可以参照示例2中按照版本号灰度的方式。App加载H5页面时，本身也很方便传递版本信息。 而对于页面简单且更新快的H5页面，往往会构建快捷发布上线的能力。每个版本放置在不同的静态目录下。该情况，可以直接通过运营的能力，由app在向后端请求配置类接口得到具体的版本路径访问。