1、背景
我目前公司研发中心担任软件研发负责人,研发中心分为3组,总共有30多人。研发中心主要开发各类生产辅助工具,比如巡检、安全教育等系统。系统不对外,只在公司内部使用。
就我个人来说,作为研发负责人,管理职能自然少不了,也做一部分产品经理的工作,包括现场调研、用户访谈、流程梳理等。在架构方面,也承担一部分的架构工作,包括开发前期的容量估算、部署架构、中间件选型、数据库选型(工业场景,个别分、子公司对数据库有要求)等。当然也包括对上的技术架构的汇报。说来惭愧,除了汇报工作,其他架构工作只做了一两次。主要原因是各分、子公司除了业务不同外,用户规模都差不太多。做完第一个系统后,其他系统架构都参照模仿。
2、系统介绍
我简单说一下我们的巡检系统。需求相对简单,主要流程描述如下:在生产现场24小时生产,有专门的巡检工,每隔一个小时到固定的地点(巡检点),查看水、电、设备、环境温度等数据。在巡检点的附近,都挂着一个纸质表格,巡检工将查得的数据填入,并签字确认。如果数据异常,立即通过电话上报。
我们的巡检系统,就是将上面的流程实现,同时,加上了任务提醒、隐患统计、隐患核销等功能。巡检工手持巡检仪,到现场扫RFID卡片定位巡检点,完成巡检工作。顺便说一下,巡检仪是一个类似于手机的设备,里面跑安卓系统,我们的应用端就安装在巡检仪上。
技术架构如下图:
这是目前巡检系统的架构图,向背景中说的一样,我们大部分系统都采用雷同的架构。服务数量最多的时候也不超过10个。各个服务用docker部署,需要查错时,登录docker,下载日志,然后人眼搜索。
服务间的相互调用几乎没有,使用的单体数据库,也不存在事务问题。nginx中配置各服务的访问规则,nginx未做保活。开发采用springboot框架,dao层使用mybatis,也有个别系统使用jpa的。系统部署在各分、子公司内部机房。
以上系统到现在为止相对稳定,除了功能升级外,技术上未出现大的升级改造。
3、思考
目前技术圈,“三高”几乎是日常讨论的话题,好像不做个高并发都不好意思跟人打招呼,这也是我目前考虑个人问题的原因。
另外,项目中也没有埋点,没有监控数据分析用户行为。