# 前言
> 最近比较闲,没什么活,并且利用这一段时间学习了部分有关`SpringCloud`体系下的分布式框架和中间件,也根据公司业务情况和技术栈设计了一份升级的提升并发的架构(哈哈这里因为还没测试过,所以先说提升,而不是高并发)
# 环境&需求 描述
教育装备业务,教室,电子班牌,学生人脸识别考勤
哈哈,很简单的描述,你也应该清楚业务环境及流程了?

对,非常简单
但这**仅仅**是单个学生的打卡流程,在实际生产环境中,每一节课上课前的**±5分钟**学生量是很大的
> 吐槽一下,其实也不大,一般的高校打卡吞吐量需求在1k-2.5k之间,不能再高了因为不可能所有学生都上课,当然那种3-4k以上的超级高校当我没说
实际上的生产环境是下面的流程↓

识别的部分不去讨论,可以做在班牌上也可以做在后端,whatever~
这个时候如果后端只是单例的话,那么在上课前后时不仅要处理来自设备上报的打卡信息,还要处理此时后台管理系统前端的请求

任一环出现问题,将出现全面宕机(服务不可用)
> 一般情况下,是不会出现后台宕机情况的。。。。因为即便是单例的Springboot程序,处理这些并发还是可以的,不过可能会导致某些服务**响应时间无限加长**,尤其是服务多了之后:数据库读写,设备控制,后台管理控制等等
所以我们需要加入**分布式**以及**消息机制**来做一点小小的升级实现**流量削峰**
# 升级的架构设计
根据上面的服务架构图本篇文章将对**后端服务部分**做升级
引入`SpringCloud`及`RocketMQ`实现人脸考勤部分的并发架构
这里引入的**消息中间件**是因为业务环境非常合适:
- 设备考勤记录产生是**消息生产者**
- MQ是**消息储存者**
- 考勤记录存档为**消息消费者**
对吧?由于`RocketMQ`的超高性能,对于这点消息吞吐已经是绰绰有余,甚至可以换成`RabbitMQ`(支持AMQP协议)也是可以的,总之对于一个架构来说任何一个部分都是被**解耦出去**的,都是可更换及**横向扩展**的
`RocketMQ`性能测试分析的文献:
- [RocketMQ 高性能揭秘](https://zhuanlan.zhihu.com/p/93602392)
- [rocketMq和kafka的性能对比和原理](https://www.cnblogs.com/cai-cai777/p/10243981.html)
并且还有其他业务会被用到啊!比如**设备的自检**,各种**新闻展示图片的发布**,**配置的更改**,**学生人脸数据的更新**等等等等,所以说引入消息中间件是非常有必要的,可以将项目服务提升性能及进行大规模**降藕解耦**,所以本文也只是对该部分服务的一个简单升级,以及后续解耦的启发!
## 设计结构
想了一会,那就开始设计了↓

就这?就这。

架构设计重在思考,想的多了,写的就少了
### 当然上图还有一些部分没有给大家画出来:
- 注册中心
- 接口鉴权中心
- 缓存服务
- 配置中心
- 等等
### 要注意的点:
对于考勤消息记录的处理保存要考虑到几个点
- 消息处理服务的幂等性
- 确保考勤消息的成功消费
- 确保考勤消息消费的实效性(待定)
### 下篇博客上代码!
因为1k字了
[架构设计]有关线下多台机器并发上传签到数据的设计架构[RocketMQ]