手机淘宝客户端架构探索宗心研究.ppt

总线也是为了分而治之的原则，各个业务方对其他业务方都是透明的，减少了以前全在一起的中心总线的复杂度问题 Wax /xpose 主要是由于底层库的pod依赖规则不同步造成问题。 手机淘宝客户端架构探索实践 关于 于佳（宗心） 2011 : 阿里巴巴中文站 阿里巴巴手机客户端 android/iOS 开发 2012：阿里巴巴无线事业部 手机淘宝客户端 iOS 开发 阿里巴巴无线事业部 负责手机淘宝并为阿里巴巴各条无线产品线提供基础技术和设施 发展历程 2010 2012 2013 Android: 披着App外衣的Mobile Web iOS: 围绕购物主链路的基本功能 业务：单工程多分支开发 底层：独立的中间件工程 Android：Atlas插件框架 iOS：多工程插件化开发 1.0 2.0 3.0 产品挑战 承载并整合多样化的业务生态 研发挑战 去年『All-In』的时候 大量业务的同时涌入 火车模型的悬崖效应 10余个团队的代码整合 『量变』呼唤『质变』！ 痛点 协同方式 迭代依赖 分支管理 合并依赖关系过于复杂！ 调试自测效率 模块依赖下的不稳定因素 业务多，回归成本大 测试资源严重不足！其他模块引起的不稳定性因素 发布的灵活性 版本发布无法快速响应 线上已发布版本稳定性 灰度以及线上版本crash难以修复！ 2014 手机淘宝自诞生以来，最大规模的底层重构 改变：开发方式，工程结构，架构模型，打包方式 探索新的路线 围绕着开发效率和性能稳定性等一系列问题 工程拆分 支持多团队并行开发 架构重构 重新梳理容器和总线规则 配套工具 使用有力工具增加开发效率 工程拆分 并行开发 业务解耦 独立调试 集成之前，在稳定环境下测试 易于集成 修改配置完成集成 工程拆分 开发阶段 提供稳定的开发环境（底层库，接口） 各个业务方独立开发 测试阶段 单独业务独立打包 针对该业务的测试回归 集成阶段 修改podfile进行集成测试 针对整体流程做回归 架构重构 需要解决的问题 迭代开发，并行开发能力差。 耦合严重，核心功能（URL导航）复杂 试错成本过高，增加减少业务带来的成本。 快速迭代下的稳定性问题。 指导思想 分而治之 并行开发 一切皆组件 BundleApp 解除耦合，制定标准 总线 URL总线（跨平台统一URL寻址方式）：三平台统一URL，自动降级，中心分发（支持hook） 服务总线 ：根据服务接口提供稳定服务 消息总线 ：中心分发，按需加载 开发透明 只需要遵守规则，不关心底层/其他业务实现 Bundle (deployable unit) Runtime Bus (UI Service Message) Lifecycle Management Bundle Management UIs Services App/Service Project RuntimeProject Bus Library Libraries Libraries … 减少新业务接入/移除成本 标准化 统一的通信调用标准，bundle间互通的基础 无法回避的瘦身问题 灵活性 Bundle自由组装（淘宝生活，码上淘） 中间件基础库自由引入 及时响应线上问题 『Move fast and break things』 via Hot Patch 线上严重问题快速修复（小时级的响应时间） AOP编码形式 Before/After/Replace 某个方法 编写容易，发布规范 配套工具 工程拆分遇到的问题： 频繁的更换spec 源码引入造成的pod update缓慢等原因 开发阶段集成阶段等问题 工具解决 摩天轮自动打包平台（自动生成spec，framework引入） 开发-集成-灰度，多阶段管理 其他工具解决的问题： 核心链路性能监控平台 Crash分析平台 耗时2个月完成 6月初上线以上 集成 Bundle：30+ 改造为服务：10+（登录、缓存、搜索组件） Hot Patch 修复线上严重故障 10+ 起 Patch 最大6KB，大部分不到1KB（iOS） 最大的阵痛：底层依赖迁移引起的编译失败 Bundle重组，互通有无。 业务复用，减少人力 基础复用，做深做精 敏捷开发，快速试错 开发透明，实时发版。 动静结合，开发透明 动态部署，渠道推送 未来 总线也是为了分而治之的原则，各个业务方对其他业务方都是透明的，减少了以前全在一起的中心总线的复杂度问题 Wax /xpose 主要是由于底层库的pod依赖规则不同步造成问题。