冉有-支付宝钱包的研发挑战和最佳实践

支付宝钱包的研发挑战和最佳实践支付宝冉有个人简介• 工作经历  –   6年嵌入式设备软件研发  –   8年项目管理和研发团队管理  –   任小微金服共享平台技术部PMO负责人  –   支付宝钱包决策组成员，小微金服无线产品技术部PMO、Android研发中心负责人  Agenda• 支付宝钱包的演进历程  • 过程中的研发挑战和最佳实践  –   客户端分层解耦拆分；  – 灰度发布；  –   持续打磨新品和精品的RC平台；  – 基于服务端单元化的自动化测试；  – 开放应用的健康度检测和反馈；  –   走向开放的研发支撑平台；  势在必行的客户端拆分纯应用的架构思路，一个系统承载70+的应用，近百万行代码应用间相互依赖，耦合度高  受到Dex包方法数的限制，Android2.x无法安装  源码直接集成，多应用同时研发时，整体稳定性差，编译出错  开发、打包时需要编译整个系统，近20分钟的咖啡时间缺乏基础性的规范，无法支撑业务的快速发展，百人级别的团队大集中作战，研发协同十分困难钱1.0构客户端分层解耦分层结构：SDK-通用技术-业务通用层-业务依赖转置（dependency inverse）:依赖接口，不依赖实现，然后接口沉底  依赖梳理：开发工具，利用POM文件绘制出所有的依赖关系客户端拆分方案– 拆系统  • 拆成多个系统（原则上每个业务有一个独立的系统）  • 原子业务对应独立的jar包  • 业务之间二进制jar包依赖，纯插件设计，可以支持Bundle共享；  • 引用mvn管理依赖  – 资源空间的拆分  • 为每个含res的jar分配一个package  id• 利用反射获取app包资源  – 打包过程不再是所有class都打到一个classes.dex里  • 每个app打包自己的class及res  研发过程演进新旧架构对比进入钱包2.0新形势新挑战• 百万用户就必须考虑的事儿  – 功能  – 稳定性  – 兼容性  • 伸头就是一刀！  – 每次发布前惊天动地  – 每次发布后求神拜佛  • 一次性把事情做对，变成逐步完善，用户参与  从无到有的“灰度发布”• 集团内测  – 内部论坛下载；  – 内网和内部通讯工具反馈；  – IOS  企业版，Android  发布版；  • 外部灰度  • BI清洗数据，白名单控制登录；  • Push推送通知，登录提示更新；  • IOS  越狱版，Android  发布版；灰度发布背后的要求• 监控反馈体系建设  – 应用的数据（UV、PV等）；  – 服务的可用率；  – 稳定性（如闪退）的趋势；  – 反馈渠道完善：微博、论坛、客户端反馈、客服    监控仪表盘灰度1.0的小故事• UID还是TID？    多账户用户的悲剧• 抓包的烦恼• 灰度的反馈速度问题• 单个应用能否灰度？    xx宝、电影票灰度发布2.0• 更加快速高效的收集灰度数据  – 时间窗口、运营商网关IP、白名单等多重控制  – 2个小时内灰度效果可见；  • 更加完备的灰度数据分析  • 流量、电量、网络、RPC性能及错误率等；  • 可视化的发布决策看板；  • 应用粒度的二级灰度控制  • 应用中心统一控制；  • 灰度策略配置中心；  灰度2.0监控反馈完善走向灰度3.0• 建立用户社区，培养粉丝群  • 打通监控反馈到研发的自动化通道：  – 自动关联缺陷，驱动客户端完善；新产品和精品的打磨平台-­‐-­‐  RC• 伸头还是一刀！  – 新产品、新特性也需要持续打磨；  – 线上真实用户体验；  – 老板不希望在实验室、测试环境下才能看到新东西！  • 单独的appid，完全独立的另一个钱包客户端服务端RC方案RZBETAmobilegw线产术GzoneRzone10%-30%-70%-100%双RC的演进• 来自稳定性的要求编码验测试RZBETARZBETA2mobilegw线/术团/10W+GzoneRzone键客户端双RC策略编码验测试发测测试验证RCRC2发mobilegwRC及灰度发布示意routerclientRZbetamobileappmobilebillmobilesecurityRZbeta2mobileappmobilebillmobilesecurityGzonemobileappmobilebillmobilesecuritymobilegwReleaseRC1RC2扩扩开放灵活的移动研发模式编码测试验证应app编码测试验证应appu RC1验证0617编码测试验证应appu RC1验证0618u RC1验证0619编码测试验证应appu RC2验证V8.3u V8.3u V8.3发为维验证应发组织时发稳围级扩发务发键RMPM总监u App发应app动态还有头疼的事儿• 来自基础服务的苦恼  – 支付、登录、账户等基础服务要求稳定；  – 快速多变的移动创新应用，需要基础服务跟上节奏；  • 但，往往是跟不上的！  – 无线创新的需求变更通常临时性、紧迫性；  – 基础服务要满足各个业务BU的各类需求，稳定性第一；  – 请求服务链路长，数据多，测试环境搭建繁琐；  – 甚至出现客户端先于基础服务发布的情况；  怎么破？• 一般做法是用Mock，但仅限于测试环境；  • 还好我们有单元化部署！  – 搭建一个想发布就发布，想怎么玩就怎么玩的Mockzone  • 居然还有惊喜!  • 线上，摆脱实验室和测试环境的不便，场景更丰富  • 除了功能自动化测试Mock，性能测试都不怕！基于服务端单元化的自动化测试• 新建mockzone；  • 配置mock请求判断规则：哪种包，哪个版本，哪个RPC接口需要进行mock；  • 钱包RPC请求首先到达GZONE，如果满足场景2条件，将请求转发到mockzone；  • mock服务器接收到请求后，根据对应规则（如：k-­‐v）返回预先设定的mock结果钱包3.0悄悄走来• 开放和生态体系为他人做好嫁衣• 千人研发的共同目标  – 无线、行业、淘系、友商、ISV  • 接入规范和标准模板  • 接入后服务和业务监控以及巡检  – 应用不可用能否第一时间知道？  – 商户服务窗404？商户的监控服务窗巡检开放式的研发过程支撑• 背景：  – 亿级终端和用户，千万级DAU    – 100+客户端开发人员  – 客户端单平台百万行代码，20+系统，100+工程  – 多条独立业务线，多个独立技术团队并行研发开放式的研发过程支撑• 挑战：  – 如何让上百开发者有条不紊地并行开发？  – 如何管理好百万行代码的变更？  – 如何管理好上百个模块的依赖？  – 如何确保亿级客户端的发布和线上变更的稳定性？  – 如何满足多个业务方对发布节奏和研发效率的不同要求？  开放式的研发过程支撑• 目标：  – 灵活的多团队并行研发  – 稳定可靠的部署  – 可控的线上变更  – 全面主动的监控  – 快速高效的用户反馈处理  开放的研发支撑平台研发交付过程研发支撑平台架构演进谢谢！@InfoQ  infoqchina