工作日记-智能柜硬件驱动的设计-初步设计
背景
新增的保密柜业务，硬件部分的协议最近已经确定下来了，需要我们中间件组配合开发一个驱动，这个驱动不包含业务相关的部分，只封装和硬件交互的部分，提供简单易用的接口给上层服务使用。我在物流项目的第二版本中曾经设计过类似的驱动层，这次正好趁这个机会好好打磨下。
具体设计
驱动层需要包含两方面的内容：
- 协议实现
- 交互API
最开始的想法是，因为交互API是独立于协议层的，所以想把这两个内容拆开，单独打包引用，方便后续可以便捷的切换到其他硬件协议。但是后来仔细想了一下，交互API需要返回的数据很可能和具体的业务相关联并深度绑定，拆成两个jar，一是引用不方便，二是增加了维护的成本。所以按照从下到上的设计原则，应该先把这两部分合二为一，如果后续再遇到需要拆分的需求再进行拆分，目前拆分为时尚早。
协议实现
协议中参数获取指令、设置指令和固件升级等运维指令是不需要包含在本次的驱动层设计之中的，原因是 硬件调试和运维部分，我们会单独抽取出来一个C端或者B端的工具给现场调试人员使用，所以不包含在此次的自动业务场景中实现。
协议的具体实现部分比较简单，按照硬件部门提供的新版本协议，使用我之前设计好的框架实现即可。
交互API
根据业务的需求，保密柜业务中最重要的业务就是统计功能，统计功能的业务步骤如下：
- 上层业务系统告知驱动层哪些文件柜需要统计
- 驱动层对需要统计的保密柜发送开启统计指令
- 保密柜回复开启统计成功或失败指令，如果成功跳转到4，如果失败，业务结束
- 保密柜内部需要启动盘带你并等待N分钟，然后一次性回传所有数据给上层服务
- 驱动层检查收到的数据是否完整，如果完整，把所有数据返回给上层业务；如果不完整，告知上层业务此次盘点业务失败
上层业务系统如果返回失败，可以启动查询最近历史统计功能的业务流程：
- 上层业务告知驱动层需要获取最近的统计结果（仍需告知需要交互的保密柜）
- 驱动层发送获取历史文件统计结果指令，重新获取最近的统计结果
- 保密柜回传最近的统计结果数据给驱动层，如果数据完整，将数据返回给上层业务；如果不完整，返回上层业务告知查询失败
