携程下一代无线App架构
三个分类
携程无线现状
(在线20)、呼叫中心8、无线72
如何实现无线化
引用Conways law
组织解耦,
横向团队,基础框架团队(开发框架、功能SDK)和服务(系统管理、网络、存储)
技术解耦
解耦传统n曾架构,SOA化,Microservice
解耦数据,提供数据服务,实现数据模型封装,
开发团队拆开,数据才容易拆
服务端
曾经的问题
- 进程耦合
- 缺少负载均衡
- 缺少监控
- 缺少熔断
- 安全性风险
app端
UI层|数据层|基础库
使用总线封装,层级划分
APP组件化
核心功能SDK化,业务功能组件化,减少重复工作
app业务容器化
隔离性和稳定性
扩展性和伸缩性,支持动态加载以及Hotfix
性能:独立指标
插件化和动态加载框架-DynamicAPK
更少迁移成本,不需要proxy
提升启动速度,在5.0以下比MultiDex快
按需下载,加载任意功能模块
Hybrid框架
Hybrid与Native功能互通
离线包模式,降低离线加载时间;因为App Size模式部分低频使用直连
查分增量更新
移动网络服务通道治理和优化
一直在喊用户体验
Native服务网络请求/Hybrid请求/Push服务网络请求/IM服务网络请求/用户行为和性能日志上传网络请求
网络通道治理思路
- 减少连接次数,用keepalive管理长连接
- 避免DNS劫持和内容劫持(失败率很高,1%),内容劫持
- 减少发送次数/压缩来减少流量
- 安全稳定
- 能够支持多数据中心
Native服务
长连接失败,使用短连接
网络服务重试机制/但是有些业务会有风险,要注意区分
使用IP列表避免DNS解析失败,IP列表下发机制;如何选择IP地址,选择网络延时最小的IP地址(ping估算RTT)
使用ProtocolBuffe+Gzip来减少Payload
Native服务。从成功率来讲,相较于HTTP96%的成功率,TCP的感觉效果好99.87%,尤其在偏远地区(App端到端网络服务成功率)
Hybrid服务网络请求
常见问题:DNS劫持、内容劫持
解决方案:
阿里,拦截webview的请求实现转发;携程在Hybrid框架层,
Hybrid框架通过TCP通道进行业务服务转发/页面等静态资源通过MAA等加速产品实现防劫持和加速。97%-》99%+,
耗时减少接近一半。
其他通道治理
尽量基于TCP长连接实现网络功能:Push/IM/用户行为和性能日志上传
优先使用成熟服务:国内:MAA等防劫持和加速产品。海外:Akaima TCP/HTTP专有加速通道。
无线研发支持平台
为什么需要支持平台?
- App端到端性能管理
- 用户行为统计
- 持续集成
- 配置中心
集成平台
支持Bundle独立打包,实现持续集成
自动化测试平台(功能化自动化测试现阶段难度还是太大,现在的自动化测试时,手工测试之后,能够帮你录制testcase!!!主要是方便用于不同系统版本平台测试或者是不同手机测试)
发布平台()
运营平台
监控平台
自动化测试平台
基于STF管理机器(Smartphone Test Farm)
安卓是用一个平台,iOS可以直接录制testcase
监控平台
采集性能数据SDK:自建或者第三方。OneAPM、听云
制定性能指标:balabala。如何展示数据?