前言

      目前的交付底座有点老，而且集成的有点杂，计划是要升级下，先说想法，看领导做不做。

1 业务平台定位

      我们的愿景：通过物联平台赋能，让数据产生价值。
      为客户提供可视化的平台（数据价值依托我们的业务平台展现），客户根据自身品牌定位、业务领域，通过我们的物联平台选择物联设备整合数据，依托我们的物联平台在业务平台端打通上下行，通过规则引擎、计量计费等等将业务信息化、差异化、细分，让数据起飞，帮助客户实现信息化价值。

1.1业务平台的具体定位：

1、 交付底座
2、 业务展示数据支撑
3、 物联网平台“客户端”
4、 硬件、业务配置端、数据展示端
以下简称“交付底座”。

2现状

      经过近10年的行业沉淀、业务发酵、技术成长，交付底座在支持各行各业的业务日积月累中，相关依赖版本、JDK等，没有与时俱进的更新。而且除了主分支，基础代码也在不断分裂。在技术的发展中，很多依赖已经不维护了，甚至有的还爆出了安全漏洞。所以，交付底座到了需要更新的时候、业务到了需要细分的节点。

3优化目标

1、 更新springboot到最新版本
2、 更新相关依赖到最新版本
3、 业务分化上微服务（这点受各种资源限制，可能不太现实，那么退而求其次）
4、 业务细分模块化
5、 大数据模块剥离，数据查询请求数据交换中心（数仓）
6、 关键模块可以考虑重构

4优化思路

4.1架构优化图：

                                                                        架构图一

                                                                        架构图二

4.2优化说明

      这里对整体架构理解可能有误，但是不影响本次优化。其实就想优化引入数据交换中心（数仓）模块，方便大数据统一管理，全生命周期记录、各状态大数据分析。
以上2个优化方案，个人倾向方案二，解析层就可以将数据存储入仓，后面可以做数据量比对，或使用flink等流处理引擎从上报源头做实时解析，实现数据全生命周期记录等等，用flink可以做的事情还挺多的。计量、计费、规则、场景驱动等等，真的是可以让数据各维度产生价值。

5优化方案

5.1模块架构拆分设计：

以上是微服务架构，如果不采用微服务，那模块还是按照服务层拆分，API层统一。

5.2技术优化点

结合目前交付底座，有依赖升级、技术升级、实现升级等等，具体如下：
1、 springboot升级到3
2、 JDK级联升级到17
3、 MybatisPlus升级到最新版本
4、 Websocket前后端信息交互不采用websocket直连，重构为通过stomp协议
5、 升级规则引擎，采用最新且性能更强的js引擎Graalvm
6、 数据源不用阿里的druid，直接用springBoot默认的HikariCP
7、 容器不用内置的tomcat，改用性能更强的undertow
8、 增加连接数据交换中心（数仓）模块
9、 重构ORM使用JPA、tk的业务代码，统一使用MybatisPlus
10、 要么拆分自动任务到LTS或PoewrJob第三方自动任务模块，交付底座只提供API业务接口
11、 如果想自动任务个性化管理，可以自己通过Quartz实现任务配置、调度、执行
12、 不用security安全管理，自己实现token权限机制，区分多端请求（更方便对接）
13、 废除有侵入的swagger接口注释方式，统一编码写javadoc注释。统一采用idea + apifox uploader + apifox方式
14、 Kafka、ES等数据消费都转移到数据交换中心做处理（数据交换中心可以接入flink做处理）
15、 移除ETL，数据计算由数据交换中心承担
16、 信息推送服务移除到信息服务中心处理
17、 如果需要，健康检查用springBoot提供的actuator
18、 相关依赖数据库开启binLog，方便flink使用CDC数据处理

6总结

      实际上，这就是物联网 + 业务交付底座的基本架构，我的想法是要优化成这样，就我们目前的资源看，估计不现实。那位东家有资源，可以参考下。
      就写到这里，希望能帮到大家，uping！！！