背景：2014年9月4日，魅族科技今日与戴尔签署合作备忘录，双方将建立长期战略合作伙伴关系，致力于加速魅族移动互联网基础建设，同时协助魅族搭建内部私有云。这一举动，也体现了戴尔对中国高端手机制造业的支持。 魅族云服务的优势在于系统级别整合、权限智能分配、一站式帐号管理，这也对互联网整体解决方案提出了更高的要求，并面临更多难点。此次合作的建立标志着魅族又一次与国际顶尖信息技术供应商的接轨，业界更佳期待戴尔发挥其解决方案优势，全力帮助魅族加速其云架构建设，实现更大的成功。

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

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

水平分层、垂直拓展

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

帮助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左右。如果全量计算文件摘要这样会比较耗时、耗资源，对硬件资源有限的手机来说是一笔很大的开销，势必会影响到用户的操作体验。为此，针对大文件，我们采用了部分比对文件摘要的方式。

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

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