案例分享：云端架构助力魅族应用商店运维

背景：2014年9月4日，魅族科技今天与戴尔签署了合作备忘录。双方将建立长期的战略合作伙伴关系，致力于加快魅族移动互联网基础设施建设，帮助魅族建立内部私有云。这一举动也反映了戴尔对中国高端手机制造业的支持。魅族云服务的优势在于系统级别集成、权限智能分配、一站式账户管理，这也对整个互联网解决方案提出了更高的要求，面临着更多的困难。合作的建立标志着魅族再次符合国际顶级信息技术供应商的标准。业界更期待戴尔充分发挥解决方案的优势，帮助魅族加快云架构建设，取得更大的成功。应用商店可以说是移动设备中最特殊的应用。它是移动操作系统的核心之一，用于分发和管理其他应用程序。然而，与操作系统的其他组件不同，它需要一个巨大的云作为支持。魅族应用商店是中国最早的应用分销平台，在中国开创了许多商业模式。魅族工程师将分享魅族应用商店云的整体结构。水平分层和垂直扩展应用商店首先位于应用管理平台，其次是应用分销平台。典型的业务场景包括：帮助Flyme用户找到应用程序；帮助Flyme开发者推广和分发应用程序；建立维护应用分销生态系统。根据业务场景，不难推断出业务结构的特点：多读少写；要求大，并发高；系统要求延迟低；数据规模可控；用户关联弱。随着用户规模的增长，当前平台的架构逐渐形成，不断重构、在线运营、探索和沉淀。如下图所示。横向、典型的三层结构；纵向、以业务为驱动，积累和沉淀了许多技术规范和基本组件，丰富和完善了全栈业务监控。依托完善的监控体系，衍生出相应的服务治理机制。早期的服务框架平台，规模小，结构简单。随着公司互联网的转型，用户规模快速增长，业务增加，平台关系复杂，扩展困难，开发效率低，原有架构无法为大型Flyme用户服务。为了减少业务依赖，提高集群效率，提高开发部署效率，我们基于典型的业务场景，模块化和单元化业务逻辑。应用管理和应用展示(列表)被拆分、应用推荐(个性化推荐)、多种服务，如应用搜索。服务分为两类，一类是基础服务，不依赖其他服务，业务逻辑简单，只提供应用管理服务等基本业务逻辑。另一种是聚合服务，它聚合了多种基本服务，形成了应用搜索服务等相对复杂的业务逻辑。成型服务框架可以满足远程呼叫、动态发现、负载平衡、监控等流行需求，必然会引入一些无关的功能，影响性能。此外，这些产品不能满足我们的定制需求，所以我们重复轮子。与以往的类似产品不同，我们做了以下改进：实时测量计算系统依赖于精细测量指标，自主研发的Kiev框架通信用于调用链无缝IT系统集成服务室。基于Netty网络框架的Kiev底层通信，序列化支持协议支持Hessian、Protobuffer等，支持跨语言（C/Java）通信协议支持TCP调用、UDP等。基于ZK的框架(ZooKeeper)实现了Highavailability和LoadBalance策略。服务调用时会采样，生成详细的调用链，收集，生成丰富的服务状态数据（ResponseTime,QPS），为服务治理提供了详细而有力的数据支持。消息队列（MetaQ）信息队列是分布式应用之间交换信息的一种技术。为了了解核心业务和辅助业务，我们引入了新闻队列，定期同步搜索团队和大数据团队所需的业务数据，并实时更新增量。既隔离了业务间的强耦合，又保证了数据的及时性。为了规范开发过程，便于问题跟踪定位，我们制定了统一的接口规范，接口规范多样，形式多样，管理维护成本高。例如，界面采用RESTful风格，统一界面返回形式，约定各业务层的错误代码，每个错误代码也携带可选的错误提示，便于跟踪问题。安全也是平台不可忽视的关键点。基于通用原则，我们采用行业通用OAuth协议，确保接口安全。为了应对异常流量对系统的影响，我们在接口层增加了流量控制功能。DB用于分布式缓存平台的早期阶段 本地缓存提供数据，DB压力大，接口吞吐量小，本地缓存更新不及时。为了解决这些问题，我们引入了分布式缓存Redis。业务接口数据全部缓存到Redis集群，缓存数据由定时任务主动刷新，零穿透，缓存即存储，存储即缓存。依靠Redis的高性能大大提高了系统吞吐量。Redis集群首先根据业务场景进行垂直切割，然后根据数据量进行水平分割。业务通过代理（Twemproxy）连接所有分片。基于ZK实现HARedis集群（HighAvailability），基于定制脚本实现在线自动扩展，既保证了缓存集群的高可用性，又满足了自动扩展集群容量的需要。随着用户规模的增长，单库单表已经不能满足业务需求。因此，我们将大量数据的用户数据库水平分割成多个数据库。为降低运维成本，采用单实例多数据库的部署模式。业务层通过分库路由组件透明访问数据库。当单实例多数据库模式无法支撑当前业务需求时，DB扩容可以通过更新路由规则顺利完成。GSLB(GlobalServerLoadBalance)使用域名提供服务的互联网企业不可避免地会遇到各种域名缓存、用户跨网访问缓慢等问题。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左右。如果整个计算文件摘要耗时耗资，对于*件资源有限的手机来说是一笔巨大的开支，必然会影响用户的操作体验。为此，对于大文件，我们采用了一些比较文件摘要的方法。应用商店应用数量大，渠道不单一。为了防止信息分发异常导致大面积应用下载失败，云增加了动态关闭和调整客户识别逻辑的机制。无论劫持动作是否成功修复，客户端都会报告操作日志。借助大数据的优势，我们可以分析和提高防劫持效果。