# 前言 >​ 最近比较闲，没什么活，并且利用这一段时间学习了部分有关`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字了