1.设计app架构：

1.梳理app业务流程
2.整理业务流程可能遇到的问题
3.根据问题，探讨可执行的解决方案
4.把3中所有技术进行有机融合，就是app后台的初步架构

api编写：
1.api的作用（功能）
2.api需要输入的参数
3.api返回的数据

2.服务器选择

1.传统的IDC
在传统的IDC，要加cpu或内存，流程如下:
　　1.和客户经理商商谈所需硬件的价格
　　2.汇款过去，等IDC的财务确认
　　3.确认后，等待IDC安排工作人员升级硬件
　　这个流程走一次，最少也要1至2天。延迟了1至2天升级硬件，怎么保证可以快速应付爆发的业务

2.云服务器
升级硬件:
1.在用户后台选择需要的硬件配置
　　2.通过网络支付
　　3.重启服务器，升级就完成了。如果只是升级带宽，甚至不用重启。
　　整个过程合起来不用5分钟，简单，快捷，方便。
　　而且，现在的云服务器提供商，出了服务器外，还提供下面的服务：
　　负载均衡
　　云数据库
　　云内存存储
　　这些服务在app上线初期，在一台服务器上自己搭建就行了，但随着app的发展，这些服务都需要部署在不同的服务器。
　　规模的增大，也要面对高可用，高并发，监控报警等问题。这些问题如果都要后端人员处理，那要疯了，后端就那么一两个人，既要保证平时的开发任务，又要做复杂的运维管理。后端人员也不是全能，一般后端人员是专注于开发，运维稍逊一筹。
　　这时，就能体会到云服务的优点，由云服务器的提供商来负责运维。高可用，高并发，监控报警这些都靠云服务器的提供商来保障，就能大大减轻运维方面的压力和人员的开支。

3.选择
在网络上经常被问到，需要选择什么样的服务器配置，这个问题，没法回答。这需要在综合考虑用户量，业务逻辑综合考虑的。
给个建议，最初硬件配置可以差点，随时监控主机，发现负载高了，才升级硬件配置也不迟

3.app后台

1.app后台要慎重考虑网络传输流量，主要做api设计，图片处理上
2.移动手机弱网络环境
3.手机电量有限

4.app流程

1.项目业务逻辑
2.产品原型
3.UI效果图
4.研发阶段

* api设计
* api提供测试数据供前端开发
* 开发页面及初级架构设计
* 后端实现api接口功能

5.测试反馈

* bug修改人员
* bug描述说明与重现步骤
* bug提交版本与bug提交人

6.市场推广与市场运营

* 潜在用户如何发现应用市场中的app？
* 怎么让用户了解app?
* 怎么让用户下载app?
* 怎么让用户使用app?怎样增加用户粘性?

5.项目开发管理

1.日常开发

* 开发计划
* 开发规范
* 保证开发的进度和效率

2.每日例会

* 昨天做了哪些事情，还有哪些没做，需要多长时间去完成
* 今天要做什么
* 有什么工作需要哪些人配合

3.测试和修复bug

* 可以交叉测试
* 问题描述和重现步骤
* 解决问题人员和提出问题人员

4.评审
使用评审整个app的功能及体验

6.app后台

1.api接口
从业务逻辑中提炼api接口

* 业务逻辑思维导图
* 功能-业务逻辑思维导图
* 基本功能模块关系

* 功能模块接口UML(设计出api)
* 在设计稿标记api
* 编写api文档

2.业务逻辑思维导图

* 用思维导图把结构关系列出来，包含里面的功能
* 把相同的元素整理出来，如相同的推送、评论、图片上传，然后用相同的颜色标起来

业务思维导图.png
功能-业务逻辑导图.png
功能模块关系图.png
功能模块UML.png

3.api设计要点

* 根据对象设计api，而不是根据页面设计api（页面修改会影响到api更改，维护较难）
* api命名(望名而知api)
* api安全
* api返回数据(注意空值的处理，不然易造成app闪退)

app后台角度，api返回的数据中正确值和空值的类型必须一样，禁止返回null值;
app客户端，当api返回数据缺少某个数据时，app客户端自动补上这个数据并赋值；
数据库设计，所有字段都有默认值，不允许Null值；
产品中常用的null值需求是用Null表示数据未填写，如用“1”表示男性，“0”表示女性，Null表示用户未填写性别；

