转载请注明出处：http://blog.csdn.net/smartbetter/article/details/53933096

做App做的久了，就想研究一下与之相关的App后台，发现也是蛮有趣的。App后台的两个重要作用就是 远程存储数据 和 消息中转。这里面的知识体系也是相当复杂，做好一个App后台也是需要长期锤炼的。本篇文章从 App 后台架构 的角度介绍。好了，下面进入正题：

说起架构，我们先看一下何为架构，百度百科是这样说的：架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。那么我们也可以看出，架构是和业务紧密相关的，是由业务驱动的。

由于App客户端的特性，因此App后台对技术实现和一般的Web后台是有区别的。首先看一个适合App开发的开发模式：

1.敏捷开发模式

这里推荐Scrum这个敏捷开发框架，具体可以查看Scrum官网学习使用，这里只是引入。

Scrum流程如下图：

2.选择合适的数据库产品和服务器系统

数据库产品众多，这里我就针对Redis、MongoDB、MySQL还有MySQL的分支MariaDB展开说明：

1.数据库产品

然后根据不同的产品需求选择恰当的数据库产品，如果没有特殊的需求，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 则是一个不错的选择。关于服务器的部署，我在之前已经介绍过了，地址如下：

Nginx + Tomcat 反向代理 负载均衡 集群 部署指南
http://blog.csdn.net/smartbetter/article/details/53535435

Nginx + Tomcat 反向代理 如何在高效的在一台服务器部署多个站点
http://blog.csdn.net/smartbetter/article/details/53615313

下面补充两个常见的Linux命令：

top           显示系统资源情况
netstat       查看网络相关信息

3.选择合适的消息队列软件

当后台系统发现完成某些小任务需要花费很多时间，而且迟点晚成也不影响整个任务的完成进度时，就会把这些小任务交给消息队列。例如发送邮件、短信、推送消息等任务都非常适合在消息队列中处理。

把这些任务放在消息队列中，可加快App后台请求都响应时间。同时消息队列也能把大量的并发请求变成串行的请求，来减轻服务器的负担。

常见的消息队列软件有：

4.使用分布式服务实现业务的复用

随着业务不断增加，后台系统由一个单一应用膨胀为一个巨无霸系统，系统中聚合了大量的应用和服务，各个模块之间有很多功能重复实现（例如登录模块），造成了开发、运维、部署的麻烦。

大量应用中的重复模块会带来大量的访问，而每个应用与数据库的连接，一般是使用数据库的连接池，这个连接池的资源一般是不释放且一直保留着。假设连接池中有10个连接，中一个数百的服务器集群中，就占用了数据库1000个连接。数据库中的每个连接都是十分珍贵的资源，在资源有限的情况下，这里被占用了，其他能用的资源就少了。

解决这些问题的方法就是把重复实现的模块独立部署为远程服务，新增的业务调用远程服务所提供的功能实现相关的业务，不依赖于里面具体的代码实现。

实现远程服务可以 参考 REST设计原则 和 RPC远程调用协议。

开源的RPC库有：

5.用户验证方案最佳实践

App操作中经常涉及用户登录操作，登录就需要使用到用户名和密码，为了安全起见，在登录过程中暴漏密码的次数越少越好。

1.使用HTTPS协议

HTTPS协议是 HTTP协议 和 SSL／TLS协议 的组合。其是一个安全通信通道，基于HTTP开发，用于在客户计算机和App后台之间交换信息。其使用安全套接字层（SSL）进行信息交换，简单来说就是HTTP的安全版。

HTTPS实际上应用了安全套接字层（SSL）作为HTTP应用层的子层。

HTTPS的模型：

避免信息的泄漏，最基本的方案是所有涉及安全性的API请求都必须使用HTTPS协议。

2.选择JSON作为数据交换格式

JSON是一种轻量级的数据交换格式，采用完全独立于语言的文本格式，易于编写，也易于机器解析和生成，而且对比XML更省流量，这些特性使得JSON成为理想的数据交换语言。

3.基本的用户验证方案

传统Web网站使用Cookie+Session保持用户的登录状态，App后台则使用token进行验证，流程如下：

此时App已经获取到了token值，为了安全，我们不在网络上传输token，而使用签名校验（这里使用URL签名）的方式，API请求加上URL签名sign和用户id后如下：

test.com/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.项目一定规模时——分布式部署

我们看一个百万级到千万级的架构：

这里新增了专门用于连接内部服务器的SSH服务的外网通道，保证SSH操作随时可用，同时加入了服务器集群，提供负载能力。

