支付宝钱包客户端技术架构

简介:



黎三平:小微金服高级技术专家,06年就开始移动方面的研发,先后从事过游戏和应用开发。对Android的动态部署和移动应用的开发框架有一定研究,现负责支付宝钱包Android平台基础技术的架构设计工作。

该议题是分析支付宝钱包客户端的技术挑战及背景,讲述钱包客户端技术架构的大思路和整体架构,以及支撑当前架构的一些关键技术。以下来分享其精彩内容。

背景

移动互联网是一个战略核心,支付宝面临着无线化,业务快速推进的问题,且用户规模爆发,android环境复杂。支付宝这样一个支付工具依赖的就是支付产检,所以支付宝有一个平台化的一个构想,可以把支付产检丰富起来。

  支付宝投入的资源也是很大的,有多个业务团队并行开发,纯andioid开发的人员近50人。工程复杂度很高,模块组织方式也有很大挑战,不包括第三方库等其他东西,就有100W+行的java代码,100+个模块。

面临的挑战

  永久的问题:如何提升开发效率,如何提高稳定性,怎样部署,性能如何,安全问题也是支付宝的重要问题。

  研发过程管理困难:1依赖管理,每个模块对其他模块的依赖是管理困难的;2版本管理;3部署管理(搭火车,难以触达到用户);4模块组织方式(库工程,源代码级别,没有权限)。

  构建打包痛苦:可能不能打包(2.x安装不上),合并代码搞了很久,编译打包时间过长。

整体架构

  图1和图2是支付宝钱包客户端整体的架构图:

 

                                                图1

 

                                               图2

 

监控日志主要是用户行为监控,质量监控(包括crash,速度,流量,电量),安全监控以及诊断日志。

  异常处理:所有业务拆分成多个bundles,但如果有一些bundles比如造成闪退了,这时我们就需要做一些故障隔离,就是通过统一的Framework Exception Handler来做这个事情。主线程的Crash;工作线程的异常(网络、存储、其他)。

  安全措施:模块的签名来校验;Dex加固;防二次发布;通讯的安全通道; 防注入攻击(Xposed,Ptrace);其他安全措施。

动态加载

  Quinox容器有三大块:

1、模块管理:安装、升级、卸载;依赖关系的管理。

安装、升级的过程是这样的,我们首先会对所有下载下来的bundles做一个合法性的校验,首先是看它们的签名是否正确,再者看依赖关系是否正确,如果检验通过的话,我们会把它们拷贝到一个可执行域里面去,然后再把元数据持久化,那么下次启动时就会创建类装载,也会把资源初始化。

2、执行引擎:类的装载;资源的管理; Android组件的执行。

3、安全机制:签名校验;容错。

                            图3

图3为执行引擎的原理,在Pathclassloader上做了一些改造,通过它来管理其它的bundles,且对每个bundle都会串接一个类装载器。

 

                              图4

  图4为运行期原理图,通过上面的几项来管理bundles,bundles再进行导入导出服务。

 

研发支撑

 

                                图5

 

图5是研发过程,我们用A-svn库来管理代码,每个团队对应一个svn库,每个团队在自己的库上去开发,获取源代码和提交代码。然后在打包平台上打包,再提交到Maven库中,然后通过发布平台进行动态部署。

 

                               图6

图6是构建过程,左边是传统的构建过程,就是源代码编译生成直接给客户端。右边是做了一些改变,工程里面会有标准的工程布局,就是为了规范代码,编译时会有一个中间的过程,编译成一个二进制包,然后再进行动态部署。



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

 

相关文章
|
1月前
|
缓存 微服务
01.【微服务架构】服务注册与发现:AP和CP,你选哪个? -- 客户端容错
【5月更文挑战第12天】客户端容错机制确保在服务端或注册中心故障时仍能正确发送请求。当服务端崩溃,由于延迟,客户端一段时间内仍会尝试发送请求。客户端应实施 failover 策略,即检测到调用失败后,切换到其他节点重试,并将故障节点从列表移除。延时通常等于服务端与注册中心心跳间隔加通知时间。若网络问题导致客户端无法访问服务端,客户端应发送心跳以检测服务端状态,成功则恢复,连续失败则视为崩溃。若客户端无法连接注册中心,它应使用本地缓存并考虑退出。
24 1
01.【微服务架构】服务注册与发现:AP和CP,你选哪个? -- 客户端容错
|
设计模式 缓存 开发框架
「第二部:容器和微服务架构](10) API网关模式与客户端直接通信2
「第二部:容器和微服务架构](10) API网关模式与客户端直接通信2
|
消息中间件 开发框架 负载均衡
「第二部:容器和微服务架构](9) API网关模式与客户端直接通信
「第二部:容器和微服务架构](9) API网关模式与客户端直接通信
|
JSON 自然语言处理 前端开发
跨端架构下客户端侧API维护方案总结
淘宝App搜索业务侧采用的是局部动态化的跨端技术架构,客户端提供丰富的基础能力与视图组件的API,前端负责业务视图搭建与业务逻辑实现。
|
前端开发 数据库 UED
客户端架构优化
客户端架构优化
63 0
|
JavaScript 应用服务中间件 Apache
实战Node.js之GET/POST请求在Web 应用架构在客户端的使用
实战Node.js之GET/POST请求在Web 应用架构在客户端的使用
实战Node.js之GET/POST请求在Web 应用架构在客户端的使用
|
测试技术 Python
热饭的测开成果盘点第八期:C/S架构大型selenium平台本地调试客户端
本期介绍的是一个wxpython写的客户端,主要是给一套服务端的selenium平台做本地调用。在上回我说到 完全在页面维护的平台反响不好后就转变为使用者可自行在本地写脚本,写好后上传到平台即可,所以做了本地的c/s客户端方便调试用例,而且和平台联系紧密,比如一些公共变量 方法等同步之类的。但是可惜 做了一半我就被陷害愤然离职了,这个客户端也还没正式启用就雪葬了
热饭的测开成果盘点第八期:C/S架构大型selenium平台本地调试客户端
|
移动开发 运维 监控
高德客户端低代码系统架构实践
过去的一段时间里,高德地图App大前端团队一直在对前端低代码搭投技术进行探索,目前已经在客户端多个业务场景落地,充分验证了搭投技术支撑业务快速迭代的潜力。
529 0
高德客户端低代码系统架构实践
|
移动开发 运维 监控
高德客户端低代码系统架构实践
在低代码的实践中,我们发现,除了前端可视化拖拽搭建技术,Serverless、智能化等技术都有助于低代码的业务落地。本文将介绍高德低代码系统架构以及一些新技术的应用方法。
|
定位技术 Android开发 前端开发
高德客户端及引擎技术架构演进与思考
阿里巴巴高级无线开发专家宋照春在高德技术专场做了题为《高德客户端及引擎技术架构演进与思考》的演讲,主要分享了高德地图客户端技术架构沿着「上漂下沉」、「模块化、Bundle化」的思路演进所做的一系列架构升级中的经验和思考。

热门文章

最新文章