开发者社区> 云学习小组> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

手机淘宝客户端架构探索实践

简介:
+关注继续查看


宗心:淘宝无线事业部资深开发工程师,手机淘宝iOS架构组开发工程师,2012年底参与开发手机淘宝iOS3.0版本,经历大小几十个版本的变迁,针对手机淘宝总体设计架构,hybrid框架解决方案,插件化解决方案以及手机淘宝核心业务组件均有参与和贡献。(阿里巴巴无线事业部:负责手机淘宝并为阿里巴巴各条无线产品线提供基础技术和设施)。

2014年手机淘宝经历了自诞生以来最大规模的一次重构。经历了去年业务的爆炸性增长,以及性能稳定性等多方面挑战后,手机淘宝在开发模式,客户端架构上面都必须做到轻量,透明,延展,敏捷。本内容会重点介绍手机淘宝iOS基础架构的第三代架构如何演进落地,实现多条业务线间独立并行、研发效率提升的目标,以及如何应对未来可能变化。以下是关于手机淘宝客户端架构探索实践的精彩内容:

 

                            图1

  如图1所示,手机淘宝从1.0用单工程编写开始,东西非常简陋;到2.0为索引许多三方库的庞大的单工程;再到3.0打破了单工程开发模式实现业务复用,包括承载充值,聚划算,航旅等业务,由于业务越来越多,我们想到了插件化的方案,就是制定一套业务的规则和标准,让这些插件按照我们的标准,我们提供的库进行开发。

我们遇到了产品和技术上的挑战和开发的痛点,协同方式上的迭代依赖和分支管理困难,合并依赖关系过于复杂!调试自测效率低——模块依赖下的不稳定因素,业务多,回归成本大,测试资源严重不足!其他模块引起的不稳定性因素。发布的灵活性不足——版本发布无法快速响应,线上已发布版本稳定性,灰度以及线上版本crash难以修复!由于很多APP集成到客户端,各个业务的对接有一定的难度,自己的业务开发完全不够支持这些功能,十余个团队的代码整合也不易,业务持续增长的量变将会导致质变。

2014年是手机淘宝自诞生以来最大规模的底层重构,改变了开发方式、工程结构、结构模型、打包方式。我们将围绕开发效率和性能稳定性等一系列问题探索新的路线,主要有:

工程拆分——支持多团队并行开发

多个业务团队更改一个或多个文件,交叉管理时,底层的东西不稳定就没有办法进行上层开发,所以首先进行业务解耦;其次要进行独立调试;最后修改配置完成集成。拆分的结果如图所示,实践证明,工程拆分以后,整体业务的盆跑速度有了明显提升。

工程拆分分为三个阶段:

开发阶段:提供稳定的开发环境(底层库,接口),各个业务方独立开发;

测试阶段:单独业务独立打包,针对该业务的测试回归;

集成阶段:修改podfile进行集成测试,针对整体流程做回归。

 

架构重构——重新梳理容器和总线规则。

  架构重构需要解决几个问题:迭代开发,并行开发能力差;

耦合严重,核心功能(URL导航)复杂;试错成本过高,增加减少业务带来的成本;快速迭代下的稳定性问题。架构重构的指导思想如图所示,我们制定规范,让各个业务方自己运行,依照规范直接集成进来或出去。核心的架构在容器层,初始化在容器层统一管理,总线是一个核心的解耦方案,通过图2中三种方式进行解耦。容器之上下全部为bundles,每一个业务全部做成bundle以后,当耦合度解的很好的时候,任何的bundles都可以拼成一个APP。

                               图2

用总线的方式解除耦合,制定标准。

URL总线(跨平台统一URL寻址方式):三平台统一URL,自动降级,中心分发(支持hook)。

服务总线 :根据服务接口提供稳定服务。

消息总线 :中心分发,按需加载。

总线也是为了分而治之的原则,各个业务方对其他业务方都是透明的,减少了以前全在一起的中心总线的复杂度问题。只需要遵守规则,不关心底层/其他业务实现。图3是一个总线图,

                                         图3

减少新业务接入/移除成本:

标准化:统一的通信调用标准,bundle间互通的基础;无法回避的瘦身问题。

灵活性:Bundle自由组装(淘宝生活,码上淘),中间件基础库自由引入。

图4为一个bundlapp,将手机淘宝等的部分bundles拿出来作一个配置 ,将业务bundles,底层bundles作一个重组,组出一个app手机窗口,目的是做一个bundle的复用。

 

                           图4

及时响应线上问题图5所示

                         图5

 

