互联网系统灰度分流方案

□科技保密信息（密级□绝密 □机密 □秘密保密期限）□非公开信息□公开信息 信息安全提示信息安全提示 本文档传递过程必须遵守“必需知道、最小授权”原则，不得向任何非授权人员提供本文档的全部或 部分内容。 若本文档不属于您知悉范围，应立即销毁，不得保存、传输、复制、印刷或使用本文档之任何内容。 灰度分流方案灰度分流方案 灰度设计方案说明书 文档属性 文档属性文档属性 项目/需求名称 项目/需求编号 文档名称 文档版本号 文档状态 文档编写完成日期 总体设计方案说明书 初稿/修订稿/正式稿 内容内容 文档变更历史清单 文档修订历史文档修订历史 修订修订 版本号版本号 日期日期日期日期 发布发布 修订人修订人审核人审核人确认人确认人归档人归档人修订说明修订说明 1 / 21 灰度设计方案说明书 模板使用说明 1.本文档为总体方案设计阶段产出物，适用于所有应用变更任务的总体方案说明，包括立 项项目及版本需求。对于版本需求，应根据实际情况尽量合并设计方案。 2.模板中所有蓝色斜体内容为编写指引，在实际文档编写过程中必须删除。 3.模板中各层级章节均不得随意删除。版本需求打包的方案，对本次不涉及，如不涉及相 关内容应明确注明。 4.本模板作为应用设计的实施指引纳入开发中心技术规范管理， 由架构管理组负责管理和 维护，开发中心所有研发单位统一执行。 5.各研发单位在实际工作中如认为有必要对模板进行专用化修订， 应向架构管理组提出申 请，经审核后可执行专用模板。 2 / 21 灰度设计方案说明书 目目录录 灰度分流方案1 第第 1 1 章章 概述1 1.1 项目背景.1 1.2 参考材料.1 第第 2 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 业务逻辑6 3.3 网申灰度方案. 11 3.3.1 概要 11 3.3.2 具体方案13 3.4 发现精彩秒杀灰度方案错错误误 未定义书签。未定义书签。 3 / 21 灰度设计方案说明书 3.4.1 概要.错错误误 未定义书签。未定义书签。 3.4.2 具体方案.错错误误 未定义书签。未定义书签。 4 / 21 灰度设计方案说明书 第第 1 1 章章概述概述 1.1 项目背景项目背景 为支持兼容新旧两套系统并行，实施灰度分流控制。 1.2 参考材料参考材料 参考文档 第第 2 2 章章灰度方案灰度方案 2.1 概述概述 通过 Nginx 实现灰度分流，前期可通过设置白名单访问灰度环境（新系统） ，待业务测试达到 预期后，可分流小部分生产流量进入灰度环境（新系统）访问。经过生产复杂用户数据验证新系统 功能稳定性和系统并发性能，在此基础上逐渐加大灰度分流占比，直到各项灰度环境（新系统）指 标稳定后，可将所有生产流量切换到新系统,同时旧系统下线。 2.2 网络实现网络实现 1.所有流量访问旧系统 1 / 21 灰度设计方案说明书 2.流量同时发往新旧系统 3.所有流量访问新系统 2 / 21 灰度设计方案说明书 2.3 应用场景应用场景 互联网应用支持系统、APP 秒杀活动等。 第第 3 3 章章技术方案技术方案 3.1 总体思路总体思路 3.1.1建建设目标设目标 新旧系统同时并行提供服务，对接入流量进行按比率分流。 3.1.2方方案概要案概要 技术方案针对http请求进行灰度和非灰度区分标识,由 Nginx 分流引擎处理分流逻辑,将不同请 求分流至新旧两套环境,并将分流数据存储到Redis.不同的应用系统分流需要根据系统特征进行方案 选择。 主要有以下几种分流类型的后端系统（Nginx 代理的系统） 1.1.无会话，无客户特征系统无会话，无客户特征系统 后台系统仅作为无 session 的服务提供者，通过 HTTP 协议 webservice 或者 RESTFul API 开 放访问，比如网银通过柜面网关提供webservice 接口服务，这些接口服务主要提供给商城、柜面、 支付、网申等关联系统调用。 2.2.有会话，无客户特征系统有会话，无客户特征系统 后台系统维持一段时间内的会话，但后台系统无客户特征数据，比如新用户注册、如在线申请 信用卡等，这些操作后台系统无法提前获取客户特征等（如客户号） 。 3 / 21 灰度设计方案说明书 3.3.无会话，有客户特征系统无会话，有客户特征系统 后台系统作为无 session 的服务提供者，通过 HTTP 协议的 webservice 或者 RESTFul API 访 问，但所有请求基本都有客户特征如客户号、手机号、卡号等，比如手机银行访问个人网银，此时 个人网银后台提供.do 服务，这些服务的操作需要手机银行传入卡号、手机号、客户号、证件号等， 这些客户数据后台系统已经存在。 4.4.有会话、有客户特征系统有会话、有客户特征系统 后台系统不仅维持session会话， 且后台系统存有客户数据， 比如发现精彩APP 访问 worklight, 此时 Nginx 代理的 worklight 系统有会话维持，且客户数据已经存在 worklight 后端系统（实际 worklight 并不保存客户数据，数据由worklight 请求的后台服务提供 ） 。 以上几种类型的后台系统根据不同的灰度实现，都可以互相转换。 3.1.3典典型方案型方案 根据 Nginx 代理的后台系统分类，分别有下面几种比较典型的灰度实现场景，不同的场景需要 一定条件支持 1.1.信用卡信用卡 APPAPP APP 作为前端，Nginx 代理 worklight 作为后端。worklight 具有会话和客户特征数据，如登 录会话、app 设备号、客户号等特征，是一个比较典型的有会话、有客户特征的后端系统，Nginx 分流引擎在后台系统生成会话前生成会话前，通过用户特征数据进行灰度识别 a版本号 b设备号 4 / 21 灰度设计方案说明书 c客户号 d手机号 2.2.网申网申 客户浏览器作为前端、Nginx 代理网申服务作为后端，网申维持客户申请信用卡时间内会话。 a按流量占比分流 3.3.网申网申 客户浏览器作为前端、Nginx 代理网申服务作为后端，网申第二步申请时，根据前一步已经填 写的资料重新操作。 （主要针对网申的业务操作，客户有可能在一次会话内填写了一部分资料信息， 且已保存到后端系统，另启动一个会话重新完善资料，如客户前一天填写完成，过几天后再重新续 填资料） 。 a证件号 b手机号 4.4.网银网银 存在客户状态，但使用前需要验证码等会话认证（生成验证码前无法取客户特征数据） a有可能需要修改业务逻辑， 既是保证前端页面首次与系统交互生成的cookie 会话后就 可以区别灰度和非灰度。如需要一个特别的.do 获取灰度标识，该请求传递cookie 会话到浏览 器，后续所有请求根据该cookie 进行会话通讯。 b c 5 / 2