《互联网系统灰度分流方案》由会员分享，可在线阅读，更多相关《互联网系统灰度分流方案（21页珍藏版）》请在金锄头文库上搜索。
1、信息安全提示 本文档传递过程必须遵守 必需知道 最小授权 原则 不得向任何非授权人员提供本文档的全部 或部分内容 若本文档不属于您知悉范围 应立即销毁 不得保存 传输 复制 印刷或使用本文档之任何内容 灰度分流方案 文档属性 文档属性内容 项目 需求名称 项目 需求编号 文档名称总体设计方案说明书 文档版本号 文档状态初稿 修订稿 正式稿 文档编写完成日期 文档变更历史清单 文档修订历史 版本号 修订 日期 发布 日期 修订人审核人确认人归档人修订说明 模板使用说明 1 本文档为总体方案设计阶段产出物 适用于所有应用变更任务的总体方案说明 包括 立项项目及版本需求 对于版本需求 应根据实际情况
2、尽量合并设计方案 2 模板中所有蓝色斜体内容为编写指引 在实际文档编写过程中必须删除 3 模板中各层级章节均不得随意删除 版本需求打包的方案 对本次不涉及 如不涉及 相关内容应明确注明 4 本模板作为应用设计的实施指引纳入开发中心技术规范管理 由架构管理组负责管理 和维护 开发中心所有研发单位统一执行 5 各研发单位在实际工作中如认为有必要对模板进行专用化修订 应向架构管理组提出 申请 经审核后可执行专用模板 目 录 灰度分流方案 1 第第 1 章章 概述 1 1 1 项目背景 1 1 2 参考材料 1 第第 2 章章 灰度方案 1 2 1 概述 1 2 2 网络实现 1 2 3 应用场景 3
3、 第第 3 章章 技术方案 3 3 1 总体思路 3 3 1 1 建设目标 3 3 1 2 方案概要 3 3 1 3 典型方案 4 3 2 总体结构 6 3 2 1 系统架构 6 3 2 2 业务逻辑 7 3 3 网申灰度方案 12 3 3 1 概要 12 3 3 2 具体方案 14 3 4 发现精彩秒杀灰度方案 17 3 4 1 概要 17 3 4 2 具体方案 17 第第 1 章章 概述 1 1 项目背景 为支持兼容新旧两套系统并行 实施灰度分流控制 1 2 参考材料 参考文档 第第 2 章章 灰度方案 2 1 概述 通过 Nginx 实现灰度分流 前期可通过设置白名单访问灰度环境 新系统
4、 待业务测试达到 预期后 可分流小部分生产流量进入灰度环境 新系统 访问 经过生产复杂用户数据验证新系统 功能稳定性和系统并发性能 在此基础上逐渐加大灰度分流占比 直到各项灰度环境 新系统 指 标稳定后 可将所有生产流量切换到新系统 同时旧系统下线 2 2 网络实现 1 所有流量访问旧系统 2 流量同时发往新旧系统 3 所有流量访问新系统 2 3 应用场景 互联网应用支持系统 APP 秒杀活动等 第第 3 章章 技术方案 3 1 总体思路 3 1 1建设目标 新旧系统同时并行提供服务 对接入流量进行按比率分流 3 1 2方案概要 技术方案针对 http 请求进行灰度和非灰度区分标识 由 Ngi
5、nx 分流引擎处理分流逻辑 将不同 请求分流至新旧两套环境 并将分流数据存储到 Redis 不同的应用系统分流需要根据系统特征进行 方案选择 主要有以下几种分流类型的后端系统 Nginx 代理的系统 1 无会话 无客户特征系统 后台系统仅作为无 session 的服务提供者 通过 HTTP 协议 webservice 或者 RESTFul API 开 放访问 比如网银通过柜面网关提供 webservice 接口服务 这些接口服务主要提供给商城 柜面 支付 网申等关联系统调用 2 有会话 无客户特征系统 后台系统维持一段时间内的会话 但后台系统无客户特征数据 比如新用户注册 如在线申请 信用卡等
6、 这些操作后台系统无法提前获取客户特征等 如客户号 3 无会话 有客户特征系统 后台系统作为无 session 的服务提供者 通过 HTTP 协议的 webservice 或者 RESTFul API 访 问 但所有请求基本都有客户特征如客户号 手机号 卡号等 比如手机银行访问个人网银 此时 个人网银后台提供 do 服务 这些服务的操作需要手机银行传入卡号 手机号 客户号 证件号等 这些客户数据后台系统已经存在 4 有会话 有客户特征系统 后台系统不仅维持 session 会话 且后台系统存有客户数据 比如发现精彩 APP 访问 worklight 此时 Nginx 代理的 worklight
7、 系统有会话维持 且客户数据已经存在 worklight 后端系 统 实际 worklight 并不保存客户数据 数据由 worklight 请求的后台服务提供 以上几种类型的后台系统根据不同的灰度实现 都可以互相转换 3 1 3典型方案 根据 Nginx 代理的后台系统分类 分别有下面几种比较典型的灰度实现场景 不同的场景需 要一定条件支持 1 信用卡 APP APP 作为前端 Nginx 代理 worklight 作为后端 worklight 具有会话和客户特征数据 如登 录会话 app 设备号 客户号等特征 是一个比较典型的有会话 有客户特征的后端系统 Nginx 分流引擎在后台系统生成
8、会话前 通过用户特征数据进行灰度识别 a 版本号 b 设备号 c 客户号 d 手机号 2 网申 客户浏览器作为前端 Nginx 代理网申服务作为后端 网申维持客户申请信用卡时间内会话 a 按流量占比分流 3 网申 客户浏览器作为前端 Nginx 代理网申服务作为后端 网申第二步申请时 根据前一步已经填 写的资料重新操作 主要针对网申的业务操作 客户有可能在一次会话内填写了一部分资料信息 且已保存到后端系统 另启动一个会话重新完善资料 如客户前一天填写完成 过几天后再重新续 填资料 a 证件号 b 手机号 4 网银 存在客户状态 但使用前需要验证码等会话认证 生成验证码前无法取客户特征数据 a
9、有可能需要修改业务逻辑 既是保证前端页面首次与系统交互生成的 cookie 会话后 就可以区别灰度和非灰度 如需要一个特别的 do 获取灰度标识 该请求传递 cookie 会话到 浏览器 后续所有请求根据该 cookie 进行会话通讯 b c 3 2 总体结构 3 2 1系统架构 1 前端渠道发起请求 2 外网通过 F5 分发各 Nginx 分流服务器引擎 3 Nginx 分流引擎获取分流规则 对请求进行标识 并将请求分别转发到生产或者灰度环境 4 Nginx 接入的生产系统或者灰度系统处理请求 并返回数据到 Nginx 5 Nginx 原路将数据返回给各渠道展示 3 2 2业务逻辑 1 按请
10、求类型划分客户主要有灰度客户 非灰度客户 未标识客户 2 按请求时间可分为首次请求和会话请求 整体逻辑如下 红色箭头为客户访问灰度环境的流程 黑色为正常流程 业务逻辑如下 说明 bl 为分流标识 标识客户是否可以进入灰度环境 1 Nginx 接收用户请求 2 Nginx 取出 http 请求 cookie 内灰度标识 bl 3 标识 bl 值为 1 分流到灰度 为 0 分发到生产 标识为未知进入下一步 4 根据客户特征 客户号等 从 Redis 取出上一次灰度标识 bl 5 标识为 1 分流到灰度 为 0 分发到生产 标识为未知进入下一步 6 从 Nginx 内存获取登录序号并递增 1 既是标
11、识客户第几位登录 N 登录序号 N 存入 Nginx 内存 7 从 Redis 获取分流比率 M 8 登录序号 N 对分流因子 X 求模 N X Y 9 Y 值大于 M 时设置标识 bl 0 Y 值小于等于 M 时设置标识 bl 1 10 客户的分流标识存入 Redis 11 标识 bl 为 1 分流到灰度 为 0 分发到生产 下面详细说明请求 Nginx 分流引擎工作内容 3 2 2 1 未标识客户 定义 未标识客户指从来没有与本系统交互的客户 下面说明未标识客户在 Nginx 引擎内的逻辑处理 分发灰度环境示例说明 1 Nginx 接收用户请求 2 Nginx 计算客户登录序号 第几位登录
12、 N 如客户为第 103 位客户登录 标识客户登录序 号 N 103 登录序号 N 存入 Nginx 内存 3 从 Redis 获取分流比率 M 业务设置 M 值为 1 到 100 内的数字 现假设业务设置 M 10 4 从 Redis 获取分流因子 X 业务设置 X 值为固定为 100 5 登录序号 N 对分流因子 X 求模 N X Y 如登录序号为 103 则求模值后 Y 3 6 Y 值小于 M 时设置标识 bl 1 7 客户的分流标识存入 Redis 8 设置 cookie 值 bl 1 9 分流标识 bl 1 分发到灰度环境 分发生产环境示例说明 1 Nginx 接收用户请求 2 Ng
13、inx 计算客户登录序号 第几位登录 N 如客户为第 133 位客户登录 标识客户登录序 号 N 133 登录序号 N 存入 Nginx 内存 3 从 Redis 获取分流比率 M 业务设置 M 值为 1 到 100 内的数字 现假设业务设置 M 10 4 从 Redis 获取分流因子 X 业务设置 X 值为固定为 100 5 登录序号 N 对分流因子 X 求模 N X Y 如登录序号为 133 则求模值后 Y 33 6 Y 值大于 M 时设置标识 bl 0 7 客户的分流标识存入 Redis 8 设置 cookie 值 bl 0 9 分流标识 bl 0 分发到生产环境 3 2 2 2 已标识
14、客户 会话中 定义 已登录且 cookie 会话标识客户为灰度或者非灰度客户请求 下面说明会话中的请求 Nginx 引擎内的逻辑处理 1 Nginx 接收用户请求 2 Nginx 取出 http 请求 cookie 内灰度标识 bl 3 灰度标识 bl 值为 1 分流到灰度 为 0 分发到生产 3 2 2 3 已标识客户 后续登录 定义 已标识客户为灰度或者非灰度客户 本次会话中登录系统 下面说明会话中的请求 Nginx 引擎内的逻辑处理 1 Nginx 接收用户请求 2 根据客户特征 客户号等 从 Redis 取出上一次灰度标识 bl 3 标识为 1 分流到灰度 为 0 分发到生产 标识为未
15、知进入下一步 3 3 网申灰度方案 3 3 1概要 根据申请信用卡不同场景 针对系统请求进行分流 1 系统无客户信息 客户首次进入系统申请信用卡 客户输入图形验证码 手机短信验证码等需要使用会话保持的 信息 前前端端N Ng gi in nx x 1 http 网网申申 3 http r re ed di is s 2 按流量分流 4 图形码 5 cookie标识 6 会话业务数据 7 会话保持 8 灰度数据 证件号 是否灰度等 10 http 11 http 数数据据库库 9 保存数据 2 系统已记录第一次客户信息 客户第二次进入系统补充完善资料 此时客户填写证件 手机等信息 不需要填写图形
16、验证码 或者填写证件号 手机号后才获取图形验证码 因图形验证码与后台系统交互时需要获取 session 会话 获取会 session 话前需提前标识客户是否灰度和非灰度 如证件号 手机号等特征信息则无 法标识请求 前前端端N Ng gi in nx x 1 证件号等 网网申申 2 灰度数据 证件号 是否灰度等 r re ed di is s 3 标识灰度 灰度分发 6 返回 4 分流 7 http 8 http 数数据据库库 5 保存数据 分分流流判判断断 3 3 2具体方案 下面方案 1 Nginx 接收用户请求 2 Nginx 计算客户登录序号 第几位登录 N 如客户为第 103 位客户登录 标识客户登录序 号 N 103 登录序号 N 存入 Nginx 内存 3 从 Redis 获取分流比率 M 业务设置 M 值为 1 到 100 内的数字 现假设业务设置 M 10 4 从 Redis 获取分流因子 X 业务设置 X 值为固定为 100 5 登录序号 N 对分流因子 X 求模 N X Y 如登录序号为 103 则求模值后 Y 3 6 Y 值小于 M 时设置标识 bl 1 7 设置