随着业务的发展，某些数据表的规模会以几何级增长，当数据达到一定规模时，查询读取性能就下降的厉害，数据库主从的架构不能应对业务上的读写压力，这时架构上要考虑分表（水平拆分／垂直拆分）。

当业务继续不断发展，数据库分表后的读写性能也可能没法满足业务上的需求，这时只能采用进一步的拆分策略——分库。用 Cobar 或者 MyCat 等关系型数据等分布式处理系统后，分库后的架构如下：

下来看一个真实社交App项目所采用的后台架构方案：

7.社交App后台架构设计方案分享

场景：类似 微博，用户与用户之间存在关注／粉丝两种关系，一个用户发表了新内容，关注他的用户也能在个人主页上收到最新的动态。类似 微博 这种场景：

社交核心功能是 Feed（指用户通过关注，聚合了被关注用户的最新的内容，也包含自己的内容，以供自己浏览的信息服务）。

1.Feed基本表结构

常见的Feed架构是把数据存储在MySQL，热点数据存储（一般最近3天）在缓存（Redis／Memcached），保证绝大多数请求通过缓存直接返回，只有少量请求穿透缓存落到数据库。

下面看一下最简单的Feed表结构：

send_content：发送内容表，存储用户发表的内容：

reveive_content：接收内容表，用于推模式时存储用户接收的内容：

followings：关注表，存储用户关注的人：

followers：粉丝表，存储用户的粉丝：

2.Feed推拉模式——推模式用户发表一条内容的流程

1）uid为1的用户发表一条内容 “HelloWorld” 信息。
2）这条内容写入发送内容表 “send_content” 后内容如下：

3）在粉丝表 “followers” 查找uid为1用户的粉丝，粉丝表 “followers” 的内容如下：

可知，id为1用户的粉丝是id为2的用户。

4）因为id为2的用户的feed中需要显示这条内容，因此把内容写入接收内容表 “reveive_content”，写入后接受内容表 “reveive_content” 内容如下：

5）当id为2的用户显示feed时，通过sql语句 “select * from reveive_content where reveive_id=2” 就能查询该用户需要显示的数据了。

推模式的缺点是：

推送人数过大会出现延时，而且浪费存储空间；
更新操作成本大，不但变更 “send_content” 表，而且需要同步变更 “reveive_content” 表。

3.Feed推拉模式——拉模式用户发表一条内容的流程：

1）uid为5的用户发表一条内容 “Thinks” 信息。
2）这条内容写入发送内容表 “send_content” 后内容如下：

3）当uid为10的用户显示feed时，在关注表 “followings” 查找uid为10所关注的用户，关注表如下：

可知，uid为10的用户关注了uid为5的用户，因此需要获取uid为5的用户发表的内容。

4）uid为5的用户通过sql语句 “select * from send_content where author_id in (5)” 查询所以需要显示的内容。

由上述可知，拉模式采用了时间换空间的策略，用户推送内容时效率很高，但当用户显示feed时，需要花费大量的时间在聚合运算上。

总结：

像 “微博” 中公开的微博采用拉模式，私密性的微博采用推模式。

拉模式最大的问题就是大量的聚合运算，请求的响应时间可能较长，可以通过缓存策略让大部分的请求的响应时间达到2到3毫秒。

8.其他的一些经验

1.高效更新数据——内容的推拉

平常App设计中，如果App需要知道首页是否有内容更新，通过一个轮询机制访问获取数据API，从API是否返回更新的数据得知是否有内容更新，轮询上很典型的拉模式，但是耗电、耗流量。

怎么减少轮询呢？ 这里给出解决方案是推模式，如下图：

当然不能只用推模式，因为手机环境的复杂性，不能保证数据更新的通知一定能够到达App，所以也要采用轮询的方式定期拉数据，时间间隔设置可以相对长一点，通过这种推拉结合的模式，就能大大减少App访问App后台的频率和传输的数据量。

2.处理表情的一些技巧

表情在MySQL的存储，表情UTF-8编码有的是3个字节，有的是4个字节，所以一般的UTF编码（3个字节）是无法存储表情数据的，常用的解决方案是：

把MySQL升级到5.5以上，然后把字符编码改为utf8mb4_general_ci。

3.可供选择的成熟稳定的开源软件

3.可供选择的成熟可靠的云服务

对于初创公司还是建议尽可能的使用成熟可靠的云服务和开源软件，自身只专注于业务逻辑。

最后，在移动互联网项目中，产品的研发讲求 小步快走，快速迭代。 架构的设计也可以遵循同样的思路，喜欢本文的记得 顶 一下哦！