类摩拜等共享小程序，架构设计与编码实现（单机版）

前言

18年初的时候，由于一个人设计并搭建设计到前端实现，所以一开始的时候可能对数据库没有什么经验，在改业务的时候，数据库的设计真的是有点头大。还有对于本文不是教你一句一句代码敲出一个项目，而是将项目的思路给你，由你去修改出以后更加适合自己的架构或业务实现思路。

这是一个真实的创业项目，不过现在已经结束了，原因种种······

项目业务与UI切图

由于现在已经终止了，所以也没有在线上运行，所以我就给大家看看大致的UI图

• 1、首页，与共享型一样，定位，获取硬件坐标
  

• 2、硬件是一个书柜，里面固定放了24本书，所以你点击首页的图书logo可以看到那个书柜里面的书籍（每个书柜都是不一样的）
  

• 3、点击图书，就是图书详情还有书评，用户点击“立即借阅”，书柜会打开对应图书的柜子门
  

• 4、借阅过的用户，可以进行书评功能
  

• 5、与其他共享app一样，也有押金和卡包功能
  

• 6、其余的大同小异

以上就是基本的业务，其余可以由读者自己发挥

架构与设计

嗯，直接上一个简易版的图纸

1、前后端分离，不管是应用还是后台数据都是API形式
2、微信与支付宝（app版）都是使用sdk，后期换了GitHub上一些开源工具包、卡包可以做成小系统
3、core，二维码模块，需要针对每台设备做定制生成，后台做了二维码系统，小程序接口有介绍，二维码模式下添加每台机的唯一参数进行数据请求
4、netty与单片机硬件的通信，TCP/IP协议，自定义通信规则，帧头+ID+数据类型+内容+CRC16加密串+帧尾，netty做了很多很好封装
5、数据库与缓存Redis，由于单机版，在没有实际用户量要求的情况下，没有使用多余的成本去做分布式、数据库主从库、并发等等
6、Netty的数据操作与数据库有关需要在Future中的线程执行，使用了原生JDBC操作CRUD，没有使用mybatis的spring注入。

技术分解

业务主体与思路

首先，这个有区别与电商类应用，这里没有很明显的商品与库存的概念，因为尽管是ISBN相同的一本书，它们投放的（书柜）箱子可以是不一样的，用户拿到手的书本即使名字内容一样，但是它们之间是不对等的，所以每一本书都要有唯一ID，书柜投放的设备也是一样，每生产一台机子，都有唯一ID与通信ID、并生成对应的二维码，用户扫码进入小程序看到的数据是针对这个书柜的图书

netty通信模块

我的一个失误，使用的netty5.0版，但是其实5是一个舍弃的版本，但是最后还是运行正常，不过个人觉得如果要使用netty还是用4主版较好。netty通信框架对于接入的channel会自动生成id，我们需要在第一次通信的接收信息时，校验通信协议（CRC16加密、帧头、帧尾等）是否正常，如果正常需要自己定义一个类似group的堆去重新存放我们的合法channel并改它的系统通信ID，接着需要做什么数据操作，类似开锁、设备报警等信息就future中处理，如果涉及数据库的操作，则用JDBC。

支付卡包

对于这个模块想说的甚少，押金就是一个判断校验，有做过微信支付的朋友都可以做出来，况且现在Github上有挺多资源了。月卡、季卡我没有设计的很好，而是一个和系统一起的功能代码，很庆幸在之后我重新做了修改，设计为系统模块。

通用开发架构

对于API的返回规范ResultVO、与定制ResultVOUtil（success、error）等api返回协议、Exception全局监控、API拦截权限、后台增删改查数据校验、系统日志等等细节，这里不做一一讲解，有web开发经验的都有一些了解了。

总结

最后，由于项目停止了，我不能给大家看实际产品效果，但是上线一个月的阶段功能均正常，以下是项目的代码目录，均为本人手敲、（摸索）设计完成。