一、灰度发布期待的效果分析

1.1 灰度发布前

image.png

灰度发布前，系统处于正常使用状态，用户在浏览器输入地址访问前端H5页面，前端页面将请求转发至zuul, 并获取相应的数据。
注：此时后端的微服务都是双节点部署，微服务B可以对两个服务C发起调用。

1.2 灰度发布过程中

image.png

灰度发布中前端页面新增部署灰度版本，此时用户也基于ip区分是正式用户还是灰度用户。
正式用户只能访问正式的H5页面，相应的页面请求为：

前端H5A正 -> 微服务B正 -> 微服务C正 -> 微服务D正

灰度用户只能访问灰度H5页面，相应的页面请求为：

前端H5A灰 -> 微服务B灰 -> 微服务C灰 -> 微服务D灰

1.3 灰度发布完成后

image.png

灰度发布完成后，前端H5A灰、微服务B灰、 微服务C灰 、微服务D灰四个服务将升级为最新的正式版服务。前端H5A正、 微服务B正、 微服务C正、 微服务D正 四个服务也将进行升级，升级后变为最新版本的正式版服务。
服务调用流程和发版前相同，只是所有服务的版本都进行了升级。

二、灰度发布难点与相应的技术解决方案

2.1 如何判断用户是正式用户还是灰度用户

根据ip来判断用户身份是最方便也是最合理的。如果是基于用户token或者用户profile等，可能会面临登陆前身份识别的问题，游客访问的页面无法进行灰度等情况出现。

2.2 如何动态配置灰度用户访问进行流量切换

灰度的流量切换依据两个方面，平台设置和用户ip地址。
a、如果平台设置为全部灰度，那么所有用户都将调用灰度服务。
b、如果平台设置为部分灰度，那么将基于ip判断用户是正式用户还是灰度用户，正式用户将调用正式服务，灰度用户将调用灰度服务。
c、如果平台设置为全部正式，那么所有用户都将调用正式服务。
注： 之所以使用双因素判断，是为了方便后期的服务发版。

2.3 后端微服务调用链路中正式版和灰度版不混用

请参考 Nepxion/Discovery 非常不错的框架

image.png

项目地址：

https://github.com/Nepxion/Discovery.git

2.4 如何动态配置后端微服务为正式版还是灰度版

使用redis 动态配置正式版和灰度版请求的header参数，然后再基于ip去判断用户身份，并基于nginx + lua + redis 读取redis中的header参数，并动态修改不同身份用户的header参数.