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

简介:



黎三平:小微金服高级技术专家,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

 

相关文章
|
2月前
|
存储 SQL 安全
什么是传统的客户端服务器模式架构
什么是传统的客户端服务器模式架构
|
10月前
|
消息中间件 缓存 测试技术
企业微信针对百万级组织架构的客户端性能优化实践
本文主要分享的是企业微信在百对百万级大规模组织架构(后文简称大架构)时,是如何对客户端进行性能优化过程的,希望带给你启发。
66 0
|
存储 开发者
国标GB28181协议客户端开发(二)程序架构和注册
国标GB28181协议客户端开发(二)程序架构和注册
544 0
|
29天前
|
前端开发 JavaScript 定位技术
高德客户端及引擎技术架构演进与思考
高德客户端及引擎技术架构演进与思考
|
2月前
|
缓存 微服务
01.【微服务架构】服务注册与发现:AP和CP,你选哪个? -- 客户端容错
【5月更文挑战第12天】客户端容错机制确保在服务端或注册中心故障时仍能正确发送请求。当服务端崩溃,由于延迟,客户端一段时间内仍会尝试发送请求。客户端应实施 failover 策略,即检测到调用失败后,切换到其他节点重试,并将故障节点从列表移除。延时通常等于服务端与注册中心心跳间隔加通知时间。若网络问题导致客户端无法访问服务端,客户端应发送心跳以检测服务端状态,成功则恢复,连续失败则视为崩溃。若客户端无法连接注册中心,它应使用本地缓存并考虑退出。
35 1
01.【微服务架构】服务注册与发现:AP和CP,你选哪个? -- 客户端容错
|
8月前
|
XML Java 程序员
页游AS客户端架构设计历程记录
页游AS客户端架构设计历程记录
49 0
|
移动开发 JavaScript 小程序
IM客户端架构设计
一些关于IM客户端架构的总结
260 0
|
设计模式 缓存 开发框架
「第二部:容器和微服务架构](10) API网关模式与客户端直接通信2
「第二部:容器和微服务架构](10) API网关模式与客户端直接通信2
|
消息中间件 开发框架 负载均衡
「第二部:容器和微服务架构](9) API网关模式与客户端直接通信
「第二部:容器和微服务架构](9) API网关模式与客户端直接通信
|
JSON 自然语言处理 前端开发
跨端架构下客户端侧API维护方案总结
淘宝App搜索业务侧采用的是局部动态化的跨端技术架构,客户端提供丰富的基础能力与视图组件的API,前端负责业务视图搭建与业务逻辑实现。