对话架构师:魅族应用商店云端架构实践

java 4 2016-02-29 13:03
女装

本文系魅族Flyme架构师胡成元,在Boss直聘主办的直聘学院「对话架构师」活动上的分享整理,介绍魅族应用商店云端架构实践的总结。

胡成元,Boss直聘「直聘学院」特邀分享嘉宾。2011年加入魅族,一直致力于移动应用架构研发,提升产品体验和研发效率。 目前主要负责魅族应用商店的研发工作,关注服务化、分布式、NoSQL、大数据等领域。

以下是分享实录整理:《 魅族应用商店云端架构实践 》

魅族应用商店作为国内最早的应用分发平台,积极探索,首创了许多新业务模式,比较典型的:应用内付费。受限于早期的封闭生态,其发展速度缓慢,这并不影响魅族人对技术架构的追寻与创新。

水平分层、垂直拓展
应用商店首先定位于应用管理平台,其次更是应用分发平台,其典型业务场景包括:
帮助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的原理非常简单,主要有两步:
A.客户端直接访问GSLB服务接口,获取业务在GSLB服务中配置的访问最优的IP。基于容灾考虑,我们保留了运营商LocalDNS域名解析的方式。
B.客户端获取到的业务服务IP后,直接向此IP发送业务协议请求。

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

A.解决域名解析异常:用户使用Http(s)协议向魅族GSLB服务发起域名解析请求,绕过了运营商的LocalDNS,用户在客户端的域名解析请求将不会遭受到域名解析异常的困扰,有效预防DNS劫持。
B.用户就近访问:GSLB能直接获取到用户IP,结合魅族自有IP地址库以及测速机制,可以为用户搜索最优的IDC服务节点。
C.实现精准流量调度:流量异常(周年庆推广活动)或机房故障时,方便快捷的将流量平滑的调度到附近的机房,保障服务的高可用性。

下载防劫持

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

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

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

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

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

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

[对话架构师] 是Boss直聘「直聘学院」旗下对话系列沙龙。联合业内明星创业公司&合作伙伴联合发起,为架构师、运维、程序员、开发者等举办的技术沙龙,旨在通过大咖干货分享,构建纯业内、纯技术交流圈,共同推动技术进步。此次活动参与对象主要是CTO,架构师,运维和技术经理等。
主办:Boss直聘(互联网招聘第一APP)
特别支持社区:SegmentFault

女装
文章评论