4.图片处理

* app客户端缓存图片，图片不存在，才通过api获取图片;
* 当app客户端需要某种尺寸的图片，由app客户端通知服务器所需要的尺寸，由服务器动态生成并缓存；

app后台数据库只保存原图，需要什么尺寸，动态生成；

5.返回提示信息

* 提示用户信息
* 提示程序员信息，参数问题，格式问题

7.数据库选择

1.MySQL、Redis、MongoDB读写数据区别
Redis是存放在服务器端内存中，内存用满之后需要扩容，就只能使用Redis的分布式方案，为防止丢失，可调整Redis配置文件，按一定策略把数据持久化传到硬盘中。

MongoDB同时使用了硬盘和内存，其使用了操作系统提供的MMAP（内存文件映射）机制进行数据文件的读写，MMAP可以把文件直接映射到进程的内存空间中，这样文件就会在内存中有对应的地址，这时对文件的读写是可以操作内存进行的，而不需要传统的如fread、fwrite文件操作方式。

MySQL的数据放在硬盘中，MySQL的缓存是查询的结果，而不是缓存数据。

2.MySQL、Redis、MongoDB查找数据的区别
Redis的数据基于“键值对”存储，查找数据，直奔主题，读写速度快。

MongoDB和MySQL，每组数据都有一个id（或者可以为每组数据建立索引），查找数据分两种，知道id或索引，不知道id或索引，前者效率高，后者效率低。

3.MySQL、Redis、MongoDB查找数据的区别
Redis数据只存放在服务器端内存中，由于内存价格高，所以内存存储数据成本高，app后台开发中，读写频率高的数据一般放在Redis中（当然这部分数据也可放在MySQL或MongoDSB中，Redis中国的数据是以缓存的形式存在的，数据更新时，两部分数据都要更新以保持数据统一性）。

MongoDB使用场景：
网站数据：MongoDB非常适合实时的插入、更新与查询，并具备网站实时数据存储所需要的复制及高度伸缩性；
大尺寸、低价值的数据；
高伸缩性的场景；
存储地理坐标的数据；

MongoDB不适用场景：
高度事物性的系统：如银行或会计系统，涉及金钱的操作不支持；
传统的商业智能应用；
需要SQL的问题：虽然MongoDB支持类似于SQL的查询，但它的查询比起MySQL来有一定的差距；

MySQL适用场景：
事物性的系统：如转账；
需要复杂的SQL问题；

8.消息队列

消息队列把大量的并发请求变成串行的请求，来减轻服务器的压力。
app后台中，发送邮件、发送短信、推送消息等任务都适合在消息队列中完成；

1.消息队列的流程

* 队列服务器
* 队列生产者
* 队列消费者

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

远层服务：
把重复实现的模块独立部署为远程服务，新增的业务调用远程服务所提供的功能实现相关的业务，不依赖于里面的具体实现代码。当远程业务发生变化时，只要接口传人的参数和返回值不变，就不会影响到调用远程服务的业务。

1.远层服务的实现

* REST
* RPC
* 开源的RPC库

2.常见的搜索软件

* Lucene
* Sold
* ElasticSearch
* Sphinx
* CoreSeek

3.定时任务

10.后台核心技术

1.用户验证方案

* api请求必须使用HTTPS协议

传统Web网站使用Cookie+Session保持用户登录状态；

2.app通信安全

* URL签名（改进：在传递参数中增加时间戳）
* AES对称加密

AES加密（data，secretKey）

app后台
* app后台用时间戳生成HTTP请求头Token-Param
* 取请求头Token-Param的22位长度作为secretKey
* 用AES算法把个人信息用密钥secretKey加密，在进行base64编码，用HTTPS返回给app

客户端
* 取HTTPS协议中HTTP请求头Token-Param的值的22位作为secretKey
* 把HTTPbody的数据先进行base64算法解码，用AES算法把解码后的数据用密钥secretKey解密，获取个人用户信息

3.更进一步的通信安全

* 使用自定义的通信协议传输敏感数据
* 使用RSA加强通信的安全性
* 涉及敏感信息（如支付密码），每次都需用户输入支付密码确认，支付密码永远不在app端保存
* 使用自主开发的输入控件输入敏感信息

