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

背景：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左右。如果整个计算文件摘要耗时耗资，对于*件资源有限的手机来说是一笔巨大的开支，必然会影响用户的操作体验。为此，对于大文件，我们采用了一些比较文件摘要的方法。应用商店应用数量大，渠道不单一。为了防止信息分发异常导致大面积应用下载失败，云增加了动态关闭和调整客户识别逻辑的机制。无论劫持动作是否成功修复，客户端都会报告操作日志。借助大数据的优势，我们可以分析和提高防劫持效果。

以上就是关于案例分享：云端架构助力魅族应用商店运维的相关介绍，更多案例分享：云端架构助力魅族应用商店运维相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对案例分享：云端架构助力魅族应用商店运维有更深的了解和认识。