开发APP在什么情况下架构需要分布式部署 ？
分布式部署阶段研发任务依然很重，架构特点是原有的单机部署架构已经不足以支撑业务的发展和高性能、高可用的要求，需要考虑某些组件独立部署、集群或分布式等架构方案，依然优先考虑云服务完成这些架构方案。在这个阶段，深圳APP开发公司规划整理架构演进如图10-15所示。
APP开发分布式架构部署示意10-15百万级到千万级架构图
在图10-15中，新增了专门用于连接内部服务器的ssh服务的外网通道，保证ssh操作随时可用。因为随着访问量的增大，ssh操作和普通的用户访问共用一个外网通道在访问量高峰期会出现一个问题：带宽给其他用户占满了，当运维人员需要通过ssh连接服务器根本连不上，就算运气好勉强连入服务器，因为带宽不足，输入一个命令，要好久才有反应，甚至隔会儿就中断一下。如果这时服务器出了什么问题需要运维人员连接服务器紧急排查，却因为带宽不足的原因而无法连接服务器，那就没办法处理问题。当然了，不一定只在这个阶段才需要新
增ssh通道，运维人员如果觉得有这个必要，也可以在前阶段就新增ssh通道。
同时使用多台应用服务器组成的应用服务器集群，通过负载均衡ULB把用户请求转发到集群中的应用服务器，提供整个集群应对高访问量的能力。如果有更大的访问量，就通过在应用服务器集群添加更多的服务器应对访问量的压力，使应用服务器的负载压力不再成为系统的瓶颈。负载均衡ULB的高可用由云服务提供商保证，应用服务器集群的架构就具备了高可用的特性。
为了保证Redis缓存扩容和保证足够的QPS，继续优先使用云内存存储UMem服务（兼容Redis协议），而不是考虑使用Twemproxy或Codis等需要大量运维成本的分布式缓存方案。云内存存储UMem能满足大多数应有的要求，内存空可可卧在0-500GB之句动态调整，1GB内存的最大QPS (query per second)为4000，若发现当前系统的QPS快到峰值，可通过升级内存提高QPS的上限。同时云内存存储UMem服务通过3个方面保证了高可用。
·数据实时保存到磁盘，防止机器重启后数据丢失。
·数据保存在主各两台机器中，任何台机器上磁盘损坏数据不会丢失。
·主机宕机，系统会自动将各机切换为主机，整个过程几秒内就能完成，无须人工干预队列服务可以继续选择Redis，减少运维成本．但如果需要更专业的队列服务．APP开发爱好者可以选择本站前面分享文章，常见的一些消息队列产品”一节中介绍的队列产品。
主从数据库，也是优先考虑使用云数据库UDB提供的功能搭建数据库主从架构，其原生就支持高性能和高可用，优点如下：
·数据库支持主从架构，确保线上数据安全。支持主库或从库备份及7天内多时间节点备份策略，保证灾备数据安全，让宝贵数据没有丢失的风险，减少了大量的运维成本，增加数据的安全性。
·支持使用SSD硬盘，针对SSD硬盘的多项硬件和软件优化，极大提供了数据库的读写能力。
随着业务的发展，某些数据表的规模会以几何级增长，当数据达到定规模的时候，查询、读取性能就下降得很厉害，数据库主从的架
构不能应对业务上的读写压力，这时架构上要考虑分表，分表有两种方法。
·水平拆分
·垂直拆分
当业务不断发展，数据库分表后的读写性能也可能没法满足业务上的需求，这时只能采用进一步的拆分策略：分库。用Cobar或MvCat等关系型数据的分布式处理系统后，分库的架构如图10-16所示。
APP开发架构分布式部署之数据库示意10-16分表分库的架构图
关于MvSQL的主从、分表、分库等优化策略，各位可查阅“本站APP开发知识栏目架构优化”一节。
如果数据库是使用MongoDB，则可以采用其原生的副本集、分片等优化策略，各位可查询“本站APP开发知识栏目高可用集群”
这个阶段的总结如下。
·开始考虑高性能和高可用，优先使用云服务商提供的基础组件来确保高性能和高可用，当云服务无法满足需求时，才考虑使用第三方开源软件。
·继续保持快速迭代速度。
好了，APP开发公司本文关于《开发APP在什么情况下架构需要分布式部署 ？》就分享到这里，谢谢关注，如有需要您可以在线联系我们客服获取专业解答。博纳网络编辑整理。
当前文章链接：/construction/appkaifa/1894.html
如果您觉得案例还不错请帮忙分享：
[声明]本网转载网络媒体稿件是为了传播更多的信息，此类稿件不代表本网观点，本网不承担此类稿件侵权行为的连带责任。故此，如果您发现本网站的内容侵犯了您的版权，请您的相关内容发至此邮箱【qin@198bona.com 】，我们在确认后，会立即删除，保证您的版权。
