微信号:infoqchina

介绍:有内容的技术社区媒体

案例|魅族应用商店云端架构实践

2015-12-12 08:11 胡成元

应用商店可以说是移动设备上最特殊的一个应用,它用于分发和管理其它应用,是移动操作系统的核心之一,但和操作系统其它组件不同,它需要一个庞大的云端作为支持。


魅族应用商店是国内最早的应用分发平台,在国内首创了许多业务模式,本次魅族工程师将分享魅族应用商店云端的整体架构。


水平分层、垂直拓展


应用商店首先定位于应用管理平台,其次更是应用分发平台,其典型业务场景包括:


  • 帮助Flyme用户找应用;

  • 帮助Flyme开发者推广、分发应用;

  • 营造维护应用分发生态圈。


根据业务场景,不难推导出业务架构特点:


  • 读多写少;

  • 请求量大、并发高;

  • 系统要求延时低;

  • 数据规模可控;

  • 用户关联弱。


随着用户规模的增长,不断的重构、线上运行、探索与沉淀,逐步形成了当前平台的架构。如下图所示。横向、典型的三层架构;纵向、以业务为驱动,积累沉淀了众多技术规范、基础组件,丰富完善全栈业务监控。依托完善的监控体系,衍生出相应的服务治理机制。




服务化框架


平台早期,规模小、结构简单。伴随公司互联网转型,用户规模高速增长、业务增多,平台关系复杂、扩展难、开发效率低,原有架构完全无法服务大规模的Flyme用户。


为了减少业务依赖、提升集群效率、提高开发部署效率,我们基于业务典型场景,把业务逻辑模块化,单元化。拆分出了应用管理、应用展示(榜单)、应用推荐(个性化推荐)、应用搜索等多个服务。


服务分为两类,一类是基础服务,该类不依赖其他服务,业务逻辑简单,仅提供基础业务逻辑,例如应用管理服务。另一类是聚合服务,该类聚合多个基础服务,形成相对复杂的业务逻辑,例如应用搜索服务。


成型服务化框架能满足大众化的需求,如远程调用、动态发现、负载均衡、监控等,同时势必会引入一些无关的功能,影响性能。外加此类产品无法满足我们的定制化需求,我们重复造轮子。与以往同类产品不同,我们做了如下改进:


  • 精细化度量指标

  • 实时度量计算

  • 系统依赖、调用链

  • 无缝IT系统集成


服务间采用自研的Kiev框架通讯。Kiev底层通讯基于Netty网络框架,序列化支持协议支持Hessian、Protobuffer等,支持跨语言(C/Java)调用,通讯协议支持TCP、UDP等。框架基于ZK(ZooKeeper)实现了High Availability与Load Balance策略。服务调用时会采样,生成详细的调用链,收集,产生丰富的服务状态数据(Response Time,QPS),为服务治理提供了详实有力的数据支撑。


消息队列(MetaQ)


消息队列是分布式应用间交换信息的一种技术。为了解核心业务及辅助业务,我们引入消息队列,将搜索团队、大数据团队需要的业务数据定期全量同步,实时增量更新。既隔离了业务间的强耦合,又保障了数据的及时性。


接口规范


接口众多、形式多样,管理维护成本高,为了规范开发流程、便于问题跟踪定位,我们制定了统一的接口规范。例如接口采用RESTful风格,统一接口返回形式,约定每个业务层的错误编码,每个错误编码还会携带可选的错误提示,方便问题跟踪。


安全性也是平台不可忽略的一个关键点,基于通用型的原则,我们采用了业界通用OAuth协议来保障接口安全。为了应对异常流量对系统造成的冲击,我们给接口层添加了流量控制功能。


分布式缓存


平台早期,分发接口采用DB+本地缓存的方式提供数据,这种模式DB压力大、接口吞吐量小、本地缓存更新不及时。为了解决这些问题,我们引入分布式缓存Redis。业务接口数据全部被缓存到Redis集群,缓存数据由定时任务主动刷新,零穿透,缓存即存储、存储即缓存。依托Redis的高性能极大的提高了系统吞吐量。Redis集群先按业务场景做垂直切分、再根据数据量做水平分片。业务通过代理(Twemproxy)连接所有分片。Redis集群基于ZK实现HA(High Availability),基于定制化脚本实现线上自动扩容,这样既保障了缓存集群的高可用性,又满足了集群容量自动扩充的需求。


