简介： 这个项目主要是用作管理深圳智慧杆设备的IOT平台，包含项目规划、项目审核工作流、杆体以及设备信息管理、监控中心的设备地图、设备出入库管理、设备维护工单工作流、巡检维护人员的轨迹记录等功能。 监控中心地图可以查看杆体的位置以及上面的设备信息，同时有告警信息提示。 我主要负责对接设备的数据读取以及巡检工单模块。 主要技术栈（后端）： SpringBoot Spring Cloud Spring Cloud Gateway Spring MVC Mybatis Redis Nacos MySQL Kafka MongoDB Activiti Nginx 技术难点： 1. 设备数据读取主要是通过Kafka队列传输，后端配置监听器接收队列消息，根据不同设备按照协议解析数据，存储在时序数据库中。提供给系统各模块的数据统计、数据分析、图标展示等功能使用。 2. 巡检工单模块主要包含了两块，一个是配置巡检计划，另外一个是巡检工单的管理以及执行。 2.1. 巡检计划除了巡检的基础信息以外，需要配置巡检频率，通过定时器功能定期生成需要执行的巡检工单。 2.2. 巡检人员在APP登录进行工单执行，APP通过Websocket把定位信息传输到后端，还有巡检的各种操作，例如完成巡检、挂起、转派给其他巡检人员、取消工单等。因为定位信息有时候会不准确，所以需要进行点位纠错，把轨迹信息存储在时序数据库中。后台可以在巡检工单详情中查看该工单的巡检轨迹。

简介： 1. 这个系统主要功能是管理学生教师档案资料、以及行为评分管理，是现代智慧校园电子化管理系统。系统分为和谐班级管理系统、心理健康管理系统、综合素质评价系统三个子系统。 2. 和谐班级管理系统系统是指管理学生，是通过系统流程的设定和不同场景的应用，和谐班级管理系统、心理健康管理系统中有关学生的信息统一汇总到综合素质评价系统，形成学生档案。 综合素质评价系统是学生平时行为奖罚的一个量化系统，不同的教职角色可以根据情况对应学生的行为进行添加加分项和减分项。 3. 心理健康管理系统主要是一个档案管理系统，管理学生的心理档案。 4. 我主要负责以下3个功能的开发：一个是归档功能，学生升班或者毕业需要对数据进行归档，第二个是是不同校区之间的数据需要进行隔离，第三个是班级数据档案的增删改查。 技术难点： 1. 项目的技术难点主要是归档功能和校区数据隔离。 2. 校区数据隔离最后采取的是分库方案，而实现方案是采用了动态数据源。用户登录的时候需要先选择登录的校区，登录成功后会把校区进行存储在登录信息中，其中包括了该用户应该读取的数据库信息。动态数据源包装了所有校区的数据源，根据当前用户的校区信息，切换到具体的数据源。 3. 归档系统需要同时对大量数据库表进行写入操作，其中必须保证其数据一致性，这是一项非常繁重的功能，我采用了组合模式和模版方法模式，同时利用了Spring容器的便利来解决代码上的繁重，通过相当简单清晰的代码就可以实现数据库表归档的执行顺序，以及增删需要归档的数据库表等功能。 3.1. 定义了归档执行器的父类，这个类定期归档数据升级的流程，如判断哪些数据需要归档、新增历史归档数据到历史表、清理当前表的已归档数据等。这个类应用了模版方法模式。 3.2. 归档执行器需要注册到Spring容器中，并使用@Order注解来编排执行顺序。 3.3. 定义将所有执行器按顺序执行的组合归档执行器，里面也有批量执行相关的处理流程，完成整个归档功能的生命周期，这个类使用了组合模式。

简介： 1. 这个项目是青少年速算实时竞赛的应用，涵盖了赛程配置、自动题目生成、选手报名、实时比赛等功能。 2. 比赛组委会可以在系统设定比赛项目规则，如得分规则、题目生成难度等，系统根据用户设定的规则自动生成题目，用户可以预览题目，并且在生成题目的基础上进行微调 。 3. 选手通过报名端进行分组报名，可以在app中进行训练，比在比赛当天使用APP进行实时比赛，可以后台进行比赛进程的管理以及比赛选手状况监控，和比赛结束后提供数据统计服务。 4. 我在项目中担任开发组长的职责，负责搭建项目基础框架，以及核心的比赛监控模块的实现。 技术难点： 1. 这个项目比赛核心的攻克关有两个，一个是题目生成模块，需要根据用户参数配置，生成与之符合的速算题目，其次是能够与选手端APP和后台管理端PC实时交互和数据状态同步的中控台模块。 2. 题目生成模块在逻辑上其实没有什么难度，无非就是根据需求生成对应的题目，难点主要在于怎么把代码分层次编排，便于后期维护以及降低bug排查难度。这里我主要使用工厂模式，根据不同的情况返回题目实例。 3. 比赛监控通讯模块是比较复杂的模块，要求PC端能监控APP选手端的状态，PC端能够发布命令到APP，并且比赛在不同的阶段有不同的行为和操作。 3.1. 使用了事件监控机制。监控台的一切操作皆定义为事件，因为同一个操作有可能触发点在完全不同的地方，使用事件监控机制有效降低了不同类之间的耦合关系。 3.2. 比赛阶段管理使用了状态机（Statemachine）。状态机使得状态之间的转移、事件的触发，这些复杂机制的编排变得容易，并且便于维护。状态机在不同的阶段会发布不同的事件，同一个事件，事件监听者可以根据状态机（也就是比赛阶段）的当前状态作出不同的反应，实现了状态中心化管理。 3.3. PC端和APP端通讯使用的是websocket和stomp的实时通讯协议。中控台的数据为websocket主动发送，并非前端主动请求，这样后端可以根据比赛阶段的不同向前端发送对应的数据，让前端根据比赛阶段渲染不同的页面。比赛监控台可以向APP端发布命令也是通过websocket向APP端发送消息来实现的。 3.4. 使用了Spring的ApplicationContext的父子继承功能。因为有可能在比赛有可能会同时进行，为了实现数据隔离，ApplicationContext的父子继承功能，这样既可以利用Spring容器装配和自动配置类的便利性，同时类的处理上能够只考虑当前比赛的环境，使用相对简单清晰的代码来编写业务功能，而不需要担心数据污染的问题。 3.5. 适配Redis内存模式。在功能开发完成后，使用了装饰者模式为比赛监控台提供了Redis支持，使得系统能够以集群模式部署。就是原本读写数据的方式是读取本地内存，通过装饰者模式让类数据读写方式变成了读写Redis。