| 编辑推荐: |
| 本文来自于infoq，介绍了APP网关以及APP后端服务灰度，移动APP灰度系统等。 |
|
背景
在这个移动互联网日渐成熟的今天，手机端流量占比高达85%。大家为了抢夺用户手机屏幕上的一席之地，杀成红海，产品的极限飙车、急速迭代。整个系统的日趋复杂可是研发时间一再压缩，变成了移动产品质量的达摩克利斯之剑。
对于Native App来讲，这个问题将变得异常严重，任何一个线上的质量问题修复的成本非常高昂，甚至还要依赖外力来解决。
在这样的环境下，移动端版本灰度发布的价值突显而出：为待发布的移动端版本提供快捷和可控范围的生产环境验证，以确认版本质量是否符合用户和业务的要求。
打造快捷和可控的生产验证，对于移动端来讲需要一个完整的灰度解决方案。相比其他移动端的灰度方案，苏宁金融的方案既包括移动APP环节的灰度，也包括移动网关到整个APP后端服务环节的灰度，实现了在真实生产环境下，苏宁金融APP全链路的灰度，如下图：
图1 苏宁金融APP全链路灰度
接下来我们将分两部分详细阐述： APP网关以及APP后端服务灰度和 APP灰度系统。
1.APP网关以及APP后端服务灰度
随着移动端用户数量的增长，移动后端服务发布出现的事故影响面越来越大，往往可能一个测试没覆盖的低级错误造成大面积线上用户不可使用的故障。
在不断的填坑中，我们发现移动服务端发布存在以下三大问题：
影响范围不可控。一旦发布到生产，特别是一些特别重要的服务的发布，如登录、首页、个人中心等。这些服务一旦出问题，会导致所有用户的崩溃。
发布后验证的时间节点。为了保证上线后第一时间进行生产验证，我们一般在系统调用较少的时候进行发布（半夜）。开发人员的电话需要24小时待机应对生产验证问题，这对开发人员是一个较大的考验。
问题反馈不易，出现生产问题后，只能通过被动的投诉来发现问题，开发人员疲于奔命，产品还要遭到差评。
我们的思路
如何做到生产安全发布呢？我们需要解决以下几个问题：
减小影响范围：发布后尽量不会影响到正常用户使用，将线上问题的影响范围可控。
支持生产环境验证：支持指定人员在指定时间范围内生产环境验证，并支持少量外部用户测试。
实时数据分析：实时采集上线后的日志与并进行异常分析告警。
移动网关以及后端服务灰度方案
我们在接入网关提供一个独立、安全、可追溯的线上灰度发布环境，实现在客户端和业务层不需要改变的情况下，让业务层服务具备灰度的能力。
在接入网关路由层，我们采用Nginx+Lua比较成熟的方案，能按照灰度配置进行流量路由；持久化Redis缓存灰度信息配置，并把相关配置推送到Nginx代理以及下游网关服务器；网关服务与业务服务采用自研RSF微服务调用框架通讯；管理后台负责灰度及路由策略配置。
先来看一下我们的流程图:
图二 移动端网关灰度流程图
1.用户请求流量到达Nginx代理，请求里面包含了设备信息、版本信息、终端信息、用户信息。
2.Nginx Lua Worker根据Redis推送过来的灰度配置，计算当前请求是否在灰度配置名单中，如果在灰度名单中，则路由到灰度聚合网关集群，否则，路由到正常的聚合网关服务器集群。
3.移动后端服务发现：聚合网关与下游后端服务之间采用自研RSF服务协议，苏宁RSF微服务调用框架支持1000+系统，每天服务调用次数达到200亿。RSF提供服务节点的自动注册和发现，服务节点的注册和续约通过Redis来实现，Pump订阅所有Redis的key
space, 当key space发生变化时，Pump聚合所有Redis服务节点数据，将服务提供方节点数据写进ZK,
消费方通过ZK来获取及更新服务方节点列表，从而少量的几台Redis就可以处理几十万的服务节点注册和续约。
1.移动后端服务灰度路由：我们在消费方服务器jvm中添加分组配置，Normal组和Gray组。当消费方服务器启动时，消费方自动将服务器分组信息注册到RSF注册中心，RSF注册中心实时将数据推送到对应的消费方。消费方在发起接口请求时，根据灰度设置计算出路由的规则，从而选择对应的服务器分组。最终：当灰度关闭时，用户请求路由到Gray+Normal服务器；灰度开启时，在灰度名单内的访问，用户请求被路由到Gray的业务服务器集群、不在灰度名单内的访问，用户请求被路由到normal的业务服务器集群。
移动网关以及后端服务支持的灰度规则
APP类型：苏宁金融APP客户端版本、苏宁金融融合钱包等
终端类型：手机型号、手机设备号等
用户类型：用户当前地域、IP、以及基于用户行为数据的分析，指定偏好或特定类型的用户，如门店用户、任性贷用户等
按比例随机用户：可以随机按照5%、10%等比例的流量
加入灰度功能之后，我们的移动服务发布流程也做了一些改变：
移动网关以及后端服务灰度发布
发布步骤：
1.截流：发布之前，进行截流。平常用户的流量被分发到所有Gray+Normal服务器集群，当截流开启时，用户流量全部会路由到Normal服务器以保证外部用户正常访问，而Gray的服务器集群只用于灰度发布。
2.灰度发布：通过CD平台，对网关Gray服务器集群和业务Gray服务器集群发布新代码，此时因为截流开启不会有任何外部流量进来，所以灰度发布不会对线上环境正常访问产生任何影响。
3.部自测：在灰度发布之后，测试人员通过管理后台配置把测试手机设备配置到灰度名单，配置后，此测试手机的访问将自动路由到灰度服务器集群，从而测试人员可以在生产环境既验证新发布的功能，也可以回归老版本的功能，保证了新发布的功能对于线上客户端版本的兼容。
4.外部灰度：内部产品和测试在生产环境上验证没有问题之后，可以通过灰度配置平台配置部分线上流量路由到灰度服务器集群，此配置可以根据客户端的版本号、终端类型等参数选择客户端老版本流量或者新版本流量，从而按照一定范围一定规模进行外部用户的灰度验证。
5.正式发布：经过内部验证和外部灰度验证之后，如果都没有问题，通过持续交互平台继续对正常的生产服务器集群进行分批发布。
6.完成发布：关闭灰度开关。用户的流量将自动路由到Gray+Normal的服务器集群上。
7.异常数据：通过日志采集监控，准实时查看到业务请求的成功率。当成功率低于阀值，会有告警发送给对应业务系统服务人，并且支持一键降级。
价值
可控范围：灰度开启后通过网关代理层（Nginx），动态将正常流量引到Normal网关上，再通过RSF微服务调用流量引导到后端业务灰度服务器上，只有符合条件的可控范围灰度流量能访问到新发布的灰度服务器上，减少发布对正常用户的影响。
线上验证：由于硬件、部署环境以及数据的原因，我们的测试环境与生产环境很难100%的一致，通过网关以及后端业务灰度的功能，支持内部人员进行生产验证，杜绝生产环境不一致可能带来的问题。
数据分析：灰度信息自动采集，异常信息自动告警，出现问题一键降级。
2.移动APP灰度系统
移动APP由于部署的特殊性，灰度有三不易：
应用安装不易，灰度包无法静默安装，往往需要用户主动点击安装，一旦发现致命BUG，需要用户自己卸载灰度版本，回退到稳定版，操作成本较大。
应用分发不易，灰度版本每次更新是新功能的集合体，即使是上万个用户使用，真正使用到新功能的用户不多，从而导致新功能没有充分灰度。
用户反馈不易，出了问题，如何反馈成了一大阻碍，崩溃问题尚能后台自动上传，业务问题不遇到较真的用户，比较难收集到反馈。
我们的思路
受到《退出、呼吁与忠诚》一书的启发（书中对如何保持组织内部的忠诚，有精辟的分类分析），我们认为App灰度的关键在于把灰度版本推送给已经有一定黏性的忠诚用户手上，给出方便的退出机制和反馈机制，并积极的回应他们的反馈，帮助App进入良性的循环。
问题：怎么找到这些用户呢？这就要靠全流程的数据埋点和数据基线。依靠大数据用户行为分析，找到最活跃的用户，更找到那些愿意积极反馈的用户。建立可靠的问题反馈解决机制，维护好APP与灰度用户稳定的互信关系。
我们的App灰度系统就是一个App灰度版本的精准分发和反馈系统，找到灰度版本使用合适的用户并将用户流量导入到新上线的功能，帮我们找到问题，并以最便捷的方式反馈给我们。
图三 移动APP灰度系统架构图
移动APP灰度系统方案
持续集成平台负责管理代码分支、代码编译、应用打包、应用加固。
数据集市是用户行为数据，消费数据的数据中心，提供数据分析引擎。
OSS服务是灰度包对象存储服务，提供私有下载链接，从而防止安卓下载包被应用市场抓包获取，导致流失到外部市场。
接口服务直接面向用户提供灰度下载逻辑功能，部署在高可用高吞吐业务集群，与灰度系统隔离。
图四 移动APP灰度发布流程图
灰度系统后台提供灰度用户配置
1.灰度后台配置灰度用户名单，我们通过客户端的埋点和数据集市行为建模，为用户构建画像，筛选出目标活跃用户，存储到灰度数据库中，也通过推的形式推送给移动升级配置服务的Redis缓存中。
2.灰度系统同时管理安卓的打包服务和IOS的灰度邀请码服务。对于安卓灰度后台将发起一个打包加固的任务，自动生成灰度版本并上传到OSS服务器（对象存储服务器），以供移动升级服务下载使用。对于IOS，灰度后台将扫描苏宁邮箱系统(TestFlight已经提交灰度版本)，与用户信息组合在一起，生成IOS灰度邀请链接，推送给移动升级服务缓存。
3.移动升级服务根据灰度系统推送过来的用户配置分发灰度版本下载链接，在灰度名单中的用户，打开苏宁金融APP的时候就会收到内测版本邀请，参与内测版本更新。
苏宁金融APP全链路灰度发布
下面是苏宁金融APP灰度发布的甘特图：
图五 苏宁金融APP灰度发布甘特图
1.第一阶段，APP服务器端灰度发布到服务端正式发布阶段。APP服务端灰度发布，由于做了截流处理，支持工作时间发布，主要做内部测试和产品人员做生产验证。
2.第二阶段，APP两轮内灰阶段，各产品线开始做APP的灰度验证，第一轮内灰反馈的问题修复后，开始扩大灰度范围，推广到所有企业内部员工灰度。
3.第三阶段，根据依据移动大数据行为分析，筛选出APP外灰名单，给名单内的用户发放灰度版本并收集用户反馈。
4.第四阶段，灰度反馈没有问题之后，投放应用市场。
爆款产品不仅仅只是产品本身，而是一种创新的极致的用户问题的解决方案。苏宁金融移动端通过践行全链路灰度，不仅仅保障了用户持续稳定的获得苏宁金融服务体验，也使得整个研发系统运转效率的本质提升，加强了移动APP的持续交付能力。后面，我们将优化整个灰度链路，加强数据收集和分析在灰度过程中运用，从数据方面来看灰度。 |