配套工具——使用有力工具增加开发效率。

  工程拆分遇到的问题:频繁的更换spec;源码引入造成的pod update缓慢等原因;开发阶段集成阶段等问题。

工具解决:摩天轮自动打包平台(自动生成specframework引入);开发-集成-灰度,多阶段管理。

其他工具解决的问题:核心链路性能监控平台;Crash分析平台。

  6月初上线以来,重构结果为:集成 Bundle30+;改造为服务:10+(登录、缓存、搜索组件);Hot Patch 修复线上严重故障 10+ 起;Patch 最大6KB,大部分不到1KBiOS)。最大的阵痛是底层依赖迁移引起的编译失败,主要是由于底层库的pod依赖规则不同步造成问题。

  关于重构之后的未来探讨如图6所示

                             图6



 

                                                                                PPT下载地址:http://club.alibabatech.org/resource_detail.htm?topicId=153

 

 

 

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
微博红包技术最佳实践:架构及运维
云栖社区2017在线技术峰会红包技术分会上,来自微博红包团队的技术负责人柯立志分享了微博红包背后的技术实践。他介绍了红包的业务场景,从红包塞钱、抽奖、拆包模型、数据一致性、预热、异步化等方面介绍了红包系统的设计思路。此外,他对红包的系统保障和性能优化也进行了分享。
6105 0
客户端稳定性优化实战,Crash率最高下降40%
大促一直是技术和产品的练兵场,每到大促,各种丰富的富媒体,如直播,视频,3D,游戏互动,AR等竞相上线,在淘宝的大航母战略下,都集中在万千宠爱于一身的淘宝App上,在这样的大促场景下,开始触碰到端侧系统资源上限的天花板。在17年双11大促期间,端侧的内存问题尤为突显,OOM的高居所有问题的榜首。内存问题成为了这几年大促端侧稳定性最大的挑战。
0 0
Qcon演讲实录|手机淘宝客户端的攻防演练实践
混沌工程是一个业界比较流行的防范系统性风险的方法论, 其核心思想是通过不断地失败来避免失败,以主动制造故障的方法来宏观地验证业务的容灾和恢复能力。这一概念在服务端存在大量的实践和落地, 在客户端还是属于探索阶段,业界甚少甚至没有类似尝试。手机淘宝等大型应用其实是一个广义概念上的分布式系统, 混沌工程理念是否也可以在这类型广义分布式系统上产生价值呢?答案是肯定的,本次分享将向大家介绍手机淘宝客户端是如何使用攻防演练来降低客户端系统风险、提高快速交付能力的。
0 0
十分钟学会使用 Elasticsearch 优雅搭建自己的搜索系统(附源码)
十分钟学会使用 Elasticsearch 优雅搭建自己的搜索系统(附源码)
0 0
解决微服务架构下流量有损问题的实践和探索
绝⼤多数的软件应⽤⽣产安全事故发⽣在应⽤上下线发布阶段,尽管通过遵守业界约定俗成的可灰度、可观测和可滚回的安全⽣产三板斧,可以最⼤限度的规避发布过程中由于应⽤⾃身代码问题对⽤户造成的影响。但对于⾼并发⼤流量情况下的短时间流量有损问题却仍然⽆法解决。因此,本文将围绕发布过程中如何解决流量有损问题实现应⽤发布过程中的⽆损上下线效果相关内容展开⽅案介绍。
0 0
解决微服务架构下流量有损问题的实践和探索
绝⼤多数的软件应⽤⽣产安全事故发⽣在应⽤上下线发布阶段,尽管通过遵守业界约定俗成的可灰度、可观测和可滚回的安全⽣产三板斧,可以最⼤限度的规避发布过程中由于应⽤⾃身代码问题对⽤户造成的影响。但对于⾼并发⼤流量情况下的短时间流量有损问题却仍然⽆法解决。因此,本文将围绕发布过程中如何解决流量有损问题实现应⽤发布过程中的⽆损上下线效果相关内容展开⽅案介绍。
0 0
淘宝iOS扫一扫架构升级 - 设计模式的应用
本文在“扫一扫功能的不断迭代,基于设计模式的基本原则,逐步采用设计模式思想进行代码和架构优化”的背景下,对设计模式在扫一扫中新的应用进行了总结。
0 0
+关注
云学习小组
一群热爱技术的朋友们在云栖社区组成的学习小组!
文章
问答
文章排行榜
最热
最新
相关电子书
更多
新浪广告系统的服务化优化历程
立即下载
新浪广告系统服务化优化
立即下载
微信H5视频播放器在海量业务下的实践
立即下载