一、背景

• 最近提示工程项目在做工程化的拆分，目的是将一些独立的模块单独拆出来做成基础的服务，方便维护、演进以及方便其他项目的调用，需要具有能快速横向拓展、稳定的特性。

二、需求

• 说干就干，干活之前先看看优秀的人是怎么做的，周围放眼望去，全哥的服务是公认的稳定、独立、拓展性好的标杆项目，好在：
  • 不依赖任何第三方组件、中间件，部署非常方便
  • 易于横向拓展，基于docker，在拓展服务器上docker-compose up -d，再在nginx中添加upstream即可
  • 功能单一，虽然参数很多，但就只做一件事，输入输出格式固定，方便对接
  • 服务端的集群和状态对客户端透明，服务端可以任意的迁移和伸缩
  • 稳定，超时、异常捕捉做的好，方便定位问题，服务稳定
  • 不做缓存，及时的数据清理（用户获取完信息便删除中间结果），数据和日志不会膨胀
• 基于成功经验，对于我们即将要做的服务的要求， 便有了初步的轮廓
  • 依赖尽量少的第三方组件及中间件，能不依赖，最好啥也不依赖
  • 部署方便
  • 拓展方便
  • 功能单一
  • 异常捕捉清晰、超时合理
  • 不做缓存，及时清理不需要的数据

三、设计

设计思维连（纠结链）

• 服务拆分之前，依赖的组件有
  • MySQL：存储任务状态信息
  • 阿里云OSS：存储PDF文件、中间缓存文件以及结果信息
  • RabbitMQ：采用生产者-消费者模式
• MySQL的作用就是记录一下任务的meta信息，不涉及事务、复杂查询和高并发，对于独立的小服务而言比较重
  • 如果把MySQL独立出来，需要单独启动并维护一个数据库实例
  • 如果把MySQL打包到小服务中，占用空间大，让docker镜像变得肿胀，没有必要
• 阿里云OSS的作用就是缓存各种文件和最终结果
  • 在小服务中不需要缓存PDF等文件，只需要记录一下最终结果（json）即可，而且用户获取结果之后可以删除清理，控制数据规模
• 那干脆把阿里云OSS直接替换为文件系统，既然服务是独立的，那直接写文件系统好了，方便，省事
• 然后把MySQL换成一个轻量的数据库，可以内置到容器
• 这样，既替换掉了臃肿的MySQL，又减少了阿里云OSS的依赖，服务就更独立一些了
• 经查阅，发现SQLite比较符合要求，正好可以替代原来MySQL和阿里云OSS的作用
  • SQLite是非常小的，轻量级的数据库，完全配置时小于400K
  • 它的数据库就是一个文件，无服务器、零配置，直接使用
  • 擅长存储文件，对于文件存储的优化，可以使SQLite在一些场景下甚至比本地文件系统快30%，磁盘空间少20%
• 服务拆分之后，依赖的组件有
  • SQLite（放在容器内部）：存储任务状态信息以及结果信息
  • RabbitMQ：采用生产者-消费者模式

四、补充材料-SQLite介绍及场景

• SQLite 是使用最广泛的数据库，嵌入式设备用的很多，所有的手机，操作系统都内置了SQLite
• SQLite 竞争对手是fopen，文件>100K的时候，存入SQLite比本地文件系统快30%左右，磁盘空间少20%
  • 
• SQLite 文件格式稳定，跨平台且向后兼容，开发人员保证至少在2050年之前保持这种格式
• SQLite 不支持行锁，只支持库级锁
• SQLite 贴心地指出了什么时候该用MySQL这类client-server数据库
  • 
• SQLite的时候发现主要瓶颈在IO，基于机械硬盘、SSD或者内存盘的SQLite性能差异巨大