本书讲了什么

通过阐述移动互联网中App后台开发的特点，梳理了App后台开发中会遇到的各个技术点，给出了生产环境常用软件的实战运维经验总结。

作者什么来头

当当没写，我也懒得查。 曾健生

第1章 App后台入门

App后台的功能

远程存储数据。

消息中转。

App后台架构

梳理APP业务流程。

整理每个流程会遇到的问题。

根据问题，探讨可行的技术方案。

有机融合这些方案，就是初步的架构。

架构设计的特点

架构是和业务紧密相关。业务不同，解决方案也不同，架构就不同。

架构的演变是业务上的驱动，APP处于不同发展阶段，架构上也需变化。

架构不是为了炫耀技术，是为了满足业务需要，不应过度设计。

App和App后台的通信

1.用HTTP协议还是私有协议？

APP与后台通信分为使用通用语言和使用暗语两种方式。协议就相当于一套语言，双方都知道每个字节的具体含义。HTTP协议是使用的最广泛的协议。大多数开发语言都支持通用协议，有大量成熟模块供程序员调用，方便程序员解析这些通用协议的内容。

使用私有协议相当于使用暗语，类似于开发一种新的语言。私有协议对协议的封装和拆解工作量大，APP程序员和后台程序员都要增加额外的工作量，且私有协议对程序员的设计能力要求高。除非开发者对APP的安全性和性能要求高，不然选择HTTP协议就足够。

2.APP和后台通信使用长连接还是短连接？

可以用打电话的模型理解：是一致保持通话，还是有需要才拨号通话。长连接就相当于一直保持通话，服务器能保持的通信数量有限，如果达到数量极限，需要增加服务器。这种通信方式多数是使用Socket和WebSocket连接长时间连接，对程序员素质要求高，开发困难，除了手游和聊天推送外，不建议使用。当APP和服务器使用短连接，主要使用HTTP协议，开发效率高，推荐使用。

3.APP和后端是怎么通信的？

APP后台只提供了一系列功能给APP使用，这些功能以API的形式提供。API（应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。

当APP调用API时，需要明确：

API的用途。比如用取款器取款、查余额。

输入什么。比如取款需要输入金额。

结果是什么。比如取款成功还是失败。

4.后端是返回给API的数据格式

API一般是以HTTP的形式调用的，通过HTTP传入参数返回数据。JSON是一种轻量级数据交换格式，比XML更省流。{“age”：11，“name”：“jeff”}

APP和后台通讯过程

选择服务器

如果出现了APP访问量爆发的情况，解决访问压力最快的方式就是升级服务器的硬件。使用云服务升级硬件很简单：选择硬件配置；付款；重启服务器。上线初期一般都在一台服务器上搭建所有服务，随着APP的发展，这些服务需要部署在不同的服务器上。

选择编程语言

选择符合业务场景的最热门的变成语言。

1.每种编程语言都有自己擅长的业务场景和性能特性。

2.选择开发效率最高的编程语言。

3.忌讳用两套不同的语言维护同一个业务逻辑。

4.一个系统中，不同的业务逻辑可以用不同的编程语言实现。

研发阶段

Android和iOS工程师先设计前端架构，或先做界面。后端架构设计完成后，通过三点初步设定API接口：API是有什么用？API的输入函数是什么？API返回什么数据？后台工程师向前端说明API接口，初期API不用实现功能，返回假数据，后期慢慢实现。

最适合App的开发模式——敏捷开发

略，近期=找本敏捷的书学习下。

每日例会

昨天完成了哪些任务？

每个任务用了多少时间？

没完成的任务还要多少时间？

今天准备做哪些工作？

有什么工作需要其他同事配合？

回顾会议

这轮迭代做的好的和不好的地方。

第2章 App后台基础技术

从App业务逻辑中提炼API接口步骤：

业务逻辑思维导图。

功能—业务逻辑思维导图。

基本功能关系模块。

功能模块接口UML（设计出API）。

在设计稿标注API。

编写API文档。

业务逻辑思维导图

用思维导图把结构关系列出来，包括里面的功能。把相同的元素整理出来，比如都是相同的推送、评论、图片上传，然后用相同颜色表示出来。

功能—业务逻辑思维导图

MVC，写一个model的名字出来，开发人员能够把业务逻辑里面的东西和其关联。简单说就是一对多，一就是model，多就是业务逻辑，一个model对应多个业务逻辑。先做最上限的一层，尽可能多的进行一对多的分析，然后按照最小独立原则，看这个是不是一个最小的系统，按设计原理：每个model都是一个可独立运行的模块，也就是说model和model之间是没关系的。在思维导图中，其实就是业务逻辑和功能模块的结合。

划分功能模块依据三个原则：

功能模块和业务逻辑之间的关系。

功能模块和功能模块之间不能有关系。

功能模块要尽可能的实现一堆多（一个功能模块对应多个业务逻辑）。

基本功能模块关系

现在要做第三个图，步骤是从业务逻辑进入功能模块，功能模块按人和事来分。

人有哪些功能模块？

事有哪些功能模块？

人和事之间的关系又有哪些功能模块？

功能模块接口UML（设计出API）

现在只考虑功能模块，做功能模块的UML图，要设计哪些接口去解决哪些问题。接口是基于现在的模块、粗略的模块。基于现在的模块设计接口，就是要提高耦合度，确保耦合正确。

编写在线API测试文档

API在线测试文档使用Swagger-UI搭建。

设计稿标注API

后台开发在设计搞上标注出哪个界面调用哪个API。