4.短信服务

* 发送短信只能依靠第三方短信平台
* 短信的到达率和延时app后台无法控制

短信平台选择（价格，短信的到达率和延时），先试用，在选用！
为建立可靠的短信服务，app后台必须要接入最少两个短信平台，当前短信平台不可靠时，切换到另一个平台；

5.表情
Openfire中发送表情引起连接断开的问题
xmpp断开连接，是由Openfire中代码引起的，app后台加个codePoint判断即可；

6.高效更新数据
推拉结合和数据增量更新是实现高效获取数据的关键；

轮询：
典型的拉模式，每隔一段时间，app向app后台发送请求数据，耗网络流量，服务器压力大；

推模式：
当app后台有数据更新，通过推送系统通知app，当app收到这个数据更新的通知后在调用api获取相应的数据。

推模式.png

7.数据增量更新策略
使用app本地存储，需考虑数据增量大更新方案；
当app从服务器获取一次数据时，记录获取最新数据的update_time，当再次获取数据就只需要获取update_time到访问服务器这刻为止所更新的数据。

8.获取APK和IPA文件中的资源

11.文件系统

尽量使用成熟可靠的云服务和开源软件，自身只专注于业务逻辑；

架设文件系统涉及文件的分布式存储、图片水印、图片缩放、及CDN等方面，小团队可用第三方云存储平台；

1.分布式文件存储系统

* 扩容的时候，只需添加机器就能达到扩容效果，不需重启整个文件系统，甚至迁移文件
* 保证文件系统高可用、文件冗余备份，避免以某台机器宕机而造成文件服务停止

2.推荐使用FastDFS（开源的轻量级的分布式文件系统）
FastDFS对文件管理功能包过：文件存储、文件同步、文件访问等，解决了大容量存储和负载均衡的问题。
FastDFS的基本原理可类比生活中的仓库，有两大角色，跟踪器和存储节点，跟踪器就是仓库管理员，负责调度工作，在访问上起负载均衡的作用，存储节点就是货柜，工人就是向FastDFS存储文件的客户端；

3.图片水印、缩减和裁剪
推荐使用GraphicsMagick作为图片处理软件；支持多语言、多平台；

4.CDN
解决网络拥挤情况；
传统CDN服务商、阿里云、UCloud等提供CDN服务；
另外很多CDN服务商提供了图片水印、缩减、裁剪的功能，开发者可以直接使用；

5.ELK日志分析平台（分布式的日志收集和分析系统）

6.Docker构建一致的开发环境
Docker是一个用于统一开发和部署的轻量级容器，让开发者打包其应用及依赖包到另一个可移植的容器，发布该容器到其它机器，就能很容易的实现应用的部署。

12.app后台应用最广泛的系统

1.基本系统优化
app后台的Linux系统如果是采用默认安装或机房工作人员帮忙安装，运维人员需要对其进行优化，以获得更高的性能和安全性。

开启自动服务优化；

Linux的交换区：交换区是硬盘上的一块空间，在内存不足的情况下，操作系统先把内存中暂时不用的数据存储到硬盘的交换区，腾出内存来让别的程序运行。

阿里云服务器上的Linux系统是默认没有设置交换区（Swap），由于开启Swap分区会导致硬盘IO性能下降，因此阿里云服务器初始没有设置Swap，如需要开启Swap，可使用相应的命令开启。

2.故障案例分析

* 进程管理软件引起的最大连接数设置（修改限制）
* 占满磁盘空间引起网络无法登陆问题（可能是由bug日志过多占空间，修复bug后要注意清楚）

13.Nginx-app后台HTTP服务的利器

Nginx与Apache类似，其是一个高性能的HTTP和反向代理服务器，也是一个imop／pop3/smtp代理服务器。

Nginx高性能主要是使用了epoll和kqueue网络I／O模型，而Apache使用的是传统的select模型。

处理大量请求时，epoll模型远远大于select模型；
理解：select 模型处理（如客人进店点菜，服务员全程跟着）
epoll模型处理（如客人进店点菜，在需要的时候服务员才跟着）

http配置；

https配置：

生成证书：
* 缴费，到证书服务商申请
* 用户自己给自己颁发证书，即手动生成

location配置:主要针对静态网页；

sever虚拟机配置；

