Python 全栈系列36 - 搭建web服务的一些总结

说明

本篇并不涉及细节，主要是基于自有算网的基础，对构建web服务的后端逻辑进行一些优化和总结。假设基于的硬件：

• 1 一台云主机（A，服务器）：Ubuntu系统
• 2 一台局域网主机（B，服务器）：Ubuntu系统
• 3 一台MacBook(C，个人使用的电脑）

基于的软件：

• 1 FRP:提供B-C的SSH,方便进行远程控制，并提供B在A上的端口资源透射
• 2 MySQL: 记录用户信息，权限，上传的文件，以及计算的结果（报表）
• 3 RabbitMQ: 用于消息服务的连接
• 4 Flask: web服务

1 构建方式

• 1 C是可以直接连到云主机的
• 2 A上安装了MySQL和RabbitMQ，用于数据持久和消息中转（当然，有需要A可以扩展为多台或者是集群）
• 3 B上安装了计算程序，通过消费消息队列来响应A的请求。（同样，B也可以是多台）
• 4 A上安装了Flask，完成用户的鉴权和交互
• 5 在A上安装消息处理程序，通过消费消息队列来响应B的反馈。

2 逻辑上的分离（应用层面）

在Flask的视图函数中，只管”要什么“，而不必管”怎么做“

• 1 A上只做用户的鉴权和交互，所有的计算通过接口或者消息的方式分离到b(docker-compose)。

  • 1 计算：例如调用模型处理一组输入数据
  • 2 接口方式：如果调用过程很短（例如模型响应通常不超100ms),那么可以使用接口。
  • 3 消息方式：如果调用过程比较长（例如发送的请求是建模，可能超过1h),那么可以使用消息队列。

• 2 在C上开发好程序，打包成b(docker-compose),然后转移到B上启动服务。

  • 1 已经预先为每台B划分好了在A上的一个端口范围
  • 2 包内容的转移方式
    • 使用类似scp的文件拷贝方式（也可以集成在python程序中）
    • 使用git方式（针对大和复杂的方式

• 3 b的组织方式

  • 1 内容
    • 1 以python程序包的方式
    • 2 以web（flask 蓝图）的形式
  • 2 服务
    • 1 web服务
    • 2 消息服务

• 4 b的作用

  • 1 每个b都执行某一种或某几种计算
  • 2 通过接口数据的格式规范进行对接
  • 3 帮助设计者把复杂的逻辑和任务完全分解开

• 5 使用域名

3 逻辑上的集成（功能层面）

• 1 使用配置+编排的方式编程

  • 直接写视图函数会产生大量的冗余代码
  • 视图函数本身会有多个出口

• 2 *逻辑链条

  • 这块可以考虑结合图数据库进行编程，确保逻辑的可靠易理解（从而可以把逻辑规模扩的更大，更深）

4 数据库

• 1 几种类型的表集合

  • 1 固定表集合（可以有外键）
    • 1 用户信息
    • 2 用户角色
    • 3 用户交易表
  • 2 半固定表集合（不要有外键）
    • 1 变量映射表
    • 2 报表映射表
    • 3 报表
  • 3 不固定表

• 2 数据库的地址

• 3 数据库的主从同步

• 4 关于图数据库

  • 图数据库可以更好的表达结构上的变化

5 消息队列

• 1 消息类型
  • 即时消息
  • 延时消息
• 2 消息队列服务器的地址

6 反向代理与负载均衡

• 1 反向代理
• 2 负载均衡

7 快速搭建方式

• 1 获取服务器的root权限，执行初始化sh脚本。（通过C的scp函数执行）| 完成后机器即加入了算网

  • 1 云主机。脚本将快速设置root的免密登录，ssh会话时间（较长），frps服务（以及自动启动）
  • 2 局域网主机。脚本将快速设置root的免密登录，ssh会话时间（较长），frpc服务（以及自动启动）

• 2 在C上根据部署计划，使用python(paramiko)执行一系列的远程主机命令。

  • 1 拷贝方式建立项目文件夹
  • 2 git方式建立项目文件夹
  • 3 在bashrc 中写入一系列的密码
  • 4 使用docker-compose 进行项目的镜像构建和启动

• 3 添加或修改项目

  • 1 动态变更项目文件并重建或重启
  • 2 动态变更配置文件并重启

• 4 开放接口

  • 1 使用nginx配置反向代理，打通所有服务
    • 1 主应用在访问不同子服务时可以使用不同的super admin秘钥（在bashrc中存储）
    • 2 主应用可以向消息队列请求从而获得某台B的服务
  • 2 在云主机上开放80端口