《App后台开发运维与架构实践》第2章 App后台基础技术

「爱情、让人受尽委屈。」 2022-01-14 15:15 192阅读 0赞

[2019独角兽企业重金招聘Python工程师标准>>> ][2019_Python_] ![hot3.png][]

## **2.1 从App业务逻辑中提炼API接口** ##

*  业务逻辑思维导图
 *  功能-业务逻辑思维导图
 *  基本功能模块关系
 *  功能模块接口UML（设计出API）
 *  在设计稿标注API
 *  编写API文档

## **2.2 设计API的要点** ##

*  根据对象设计API
 *  API的命名
 *  API的安全性
 *  API所返回的数据：禁止返回Null值
 *  图片的处理：图片数据库保存原图，在App客户端本地缓存图片不存在时，按图片尺寸向服务端请求动态生成。
 *  返回的提示信息：给用户看的提示和给程序员看的提示。
 *  在线API测试文档：使用Swagger-UI搭建，按TDD（测试驱动开发）原则进行开发。
 *  在App客户端启动时调用一个API获取必要的初始化信息：比如App版本
 *  关于API的版本升级问题：V2版本的API的Controller必须要继承V1版本的Controller，V2版本的API只重写需要改动的API。

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

### 2.3.1 Redis、MongoDB、MySQL读写数据的区别 ###

*  Redis的数据是存放在服务器的内存，当内存用满了后需要扩容，就只能使用Redis的分布式方案。为了防止断电或Redis程序重启造成内容数据的丢失，可调整Redis配置文件，按照一定的策略把数据持久化传到硬盘。
 *  MongoDB同时使用了硬盘和内存，其使用了操作系统提供的MMAP（内存文件映射）机制进行数据文件的读写，MMAP可以把文件直接映射到进程的内存空间中，这样文件就会在内存中有对应的地址，这时对文件的读写是能通过操作内存进行的，而不需要使用传统的如fread、fwrite文件操作方式。
 *  MySQL的数据是放在硬盘中的。虽然MySQL也有缓存，但MySQL缓存的是查询的结果，而不是缓存数据。

### 2.3.2 Redis、MongoDB、MySQL查找数据的区别 ###

*  Redis的数据是基于“键值对”存储。Redis查找数据，每次都是直奔目标，读写速度当然快。
 *  MongoDB和MySQL中查找数据，有两种模式：知道id或索引，不知道id或索引。前者直奔目标，效率高；后者逐个查找，效率低。

### 2.3.3 Redis、MongoDB、MySQL适用场景 ###

*  Redis适用场景：读写频率高的数据、热点数据。
 *  MongoDB适用场景：网站数据（实时的插入、更新与查询），大尺寸、低价值的数据，高伸缩性的场景（数十或者数百台服务器组成的数据库），存储地理坐标的数据；不适合高度事务性的系统、传统的商业智能应用及需要复杂SQL的问题。
 *  MySQL适用场景：事务性的系统（涉及金钱），需要复杂SQL的问题。

## **2.4 如何选择消息队列软件** ##

### 2.4.1 为什么使用消息队列 ###

将一些需要花比较多的时间，而且迟点完成不影响整个任务的完成进度的小任务，放到消息队列中，可加快后台请求的响应时间；比如发送邮件、发送短信、推送消息等任务就非常适合放到消息队列中。同时消息队列也能把大量的并发请求变成串行的请求，减轻服务器的负担。

### 2.4.2 消息队列的工作流程 ###

*  App后台（队列生产者）把消息推入到消息队列；
 *  守护进程（队列消费者）不断地检测消息队列中有没有新的消息，没有消息就休息一会儿再检测消息队列中有没有新的消息（这样做能避免消息队列占据过多的服务器资源），有消息的话就从消息队列取出消息，用新的线程处理相关的业务，在主线程中继续检测消息队列是否有新消息。

### 2.4.3 常见的一些消息队列产品 ###

*  RabbitMQ：重量级的消息队列，适合企业级的开发，其支持大量的协议，比如AMQP、XMPP、SMTP、STOMP；同时RabbitMQ自带了一个Web监控界面，可方便监控队列的情况。
 *  Redis：虽然是一个key-value系统，但其也支持队列这种数据格式，可看作是一个轻量级的消息队列。在App后台架构中Redis被广泛使用，如果把其作为消息队列，能减少项目中的运维成本。
 *  ZeroMQ：号称最快的消息队列，尤其针对大吞吐量的需求场景。
 *  ActiveMQ

## **2.5 使用分布式服务实现业务的复用** ##

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

### 2.5.1 巨无霸系统的危害 ###

*  维护上的麻烦
 *  代码管理上的不方便
 *  数据库连接资源的耗尽

### 2.5.2 远程服务的优点 ###

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

### 2.5.3 远程服务的实现 ###

*  REST

REST（Representational State Transfer），即**表述性状态传递**，它是一组架构约束条件和原则。满足这些约束条件的原则的应用程序或设计就是RESTful。

REST架构的特点：每一个URI代表一种资源；客户端和App后台之间，传递这种资源的某种表述；客户端通过GET、POST、PUT、DELETE等HTTP动词，对App后台资源进行操作，实现“表述性状态传递”。

REST设计原则中最重要的是请求是无状态的。

*  RPC

RPC（Remote Procedure Call），即**远程过程调用，**它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

*  开源的RPC库

阿里巴巴开源Dubbo，其是一个分布式服务框架，致力于提供高性能和透明化的RPC远程调用服务和SOA服务治理方案。

当当网在Dubbo的基础上实现了如下的新功能，并将其命名为Dubbox。

1.  支持REST风格远程调用（HTTP+JSON/XML）。
2.  支持基于Kryo和FST的Java高效序列化实现。
3.  支持基于嵌入式Tomcat的HTTP remoting体系。
4.  将Dubbo中Spring由2.x升级到目前常用的3.x版本。
5.  将Dubbo中的Zookeeper客户端升级到最新的版本，以修正老版本中包含的bug。

## **2.6 搜索技术入门** ##

常见的开源搜索软件介绍

*  Lucene
 *  Solr
 *  ElasticSearch
 *  Sphinx
 *  CoreSeek

## **2.7 定时任务** ##

*  Linux定时任务Crontab
 *  Java定时任务框架Quartz

转载于:https://my.oschina.net/lienson/blog/3035295

[2019_Python_]: https://my.oschina.net/u/2663968/blog/3061697
[hot3.png]: /images/20220114/753b0fb56e7446a9a1998629b9b8060a.png