魅族应用商店云端架构实践-InfoQ

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

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

水平分层、垂直拓展

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

帮助 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 回源前后也会校验文件信息。