记开发证照借阅系统的全部流程，主要说下实现方案和难点（项目其他部分非常简单，不再赘述）
1.借阅审批，基于工作流引擎实现
2.打水印，主要在pdf,和图片上打印有限时间和事由
3.消息队列与乐观锁，处理高并发下原件的竞争问题（类似于抢购系统1000线程竞争2个资源）
系统间关系图，
1.用户在文档管理平台查询并借阅文件，根据借阅文件分发成多个工作流，组装工作流需要的必要参数，调用工作流引擎发起，
2.审批者审批（邮件短信微信提醒），
3.审批完成后，调用文档管理平台接口，回写用户借阅文件状态（提醒申请人审批完成），
4.打水印打包
1.借阅审批
我间断的做了4年的工作流二次开发（在现有引擎下，实现业务逻辑），做过K2，奥哲H3，开源的有CCFlow，RoadFlow
我最终选用引擎为CCFlow，RoadFlow商业使用有些限制，开源的版本与最新版本差距太大，源码基本就参考作用。
详情我会开另一篇随笔，介绍CCFlow开发
2.打水印
为电子扫描件打水印，供用户下载。特别的，如果用户一次借阅多个电子件且审批通过，可以用代码将打好水印的文件压缩供用户下载。
具体打水印实现请参考这两位博主的文章。
https://www.cnblogs.com/amylis_chen/p/3403069.html
https://blog.csdn.net/eiceblue/article/details/49493185
3.消息队列与乐观锁
这部分在本项目中其实不属于优化功能，用户在借阅电子件时，往往一次会借阅几十或上百分扫描件，由于每个文件的审批者可能不相同，一次借阅流程会按照每个文档分发，比如借阅50个文件，RoadFlow生成50个独立的流程。这么做的好处是，每个文档均可以独立审批，不会影响其他文档，先审批完毕的，可以先下载，全部审批完毕可以批量下载。缺点是增加了工作流引擎的负载，RoadFlow发起一个工作流大概耗时0.4s，单如果200个，用户在发起是就需要等待0.4*200即80s，用户体验会非常差。
解决方式引入消息队列ActivityMQ，用户发起后，将借阅的信息入队，只要入队成功就向用户反馈发起成功（0.5s左右），在异步消费时，完全结束后，再向用户发邮件，表明借阅的成功或失败。
另一个使用消息队列位置是文档管理平台的审批状态回调接口，审批者是批量审批，所以在一瞬间可能回写几百份文件，在此处引入消息队列，按照服务器性能配置，并发的出队线程数，避免水印IO崩溃或管理平台数据库死锁
文档管理平台另一个功能是借阅原件，原件有严格的份数，一个人如果借出了，另一个就无法借阅。客户的业务人员需要大量借阅原件，保证自己的绩效和项目进度，这已经超出正常的文件管理系统范畴，借阅时间差小于1ms，普通的页面级表单锁已经无法满足，我们参考了网上主流的抢购系统，引入了redis乐观锁，效果拔群！
后记
永远不要低估客户随口提一句的需求，带来的难点和工作量