负载均衡配置：保证服务的高可用；

负载均衡.png

下载app配置：在浏览器下载；

性能统计：可开启Nginx的统计模块；

14.MySQL-app后台最常用的数据库

1.MySQL基本架构

• 服务层：大多数基于网络的客户端／服务端工具都有这一层，这一层主要处理连接和安全验证；
• 核心层：这层处理MySQL的核心业务；
  查询、分析、缓存和内置的函数
  内建的视图，存储过程，触发器
• 存储引擎层：存储引擎负责数据的存储和提取。

核心层通过存储引擎的API与存储引擎通信，这样就遮蔽了不同存储引擎的差异，使得这些差异对上层查询是透明的。
存储引擎之间不会相互通信，只是简单的响应上层查询。

建议选择MySQL社区版，足够业务需求；

2.软件优化

1.正确使用MyISAM和InnoDB存储引擎
MyISAM和InnoDB存储引擎是MySQL最常用的存储引擎；

• MyISAM基于ISAM（索引顺序访问方法），支持全文索引，但并非是事物安全，不支持外建，使用表级锁。每个MyISAM存3个文件：FRM文件存放表结构，MYD文件存放数据，MYI存放索引。

• InnoDB是事务型存储引擎，其支持行锁，InnoDB的行锁也不是绝对的，如果他在执行一个更新的语句是没法确定更新的范围，也会锁表。InnoDB支持回滚、崩溃恢复、ACID事物控制，InnoDB存储他的表和索引在一张表空间，表空间可包含多个文件。
  支持外建，是事务安全型的；

2.正确使用索引

* 给合适的列建索引
* 索引列的值尽不相同
* 使用短索引
* 利用最左前缀
* 使用like查询时索引会失效，尽量少使用like查询
* 不能滥用索引

3.避免使用select*

• “select*”从数据库中返回的数据更多，降低了查询速度；
• 过多的返回结果会增大服务器反给app端的数据的传输，网络不好的情况下，过大的传输会造成请求失败；

4.建议数据库上所有字段都设置为NOTNULL，必须有默认值；

3.硬件优化

1.增加物理内存
2.增加应用缓存
3.用固态硬盘代替机械硬盘
4.SSD硬盘+SATA硬盘混合存储方案

4.架构优化

1.分表
项目用户增长，数据庞大，就要分表：将大表拆分为多个子表，在更新或查询数据的时候，压力会分散到不同的表上。由于分表之后，每张表的数据变小，查询或更新会有很好的提升；

• 水平拆分：把一张表的数据分别保存在不同的表中；
• 垂直拆分：把一张表的字段保存在不同的表中；

2.数据库优化
使用数据库读写分离策略；
读写分离是把对数据库的读和写操作分开对应于主／从数据库服务器；

读写分离架构.png

3.分库
数据规模变大，当读写分离也不能满足系统性能要求的时候要考虑分库，分库即把不同的数据表部署在数据库集群上；

MyCat部署.png

4.SQL慢查询分析
SQL慢查询是指超过一定时间的SQL查询语句，把这些语句记录到查询日志，以便分析其原因，以进行优化。

5.云数据库

* 配置高性能的SSD硬盘
* 备份机制
* 完善的监控体系
* 弹性扩展

15.Redis-app后台高性能的缓存系统

1.Redis

业务场景需求：

* 少量数据被经常读写，同时对读写速度要求非常高；
* 能提供丰富的数据结构
* 提供数据落地的功能

Redis就是满足上面需求的开源Key-Value内存存储系统；
特点：

* 全部的数据操作在内存，保证了高速的读写速度
* 提供丰富的数据类型，string、hash、list、set、sorted set、bitmap、hyperloglog
* 提供了AOF和RDB两种数据的持久化方式，保证了Redis重启后数据不丢失
* Redis所有操作都是原子性，同时Redis还支持对几个操作合并后的原子性操作，也即支持事务

2.Redis常用数据结构及应用场景

2.1string-存储简单的数据

特点：
* 可接受任何格式的二进制数据
* 是基本的Key-Value结构

场景：
* 可存储大量数据，app后台该类型经常被用来缓存数据
* 页面：访问频率高，数据不经常变动（可能几天）

缓存不常变数据.png

2.2hash-存储对象的数据

