大型的App后台在面对海量用户的高并发访问量和海量数据的存储需求时．无论配置多么高级，一台服务器到了一定的阶段后总会没法满足需要，深圳APP开发公司认为这时就要考虑使用多台服务器提供服务。可伸缩是指通过往集群中添加机器，应付不断增大的访问压力和数据存储需求。
对于应用服务器而言，可伸缩性是指当访问量增大后，往集群中添加服务器。用户通过负载均衡设备分发请求到集群中的服务器，使每台服务器分担集群中不断增大的访问量。应用层实现可伸缩的前提是应用服务器是无状态的，即应用服务器不保存用户的信息，用户请求分发到任意一台服务器都是对等的。数据存储的可伸缩性分为文件数据的可伸缩性、缓存数据的可伸缩性、数据库的可伸缩性。
文件数据的可伸缩性，使用分布式文件存储软件很容易实现。以分布式文件存储软件Fastdfsh例，当发现集群中的文件容量快到瓶颈时，有下面两个方法可以增加集群的文件容量。
·在某台服务器上添加硬盘，就能给集群扩容。如果使用的是UCloud等云服务器，其提供了给云服务器添加云硬盘的服务，通过简单的几步操作就能把个新硬盘挂载到云服务器，无须停机，保证服务不停止。
·在集群中添加服务器，Fastdfs内部检测到新的服务器后，会把文件保存在新的服务器上。
缓存数据实现可伸缩．由于添加了新的服务器会导致之前的路由失效，造成大多数缓存都没法命中。虽然可以把数据重新加裁到缓存，但这段时间缓存失效会造成数据请求的压力直接达到相关的存储层，造成存储层压力过大甚至宕机。因此，可以通过改进的路由算法（例如一致性Hash算法）减少添加服务器造成的路由失效情况。缓存失效和致性Hash算法的详细描述，可查看本站前面所分享的缓存架构的演进”一节。
关于数据库的可伸缩性，分为关系型数据库和NoSQL数据库的可扩展性。
MvSQL使用分库可实现可伸缩性，但MySQL原生是不支持分库的。MySQL通过Amoeba和Cobar，或者是新兴起的MvCat等关系型数据库的分布式处理系统，就能实现分库。关于MySQL分库的详细描述，可查看本站前面相关经验介绍。
NoSQL数据库天生就是为了分布式存储没计的，很简单就能实现伸缩性。例如，NoSQL数据库MongoDB使用分片策略就能实现伸缩性。关于MongoDB分片功能的详细描述，可查看本站前面相关文章。
APP架构升级之可扩展
在移动互联网时代，App的一个重要特点是迭代的速度非常快，可能新的产品出来后，连用户从界面上部看不出是以前的那个App，App快速迭代的特点注定了需求是多变的，可扩展性就是关注在需求多变的情况下怎样对现在的架构影响最少。
可扩展性的核心是减少模块间的耦合度，每个模块都尽量少依赖其他模块，这样其中一个模块的变化对其他模块的影响减少。实现可扩展性有下面的3种方式。
·消息队列：生产者（某个业务模块）将消息放到消息队列，消费者（另外的业务模块）将消息从消息队列中取出来进行处理。通过动态增减消息，再加上消息的生产者和消费者分离的方法，就能降低模块间的耦合程度。
·分布式服务：把业务中可复用的模块抽离成个独立的服务，对其他模块提供可复用的服务，通过分布式服务框架供其他模块调用。新增的业务通过调用可复用的服务实现其需要的业务逻辑，减少了开发量。当可复用的服务需要改变其业务逻辑时，由于其他模块都是调用同一个可复用服务，可使代码的修改量减到最少。
·开放式API:从商业的角度来说，把自身的业务封装成开放式API供其他开发者调用，也是实现系统可扩展性的个重要方法。国外的Facebook、Twit ter，国内的淘宝、腾讯、微博等企业，大量的开发者基于其开放式API创建了海量应用，极大丰富了产品平台。
APP架构升级之安全性
安全性就是保证用户的核心数据不被非法人员盗窃。
国内外发生的多宗用户的核心数据泄露事件，给相关的App带来了极坏的影响，导致大量用户流失。
对于和金钱交易相关的App，安全性更为重要，如果因为安全问题造成用户的金钱损失，轻则用户流失，严重则会引起法律纠纷。好了，APP开发公司本文关于大型APP平台升级架构时需要注意哪些方面？的经验就分享到这里，希望能给您帮助，谢谢关注，博纳网络编辑整理。
当前文章链接：/construction/appkaifa/1863.html
如果您觉得案例还不错请帮忙分享：
[声明]本网转载网络媒体稿件是为了传播更多的信息，此类稿件不代表本网观点，本网不承担此类稿件侵权行为的连带责任。故此，如果您发现本网站的内容侵犯了您的版权，请您的相关内容发至此邮箱【qin@198bona.com 】，我们在确认后，会立即删除，保证您的版权。