设计API的要点

根据对象而不是页面设计API。

API命名简单易懂。

API安全性。

API所返回的数据。API返回的数据中正确值和空值的类型必须一样。数据库设计得时候，合理的设计原则是所有字段都有默认值，不允许Null值。

图片的处理。APP本地缓存图片，缓存图片不存在时才请求服务器API。当APP需要某种尺寸的图片，由APP通知服务器所需图片的尺寸，服务端动态生成并缓存。

返回的提示信息。APP后台只返回信息代码，具体文字APP决定。

在线API测试文档。

APP启动时调用一个API获取必要的初始化信息。

API版本升级需要注意：V2版本的Controller必须继承V1版的Controller，这样V2版本的API只重写需要改动的API。

如何选择合适的数据库产品

Redis，MongoDB，MySQL读写数据的区别

Redis的数据存放在服务器的内存，内存满了需要扩容，只能使用Redits的分布式方案。

MongoDB同时使用硬盘和内容，使用MMAP机制进行数据文件读写，可以直接把文件映射到进程的内存空间中，这样文件在内存中有对应的地址，对文件的读写是能通过操作内存进行的。

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

Redis，MongoDB，MySQL查找数据的区别

Redis的数据是基于“键值对”存储，键相当于门牌号，值相当于房间，Redis查找数据每次都是直奔目标，读写速度快。

MongoDB和MySQL中，没组数都有一个id（或为每组数据建立索引），这个id和索引就相当于门牌号。

MongoDB和MySQL中查找数据有两种模式：知道id或索引，不知道id或索引。不知道的时候就要遍历。

Redis，MongoDB，MySQL适用场景（略）

消息队列的工作流程

巨无霸系统的危害

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

远程服务的优点

解决上述问题的方法是把重复实现的模块独立部署为远程服务，新增的业务调用远程服务所提供的功能实现相关业务，不依赖于里面具体的代码实现。下图为把登录模块部署为一个远程服务。远程服务的实现：REST/PRC/开源PRC库。

搜索技术的基本原理

如果知道每行数据中包含多少关键字，然后建立一个映射表，把每个关键字出现在哪行数据中记录下来，搜索就不用遍历。当知道关键字，只需要查找映射表，找到关键词，根据关键词建立的映射关系就能查到包含这个关键词的数据。知道每行数据中包含多少个关键字的过程，就是分词。常见开源搜索软件：Lucene/Solr/ElasticSearch/Sphnix/CoreSeek

定时任务

APP后台开发经常需要执行一些定时任务，如定期清理垃圾文件等。

第3章 App后台核心技术

用户验证方案

使用HTTPS协议

HTTPS基于HTTP开发，用于在客户计算机和APP后台之间交换信息。其使用安全套接字层（SSL）进行信息交换，简单来说其是HTTP的安全版。HTTPS实际上使用了安全套接字层（SSL）作为HTTP应用层的子层。

基本的用户登录方案

URL签名

AES对称加密（略）

App后台发送短信简介

发送手机短信要通过运营商的短信通道，但通道费用过高，进而催生了短信平台。短信平台购买了运营商的短信通道后，把一个通道给一批企业共同使用，让企业按发送短信数量付费，从而降低了企业发送短信的成本，同时短信平台也初步审核短信内容，避免出发短信通道的使用限制。APP后台购买了短信平台的短信服务后，就能通过短信平台的API接口发送短信。

内容的推拉

如果APP要知道首页是否有内容更新，通过轮询机制访问获取API，从API是否返回更新的数据得知是否有内容更新。轮询即每隔一段时间，APP向后台发送请求获取是数据。缺点：耗电、耗流量。

推模式的流程

不能只用推模式，手机网络环境的复杂性，不能保证数据更新的通知一定能到达APP，所以也要采用轮训的方式定期拉数据，使用推拉结合时轮询的时间间隔可以设置的比较长。

文件系统

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

第4章 Linux-App后台应用最广泛的系统

后台开发需要兼顾开发与运维两方面，现在的APP服务器大多是运行在Linux系统，因此开发工作中设计大量Linux的运维操作。具体操作不看了。

第5章 Nginx-App后台HTTP服务的利器

Nginx是一个高性能的HTTP和反向代理服务器，在BAT和众多互联网公司有广泛应用，其主要特点是占用内存少，并发能力强。略略略。

第6章 MySQL-App后台最常用的数据库

第7章 Redis-App后台高性能的缓存系统

MySQL速写速度慢，随着互联网发展，越来越多业务场景需要满足：少量数据需要经常被读写，对速度要求高；能提供丰富的数据结构；提供数据落地的功能。Redis就死满足上述需求的开源Key-Value内存存储系统。

第8章 MongoDB——App后台新兴的数据库

MongoDB是介于关系型数据库和非关系型数据库之间的产品，是非关系型数据库当中功能最丰富、最像关系型数据库的数据库。是由10gen公司基于C++编写，知名IT公司使用其构建自己的核心应用的有eBay、Cisco、Adobe等。它的主要特点：读写性能高、灵活的文档模型给开发带来的方便、水平扩展机制能轻松应对从百万到十亿级别的数据处理。这也是MongoDB名字来源于单词humongous的原因。

第9章 App后台架构剖析（略）

第10章 App后台架构的演进

架构的核心要素

高性能。

高可用。

可伸缩。

可扩展。

安全性。

架构的演进

单机部署。

分布式部署。

服务化。

架构的特点

每个App的后台架构不会完全一样。

架构的演进是由业务驱动的。

架构不是为了炫耀技术。