特点：
* hash的key是唯一值，value部分是个hashmap结构

场景：
* 根据用户id获取用户信息

2.3list-模拟队列操作

特点：
* list是按照插入顺序排序的字符串链表，可在头部和尾部插入新元素
* 链表中间插入效率低，首位插入效率高

场景：
* Redis被用来作为消息队列

如短信发送：

短信发送.png

2.4set-无序且不重复的元素集合

特点：
* set类型可以看作是没有排序、不重复的元素集合，可以在类型上添加、删除或判断某一元素存在等操作

场景：
* 如社交中的共同好友

2.5sorted set – 有序且不重复的元素集合

特点：
* 和set 类似，不容许成员重复

场景：
* 各种类型的排行榜（如人气排行）

3.内存优化

3.1监控内存使用情况（命令redis-cli info）

3.2优化存储结构

* hash存储，当hashmap成员达到不同数时，采用不同的形式存储数据（<512用ziplist存储，>512用hashmap存储;）,hashmap成员长度（<64用ziplist存储，>64用hashmap存储）
* set使用了intest的结构来节省内存

3.3限制使用的最大内存

• 设置maxmemory的参数来限制Redis使用的物理内存
• 当Redis使用的内存达到了限制值，任何write操作会触发“数据清除策略”，配置文件“maxmemory-policy”来采用特定的“数据清除策略”

3.4设置过期时间
可设置Key超时时间（命令EXPIRE key seconds）
超过超时时间后，删除不用的Key及数据，达到内存优化；

删除：
* 惰性删除(发现key过期就删除)
* 定期删除（定期检查，有过期的删除）

4.集群

4.1客户端分片
4.2Twemproxy

Twemproxy.png

优劣.png

4.3Codis

Codis.png

4.4Redios3.0集群采用了p2p模式，完全去中心化

4.5云服务器上的集群服务

* 动态扩容
* 数据多备（数据保存在一主一备两台机器中）
* 自动容灾

4.6持久化
Redis是一个支持持久化操作的内存数据库，通过持久化机制把内存中的数据保存在硬盘文件。当Redis重启后通过把硬盘文件重新加载到内存，就能达到恢复数据目的。

* RDB(按照一定的时间周期策略把内存的数据以快照的形式写入到硬盘的二进制文件)
* AOF（通过write函数追加到持久文件中）

4.7故障排除
查看Redis错误日志；

16.MongoDB-app后台新兴的数据库

1.MongoDB

* 一种非关系型数据库
* 支持的数据结构非常松散，数据采用bson格式，可存储比较复杂的数据类型
* 读写性能高
* 水平扩展机制

高性能（MMAP和Journal日志）
* MMAP（内存文件映射）
* Journal日志（所有数据更新操作都会记录并保存在该日志中）

* MongoDB把关系模型转变为文档模型
* 可进行数组操作、文档操作

2.高可集用群

2.1主从
MongoDB采用双机主从备份，主节点的数据会自动同步到从节点，当主节点宕机后，切换到从节点继续提供服务。

主从.png

2.2副本集
副本集使用多台机器做同一份数据的同步和异步，从而使多台服务器拥有同一份数据的多个副本。一台服务器作为主节点提供写入服务，多台服务器作为副本节点提供读取服务，实现读写分离和负载均衡。当主节点宕机后，可把副本节点提为主节点或将其他节点改为主节点，继续服务。

副本集.png

2.3分片
集群中大量的数据读写请求分散到多个集群处理，在MySQL中称为数据库分片；

2.4.LBS- 地理位置查询

2.5MongoDB3.0

* 灵活的存储架构（引入插件式存储引擎api）
* 性能提升7-10倍
* 存储空间最多减少80%（新增WiredTiger存储引擎，支持集合数据压缩）
* 运维成本降低95%

17.app后台架构剖析

1.聊天app后台架构

1.1移动互联网的网络特性

* 弱网络性
心跳机制防止TCP half-open（客户端断开连接，服务器以为仍和app保持连接）
* 对流量敏感

1.2协议

* XMPP
* MQTT
* ActivitySync

基于队列的消息协议

* 传统的IM协议一般是基于队列的消息发送和反馈机制

基于队列消息协议.png

基于版本号的消息协议

基于版本号的协议.png

1.3文件发送

