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

本文系魅族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