转载

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

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

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

水平分层、垂直拓展

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

帮助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、实现精准流量调度：流量异常（周年庆推广活动）或机房故障时，方便快捷的将流量平滑的调度到附近的机房，保障服务的高可用性。