我的书签
添加书签
移除书签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访问量来进行设计的。
高清图看这里： https://www.processon.com/view/link/5b29103ae4b0d4a19d7c67f1
- DocHub 将采用前后端完全分离的技术方案，一套API接口，供PC前端和移动端APP和小程序使用
- 文档转换服务是比较耗费服务器资源的，属于计算密集型，该功能将独立成一个文档转换服务
moredoc（也就是魔刀），以便可以独立部署到另外的服务器上 CloudStore是一个云存储服务中介，支持将文档等文件数据存储到各大云存储上。
moredoc（魔刀文档转换服务）
高清图看这里：https://www.processon.com/view/link/5cd63503e4b0bab9097b9ef2
moredoc的技术构成和转换原理，如上图所示。
该服务将支持全部 office 文档类型和epub等文档类型转为可在前端页面展示的图片以提供用户阅读。
现有dochub文库系统目前文档转换依赖的软件基本上就是上面这些了（除了pdftohtmlex）。
由于这部分软件的安装部署，对于小白用户以及不同系统用户来说，比较复杂，所以整成moredoc文档转换服务之后，整个都将打包到docker容器中，moredoc只提供文档转换的resetful接口给dochub进行调用。
技术栈
前端技术方案主要用Vue，考虑到SEO的需要，配合Nuxt使用，UI 使用ElementUI。
移动端使用uni-app的解决方案，一次开发，多端分发。
后端选用Go语言，至于群友问为什么不用PHP和Python…
我也是做过三年PHP开发的，好不容易跳脱出来，又想骗我回去，怎么可能…Python的话，在公司也就写写脚本做做运维，并没用真正实现过一个产品的开发，对这门语言还是不熟练。
所以综合考虑选用Go语言，Go语法简洁，性能和开发效率都很高，编译成二进制可执行文件之后，直接丢到服务器就能跑了，还不需要安装环境依赖，部署简单。
重构周期
我想按照自己的节奏来开发，由于是业余时间做的开发，所以开发周期至少要半年以上。
