互联网系统灰度分流方案.docx

信息安全提示：
——本文档传递过程必须遵守"必需知道、最小授权”原则，不得向任何非授权人员提供本文档的全部或 部分内容。
——若本文档不属于您知悉范围，应立即销毁，不得保存、传输、复制、印刷或使用本文档之任何内容。
灰度分流方案
手机号、客户号、证件号等， 这些客户数据后台系统已经存在。
4・有会话、有客户特征系统：
后台系统不仅维持session会话且后台系统存有客户数据比如发现精彩APP访问worklight, 此时Nginx代理的worklight系统有会话维持，且客户数据已经存在worklight后端系统（实际 worklight并不保存客户数据，数据由worklight请求的后台服务提供）。
以上几种类型的后台系统根据不同的灰度实现，都可以互相转换。

根据Nginx代理的后台系统分类，分别有下面几种比较典型的灰度实现场景，不同的场景需要 一定条件支持：
:
APP作为前端，Nginx代理worklight作为后端。worklight具有会话和客户特征数据，如登 录会话、app设备号、客户号等特征，是一个比较典型的有会话、有客户特征的后端系统，Nginx 分流引擎在后台系统生成会话前，通过用户特征数据进行灰度识别：
a） 版本号
b） 设备号
c） 客户号
d） 手机号
2・网申：
客户浏览器作为前端、Nginx代理网申服务作为后端，网申维持客户申请信用卡时间内会话。
a）按流量占比分流：
3・网申：
客户浏览器作为前端、Nginx代理网申服务作为后端，网申第二步申请时，根据前一步已经填 写的资料重新操作。（主要针对网申的业务操作，客户有可能在一次会话内填写了一部分资料信息， 且已保存到后端系统，另启动一个会话重新完善资料，如客户前一天填写完成，过几天后再重新续 填资料）。
a） 证件号
b） 手机号
4网银：
存在客户状态，但使用前需要验证码等会话认证（生成佥证码前无法取客户特征数据）
a） 有可能需要修改业务逻辑，既是保证前端页面首次与系统交互生成的cookie会话后就 可以区别灰度和非灰度。，该请求传递cookie会话到浏览 器，后续所有请求根据该cookie进行会话通讯。
b）
c)

财心灰度分流整体架构
进件系统
决策系统
短信平台
营徜平台
密码平台
厂］"有-="葡「「褫「「-甄=:
————1 I I 1_ __ I __ L — — — — — — — L
F5
飕inK分流引擎 Redis分流规则
___
项度环境（新系统） 生产环境（旧系统）
DF?D璋群 配璘据库
前端渠道发起请求.
外网通过F5分发各Nginx分流服务器引擎
Nginx分流引擎获取分流规则，对请求进行标识，并将请求分别转发到生产或者灰度环境
Nginx接入的生产系统或者灰度系统处理请求并返回数据到Nginx.
Nginx原路将数据返回给各渠道展示.

按请求类型划分客户主要有灰度客户、非灰度客户、未标识客户。
按请求时间可分为首次请求和会话请求。
整体逻辑如下：
NEm灰度分施工作圈
红色箭头为客户访问灰度环境的流程，黑色为正常流程，业务逻辑如下：
说明：_bl_为分流标识，标识客户是否可以进入灰度环境。
Nginx接收用户请求；
Nginx取出http请求cookie内灰度标识:_bl_;
标识_bl_值为1分流到灰度，为0分发到生产，标识为未知进入下一步；
根据客户特征（客户号等）从Redis取出上一次灰度标识:_bl_;
标识为1分流到灰度，为0分发到生产，标识为未知进入下一步
从Nginx内存获取登录序号并递增1,既是标识客户第几位登录:N。登录序号（N）存入 Nginx
内存；
从Redis获取分流比率：M;
登录序号（N）对分流因子（X）求模：N%X二Y;
Y值大于M时设置标识_3_=0,丫值小于等于M时设置标识_3_=1;
客户的分流标识存入Redis;
标识_bl_为1分流到灰度，为0分发到生产。
下面详细说明请求Nginx分流引擎工作内容：

定义：未标识客户指从来没有与本系统交互的客户。
下面说明未标识客户在Nginx引擎内的逻辑处理：
FJ哲ru茨度分施首次登录
nedis
网苏流好和田予
胃有桥迎
分流因子洪
交互前婿 清求
岫伽分源号I擎
Nginx（Lua）
•分发灰度环境示例说明：
Nginx接收用户请求；
Nginx计算客户登录序号（第几位登录）:N，如客户为第103