前言
最近比较闲，没什么活，并且利用这一段时间学习了部分有关
SpringCloud体系下的分布式框架和中间件，也根据公司业务情况和技术栈设计了一份升级的提升并发的架构（哈哈这里因为还没测试过，所以先说提升，而不是高并发）
环境&需求 描述
教育装备业务，教室，电子班牌，学生人脸识别考勤
哈哈，很简单的描述，你也应该清楚业务环境及流程了？
对，非常简单
但这仅仅是单个学生的打卡流程，在实际生产环境中，每一节课上课前的±5分钟学生量是很大的
吐槽一下，其实也不大，一般的高校打卡吞吐量需求在1k-2.5k之间，不能再高了因为不可能所有学生都上课，当然那种3-4k以上的超级高校当我没说
实际上的生产环境是下面的流程↓
识别的部分不去讨论，可以做在班牌上也可以做在后端，whatever~
这个时候如果后端只是单例的话，那么在上课前后时不仅要处理来自设备上报的打卡信息，还要处理此时后台管理系统前端的请求
任一环出现问题，将出现全面宕机（服务不可用）
一般情况下，是不会出现后台宕机情况的。。。。因为即便是单例的Springboot程序，处理这些并发还是可以的，不过可能会导致某些服务响应时间无限加长，尤其是服务多了之后：数据库读写，设备控制，后台管理控制等等
所以我们需要加入分布式以及消息机制来做一点小小的升级实现流量削峰
升级的架构设计
根据上面的服务架构图本篇文章将对后端服务部分做升级
引入SpringCloud及RocketMQ实现人脸考勤部分的并发架构
这里引入的消息中间件是因为业务环境非常合适：
- 设备考勤记录产生是消息生产者
- MQ是消息储存者
- 考勤记录存档为消息消费者
对吧？由于RocketMQ的超高性能，对于这点消息吞吐已经是绰绰有余，甚至可以换成RabbitMQ（支持AMQP协议）也是可以的，总之对于一个架构来说任何一个部分都是被解耦出去的，都是可更换及横向扩展的
RocketMQ性能测试分析的文献：
并且还有其他业务会被用到啊！比如设备的自检，各种新闻展示图片的发布，配置的更改，学生人脸数据的更新等等等等，所以说引入消息中间件是非常有必要的，可以将项目服务提升性能及进行大规模降藕解耦，所以本文也只是对该部分服务的一个简单升级，以及后续解耦的启发！
设计结构
想了一会，那就开始设计了↓
就这？就这。
架构设计重在思考，想的多了，写的就少了
当然上图还有一些部分没有给大家画出来：
- 注册中心
- 接口鉴权中心
- 缓存服务
- 配置中心
- 等等
要注意的点：
对于考勤消息记录的处理保存要考虑到几个点
- 消息处理服务的幂等性
- 确保考勤消息的成功消费
- 确保考勤消息消费的实效性（待定）
下篇博客上代码！
因为1k字了
