DocHub 文库系统是使用Go语言的Beego框架开发实现的类百度文库解决方案,使用对商业友好的 Apache2.0 开源协议进行开源,支持office(全部类型)、PDF、TXT、EPUB、MOBI等多种文档格式的在线阅读浏览。

升级日志

  • 修复 group by title 查询文档列表失败的问题:https://stackoverflow.com/questions/34115174/error-related-to-only-full-group-by-when-executing-a-query-in-mysql
  • 导航栏标识大小写导致选中的时候无法高亮的问题
  • 修复上一版本增加虚拟目录导致的 sitemap 找不到的问题
  • 面包屑导航链接不正确的问题
  • 文档上传过程中临时文件命名出现重名的问题
  • 后台配置了备案号前台无法显示的问题(不知道是什么时候写死在模板里了)
  • 是否允许上传重复文档(管理后台 -> 系统设置 进行设置)
  • 每天凌晨 2:00 自动更新站点地图(sitemap)

相关链接

源码仓库

下载地址

https://gitee.com/truthhun/DocHub/releases

文档地址

https://www.bookstack.cn/books/dochub

演示站点

文库之家:https://www.wenkuzhijia.cn

手机端和PC端都可以直接点开访问,手机用户会自动显示为手机版。

重构规划

DocHub 项目之所以在码云和GitHub收到的star比较高,那是因为项目切中了大多人的需求,以及前端页面设计的比较简洁好看,且用户体验也尚可。

但真实情况却是代码写的很渣,这个真不是自谦。尽管我已经尽了很大努力去优化,但是一个不合理的数据库设计以及不规范的代码写作,导致了后续功能扩展和代码维护困难重重。

所以,还是决定对项目全部推翻了进行重构。现有分支仍会持续维护和修复Bug,但不会再增加新功能。重构会在新分支上进行,对于不兼容问题,届时会出一个迁移工具,以帮助从旧版迁移到重构的新版本上来。

服务架构

完整的服务架构图如下,按100万的IP访问量来进行设计的。

DocHub v2.4 发布,常规升级 - 图1

高清图看这里: https://www.processon.com/view/link/5b29103ae4b0d4a19d7c67f1

  1. DocHub 将采用前后端完全分离的技术方案,一套API接口,供PC前端和移动端APP和小程序使用
  2. 文档转换服务是比较耗费服务器资源的,属于计算密集型,该功能将独立成一个文档转换服务moredoc(也就是魔刀),以便可以独立部署到另外的服务器上
  3. CloudStore是一个云存储服务中介,支持将文档等文件数据存储到各大云存储上。

moredoc(魔刀文档转换服务)

DocHub v2.4 发布,常规升级 - 图2

高清图看这里:https://www.processon.com/view/link/5cd63503e4b0bab9097b9ef2

moredoc的技术构成和转换原理,如上图所示。

该服务将支持全部 office 文档类型和epub等文档类型转为可在前端页面展示的图片以提供用户阅读。

现有dochub文库系统目前文档转换依赖的软件基本上就是上面这些了(除了pdftohtmlex)。

由于这部分软件的安装部署,对于小白用户以及不同系统用户来说,比较复杂,所以整成moredoc文档转换服务之后,整个都将打包到docker容器中,moredoc只提供文档转换的resetful接口给dochub进行调用。

技术栈

DocHub v2.4 发布,常规升级 - 图3

前端技术方案主要用Vue,考虑到SEO的需要,配合Nuxt使用,UI 使用ElementUI

移动端使用uni-app的解决方案,一次开发,多端分发。

后端选用Go语言,至于群友问为什么不用PHPPython

我也是做过三年PHP开发的,好不容易跳脱出来,又想骗我回去,怎么可能…Python的话,在公司也就写写脚本做做运维,并没用真正实现过一个产品的开发,对这门语言还是不熟练。

所以综合考虑选用Go语言,Go语法简洁,性能和开发效率都很高,编译成二进制可执行文件之后,直接丢到服务器就能跑了,还不需要安装环境依赖,部署简单。

重构周期

我想按照自己的节奏来开发,由于是业余时间做的开发,所以开发周期至少要半年以上。