互联网系统灰度分流方案

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