MySQL水平分片


随着用户规模增长,单库单表已无法满足业务需求,为此我们将数据量大的用户数据库横向拆分出多个数据库。为了降低运维成本,我们采用了单实例多数据库的部署模式。业务层通过分库路由组件透明的访问数据库。当单实例多数据库的模式无法支撑当前业务需求时,通过更新路由规则就可以平滑的完成DB扩容。


GSLB(Global Server Load Balance)


使用域名提供服务的互联网企业,都无法避免在有中国特色的互联网环境中遭遇到各种域名被缓存、用户跨网访问缓慢等问题。Flyme互联网基础架构团队推出了一种全新的域名解析调度系统:GSLB。GSLB是为移动客户端量身定做的基于Http(s)协议的流量调度解决方案,解决LocalDNS解析异常以及流量调度不准。


GSLB的原理非常简单,主要有两步:


1 客户端直接访问GSLB服务接口,获取业务在GSLB服务中配置的访问最优的IP。基于容灾考虑,我们保留了运营商LocalDNS域名解析的方式。


2 客户端获取到的业务服务IP后,直接向此IP发送业务协议请求。

GSLB将域名解析的协议由DNS协议换成了Http(s)协议,并不复杂。但是这一转换,却带来了许多收益:


  • 解决域名解析异常:用户使用Http(s)协议向魅族GSLB服务发起域名解析请求,绕过了运营商的LocalDNS,用户在客户端的域名解析请求将不会遭受到域名解析异常的困扰,有效预防DNS劫持。

  • 用户就近访问:GSLB能直接获取到用户IP,结合魅族自有IP地址库以及测速机制,可以为用户搜索最优的IDC服务节点。

  • 实现精准流量调度:流量异常(周年庆推广活动)或机房故障时,方便快捷的将流量平滑的调度到附近的机房,保障服务的高可用性。


下载防劫持


运营商HTTP劫持推送广告的情况相信大家并不陌生,近来国内各大应用分发平台都有不同的程度的应用下载被劫持现象,我们也难置身事外,为此,我们上线文件下载防劫持方案。


如下图所示。应用商店在分发应用时,会同时分发应用文件的摘要等相关信息,客户端下载获取到应用文件(Apk)后,会计算并比对文件的摘要,以此来判别文件是否被修改或替换。如果文件比对失败,则更换为HTTPS通道继续下载应用。为防止CDN与源站的网络被劫持,CDN回源前后也会校验文件信息。



除了比对应用文件的摘要,我们还会比对文件的大小、包名(Android应用的唯一标识)、版本号等信息。针对APK下载场景,生产环境我们主要使用文件大小和包名来做校验。


有些游戏应用文件比较大,如热门游戏《植物大战僵尸》大小在100M左右、热门网络游戏《梦幻西游》大小在300M左右。如果全量计算文件摘要这样会比较耗时、耗资源,对硬件资源有限的手机来说是一笔很大的开销,势必会影响到用户的操作体验。为此,针对大文件,我们采用了部分比对文件摘要的方式。


应用商店应用数量大、渠道不单一,为了预防分发信息异常造成大面积应用下载失败事故,云端新增了动态关闭、调整客户端判别逻辑的机制。


无论劫持动作是否成功修复,客户端均会上报操作日志,借助大数据的优势,我们可以分析改进防劫持效果。




AS倒计时

InfoQ主办为期两天的ArchSummit北京2015全球架构师峰会下周五、六[12.18-12.19]将于国家会议中心与大家见面,14大专题,70余位讲师集中两天放送,以下为讲师专访回顾,戳“阅读原文”查看大会日程。

讲师专访回顾 [点标题直接阅读]



查看日程戳“阅读原文”👇

 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 Java进阶系列(一)Java Annotation(注解) 前端模板开发大赛,赢iPhone 6s得高薪 程序员王牌挑战赛,约吗? 『独家干货 』Android应用函数级性能分析方案 用vue简单实现知乎日报