App后台架构设计⽅案设计思想与最佳实践
做App做的久了，就想研究⼀下与之相关的App后台，发现也是蛮有趣的。App后台的两个重要作⽤就是远程存储数据和消息中转。这⾥⾯的知识体系也是相当复杂，做好⼀个App后台也是需要长期锤炼的。本篇⽂章从 App 后台的⾓度介绍。好了，下⾯进⼊正题：
说起架构，我们先看⼀下何为架构，百度百科是这样说的：架构，⼜名软件架构，是有关软件整体结构与组件的抽象描述，⽤于指导⼤型软件系统各个⽅⾯的设计。那么我们也可以看出，架构是和业务紧密相关的，是由业务驱动的。
由于App客户端的特性，因此App后台对技术实现和⼀般的Web后台是有区别的。⾸先看⼀个适合App开发的开发模式：
1.敏捷开发模式
这⾥推荐Scrum这个开发框架，具体可以查看Scrum官⽹学习使⽤，这⾥只是引⼊。
Scrum流程如下图：
2.选择合适的数据库产品和服务器系统
产品众多，这⾥我就针对、、还有MySQL的分⽀MariaDB展开说明：
1.数据库产品
数据库数据存放位置查数据的区别
Redis内存基于键值对存储，读写速度快
MongoDB同时使⽤了硬盘和内存每个数据有⼀个id（索引），知道id（索引）查询速度快，不知道id（索引）效率低
MySQL（MongoDB）硬盘每个数据有⼀个id（索引），知道id（索引）查询速度快，不知道id（索引）
效率低
然后根据不同的产品需求选择恰当的数据库产品，如果没有特殊的需求，Redis做缓存系统，MySQL 或 MariaDB 做数据库（常见的设置是数据库默认字符集utf8，默认排序utf8_general_ci）将会是很好的选择。
软件优化：
1）正确使⽤MyISAM和InnoDB存储引擎
2）正确使⽤索引
3）避免使⽤ select *
4）字段尽可能的设置⾮NULL
硬件优化：
1）增加物理内存
2）增加应⽤缓存
3）使⽤SSD硬盘
架构优化：
1）分表
2）读写分离
3）分库（把⼀张表的数据分别存储在不同的数据库，可⽤MyCat实现，MyCat，关系型数据库分布式处理软件）。
MyCat以代理服务器的形式位于App服务器和后台数据库之间，
对外开放的接⼝是MySQL通信协议，将App服务器传过来的sql语句按照路由的规则拆解转发到不同的后台数据库，并把结果汇总返回。
MyCat部署模型如下：
2.服务器系统
CentOS 则是⼀个不错的选择。关于服务器的部署，我在之前已经介绍过了，地址如下：
下⾯补充两个常见的命令：
top          显⽰系统资源情况
netstat      查看⽹络相关信息
3.选择合适的消息队列软件
当后台系统发现完成某些⼩任务需要花费很多时间，⽽且迟点晚成也不影响整个任务的完成进度时，就会把这些⼩任务交给消息队列。例如发送邮件、短信、推送消息等任务都⾮常适合在消息队列中处理。
把这些任务放在消息队列中，可加快App后台请求都响应时间。同时消息队列也能把⼤量的并发请求变成串⾏的请求，来减轻服务器的负担。
常见的消息队列软件有：
消息队列软件说明
RabbitMQ重量级，适合企业级的开发，⾃带Web监控界⾯，⽅便监控队列的情况
Redis轻量级，是⼀个key-value系统，但是也⽀持消息队列这种数据结构，App后台中Redis被⼴泛使⽤
ZeroMQ号称最快，尤其针对⼤吞吐量的需求场景
ActiveMQ Apache的⼀个⼦项⽬，能够以代理⼈和点对点的技术实现队列
4.使⽤分布式服务实现业务的复⽤
随着业务不断增加，后台系统由⼀个单⼀应⽤膨胀为⼀个巨⽆霸系统，系统中聚合了⼤量的应⽤和服务，各个模块之间有很多功能重复实现（例如登录模块），造成了开发、运维、部署的⿇烦。
⼤量应⽤中的重复模块会带来⼤量的访问，⽽每个应⽤与数据库的连接，⼀般是使⽤数据库的连接池，这个连接池的资源⼀般是不释放且⼀直保留着。假设连接池中有10个连接，中⼀个数百的服务器集中，就占⽤了数据库1000个连接。数据库中的每个连接都是⼗分珍贵的资源，在资源有限的情况下，这⾥被占⽤了，其他能⽤的资源就少了。
解决这些问题的⽅法就是把重复实现的模块独⽴部署为远程服务，新增的业务调⽤远程服务所提供的功能实现相关的业务，不依赖于⾥⾯具体的代码实现。
实现远程服务可以参考 REST设计原则和 RPC远程调⽤协议。
开源的RPC库有：
开源的RPC库说明
Hprose轻量级、跨语⾔、跨平台、⽆侵⼊式、⾼性能动态远程对象调⽤引擎库
Dubbo分布式服务框架，致⼒于提供⾼性能和透明化的RPC远程调⽤服务和SOA服务治理⽅案
5.⽤户验证⽅案最佳实践
App操作中经常涉及⽤户登录操作，登录就需要使⽤到⽤户名和密码，为了安全起见，在登录过程中暴漏密码的次数越少越好。
1.使⽤HTTPS协议
HTTPS协议是 HTTP协议和 SSL／TLS协议的组合。其是⼀个安全通信通道，基于HTTP开发，⽤于在客户计算机和App后台之间交换信息。其使⽤安全套接字层（SSL）进⾏信息交换，简单来说就是HTTP的安全版。
url编码和utf8区别
HTTPS实际上应⽤了安全套接字层（SSL）作为HTTP应⽤层的⼦层。
HTTPS的模型：
HTTP
SSL／TLS（安全套接字层／传输层安全协议）
TCP
IP
⽹络传输
避免信息的泄漏，最基本的⽅案是所有涉及安全性的API请求都必须使⽤HTTPS协议。
2.选择JSON作为数据交换格式
JSON是⼀种轻量级的数据交换格式，采⽤完全独⽴于语⾔的⽂本格式，易于编写，也易于机器解析和⽣成，⽽且对⽐XML更省流量，这些特性使得JSON成为理想的数据交换语⾔。
3.基本的⽤户验证⽅案
传统Web⽹站使⽤Cookie+Session保持⽤户的登录状态，App后台则使⽤token进⾏验证，流程如下：
此时App已经获取到了token值，为了安全，我们不在⽹络上传输token，⽽使⽤签名校验（这⾥使⽤URL签名）的⽅式，API请求加上URL 签名sign和⽤户id后如下：
test/user/update?uid=2&sign=3f1e736bc4ae958ae7e8500b45aefdbb&age=22
这样，token就不需要附在URL上了。App后台签名校验流程如下：
还有的童鞋喜欢设置时间戳，这样时间⼀长，URL就失效了，也是⼀种不错的进⼀步的优化⽅案。
建议：为了保障数据安全，这⾥建议同时使⽤ HTTPS 和签名校验。
6.App后台架构的演进原则
App后台的架构是由业务规模驱动⽽演进的，App后台是为业务服务的，App后台的价值在于能为业务提供其所需要的功能，不应过度设计。
从项⽬的⾓度，当App访问量不⼤时，应该快速搭建App后台，让App尽快上线给⽤户提供服务，验证商业模式的正确性，同时快速迭代产品。
当App访问量不断上升，这时要在保证快速迭代的前提下，同时兼顾⾼性能和⾼可⽤。
当App访问量达到⼀定阶段后，增长曲线就会放缓，但业务变得更加复杂，对⾼性能和⾼可⽤的要求也更⾼，性能问题、模块间的耦合、代码的复杂性会更加突出和明显，这时要使⽤业务拆分、分布式服务调⽤，甚⾄是技术转型等问题。
1.项⽬启动时——单机部署
我们看⼀个App后台极简化的架构：
⼀开始就使⽤Redis的好处：
既能⽤作缓存，⼜能充当队列服务，⽽且并发性能⾼，能在长时间内应对业务压⼒，⾮常适合初期的项⽬。
这⾥使⽤Redis验证⽤户信息，充当消息队列。
⽽⽂件服务初期可以选择⽂件云存储服务，或者⾃⼰搭建⼀个资源服务器。
2.项⽬⼀定规模时——分布式部署
我们看⼀个百万级到千万级的架构：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。