APP后台开发运维与架构实践 2 : App后台基础技术
1、简介
App后台的两个重要作用：远程存储数据和消息中转
需求
2、App后台基础技术
2.1 从App业务逻辑中提炼API接口
项目初期只知具体的业务逻辑，
6个阶段：
- 业务逻辑思维导图
- 功能---业务逻辑思维导图：支撑业务逻辑的功能模块，属于model
- 基本功能模块关系：按照人和事来分，人、事、事件
- 功能模块接口UML（设计出API）：合理的耦合度
- 编写API文档：使用Swagger-UI搭建，www.sosoapi.com提供了在线编辑和预览测试接口的功能，其基于Swagger-UI，方便地解决了Swagger-UI部署和编写接口的不便之处。
- 在设计稿标注API：哪个界面调用哪个API
2.2 设计API的要点
根据对象设计API：根据对象而不是界面来设计API。
API的命名：第一个是对象，第二个是对象的操作删除，如删除微博的API“statuses/destroy”。
API的安全性：
API所返回的数据：数据库设计时所有字段都有默认值，不应该允许Null值，Null值在语言和数据库中会带来无穷的问题。
图片的处理：不同尺寸的手机，参考策略，客户端本地缓存图片，不存在才请求API并提交图片大小，有服务端动态生成并缓存。现在的CDN都提供了图片的缩放功能。
返回的提示信息：
在线API测试文档：
在App客户端启动时调用一个API获取必要的初始化信息：如提示版本更新的功能。
关于API的版本升级问题：test.com/v2/statuses/destroy，兼容
2.3 如何选择合适的数据库产品
Redis，MongoDB，MySQL读写数据的区别：
Redis的数据是存放在服务器的内存，满了后需要扩容，就只能使用Redis的分布式方案。为了防止断电或重启造成内容数据的丢失，可调整Redis配置文件，按照一定的策略把数据持久化传到硬盘。
MongoDB同时使用了硬盘和内存，其使用了OS提供的MMAP（内存文件映射）机制进行数据文件的读写，把文件直接映射到进程的内存空间中，对文件的读写是能通过操作内存进行的，而不需要使用传统的如fread、fwrite文件操作方式。
MySQL的数据是放在硬盘中。虽然也有缓存，但是查询的结构，不是缓存数据。
Redis，MongoDB，MySQL查找数据的区别：Redis的数据是基于“健值对”存储，读写速度快。MongoDB和MySQL中，每组数据都有一个id
Redis，MongoDB，MySQL适用场景：读写频率高的数据一般都会放在Redis中，以缓存的形式存在的。
MongoDB适用场景：
- 网站数据：非常适合实时的插入、更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
- 大尺寸、低价者的数据：使用传统的关系数据库存储一些数据时可能会比较贵，在此之前，很多程序员往往会选择传统的文件进行存储。
- 高伸缩性的场景：非常适合有数十或者数百台服务器组成的数据库。
- 存储地理坐标的数据：MongoDB的地理坐标查询功能非常强大，例如，MongoDB可以查找在某个矩形范围内的所有坐标，因此非常适合于LBS应用。
MongoDB不适合用下面的场景：
- 高度事物性的系统：例如银行或会计系统。由于MongoDB不支持事物。
- 传统的商业智能应用：针对特定问题的BI数据库会产生高度优化的查询方式。对于此类应用，数据仓库可能是更适合的选择。
- 需要SQL的问题：它的查询比起MySQL还是有一定的差距。
MySQL适合场景：
- 事物性的系统
- 需要复杂SQL的问题
2.4 如何选择消息队列软件
为什么要用消息队列：当后台系统发现完成某些小任务需要花很多时间，而且迟点完成也不影响整个任务的完成进度时，就会把这些小任务交给消息队列。发送邮件、发送短信、推送消息等任务都非常适合在消息队列中处理。同时消息队列也也能把大量的并发请求变成串行的请求，来减轻服务器的负担。
消息队列的工作流程：队列服务端，队列生产者，队列消费者3个角色。如RabbitMQ，Redis，ZeroMQ，ActiveMQ。
2.5 使用分布式服务实现业务的复用
把重复实现的模块独立部署为远程服务，新增的业务调用远程服务所提供的功能实现相关的业务，不依赖于里面具体的代码实现。如登录模块部署
远程服务的实现：REST、RPC
2.6 搜索技术入门
搜索技术的基本原理： Lucene、Solr、ElasticSearch、Sphinx、CoreSeek
2.7 定时任务
例如定期清理一下项目产生的垃圾文件，或者要某段时间执行一些业务逻辑等，都需要使用到定时任务。
Linux定时任务Crontab命令、Quartz