文件发送.png

1.4聊天架构

聊天架构.png

连接层:
* 与app保持连接
* 把消息通过队列转发到逻辑层处理

业务层(处理业务逻辑):
* 验证模块（验证用户身份信息）
* 路由模块（路由获取用户所在服务器，如实现群聊功能） 
* 统计模块（统计各种信息，如连接数、每秒发送消息数、每个端端连接数）
* 数据存储模块（存储消息、统计信息、用户身份信息等）

持久层：
* 提供数据存储服务

流程：

聊天后台流程.png

2.社交app后台架构

社交的核心功能是Feed；

2.1基本表结构
常见的Feed架构就是把数据存储在MySQL中，热点数据（一般说最近3天数据）存储在缓存（常见的缓存有Redis和Memcached，微博用的Memcached），务必让绝大数请求通过缓存直接返回，只有少量的请求穿透缓存落到数据库。

2.2推拉模式

推模式：
* 推送给粉丝（同时推送很多人，延迟严重，浪费存储空间）
* 一个SQL可完成（显示Feed）
* 变更成本高 （如删除某一条内容）

拉模式：
* 采用了时间换空间的策略
* 不推送
* 需要大量的聚合运算（显示Feed）
* 没有变更成本

微博中公开的微博采用了拉模式，私密性微博采用了推模式；

2.3数据库的架构演进
单机部署 ——> 读写分离，从一主一从到一主多从——>分表分库

2.4社交app后台数据库在业务层实现分表分库的方案

数据库自增id
* 生成id算法

分表分库策略
* 按hash拆分（适用于数据分表分库前中期）
* 按时间拆分
* 综合使用拆分

hash拆分.png
时间拆分.png

2.5缓存架构的演进
分布式缓存

分布式缓存.png

主从缓存结构

主从缓存.png

2.6防止缓存实效的措施

* 定期把主缓存的数据同步到从缓存
* 应用层控制请求有一定的概率落在从缓存，让从缓存承担部分请求，使从缓存的数据不过冷

3.LBS-app后台架构

3.1地理坐标
获取

* GPS：精度高，初始化搜索卫星的速度慢，耗电
* 基站：速度快、精度低，不同运营商的基站定位差别大
* AGPS：GPS+基站的结合
* WiFi定位：通过服务商收集的Wi-Fi数据定位，但WiFi的地理信息更新慢

app端建议使用地图SDK，后台注意坐标偏移问题；

处理

* MySQL的空间数据库(把地理坐标的数据当成一种独立的数据类型)
* geohash（geohash编码就是把地理坐标变换成一个值（字符串））
* MongoDB封装了大量地理位置操作 

3.2基于MongoDB的LBS后台架构演进
副本集架构——>分片架构

副本集架构

* 保证高可用

MongoDB副本集架构.png

分片架构

* 每个分片都是副本集架构

4.推送服务器的后台架构

4.1Android推送
由于android系统没有限制，当app进入后台也能运行服务，所以android可以基于长连接作推送；

app连接推送服务器流程：

后台推送消息到app流程：

后台推送消息到app.png

app获取离线消息流程：

app获取离线消息.png

4.2iOS推送
APNS原理：

APNS原理.png

18.app后台架构的演进

app后台架构核心：

* 高可用
* 高性能
* 安全性
* 可扩展
* 可伸缩

app发送请求后台运行：

app请求后台运行.png

1.高性能

app层：

app层.png

网络传输层：

网络传输层.png

应用服务层：

文件服务层.png

文件服务层：

应用服务层.png

缓存层：

缓存层.png

数据库层：

数据库层.png

2.高可用

应用服务器高可用原理.png

宕机后的负载均衡：

宕机.png

高可用备份：

备份.png

数据服务器宕机：

数据服务器宕机.png

3.开发服务器、工具

开发.png
开发2.png

4.架构演进

4.1单机部署
app后台极简化架构：

app后台极简化架构.png

* 加入ULB(UCloud的负载均衡ULB是免费的)
* 一开始使用Redis（既能当缓存，又能当队列服务，并发性能高，适用于初期项目）
* 架构中不包含文件服务（运维成本高）

4.2分布式部署

分布式部署.png

4.3架构拆分

架构拆分.png

业务平稳期：

业务平稳期.png
orange.png