1、背景

我目前公司研发中心担任软件研发负责人，研发中心分为3组，总共有30多人。研发中心主要开发各类生产辅助工具，比如巡检、安全教育等系统。系统不对外，只在公司内部使用。

就我个人来说，作为研发负责人，管理职能自然少不了，也做一部分产品经理的工作，包括现场调研、用户访谈、流程梳理等。在架构方面，也承担一部分的架构工作，包括开发前期的容量估算、部署架构、中间件选型、数据库选型（工业场景，个别分、子公司对数据库有要求）等。当然也包括对上的技术架构的汇报。说来惭愧，除了汇报工作，其他架构工作只做了一两次。主要原因是各分、子公司除了业务不同外，用户规模都差不太多。做完第一个系统后，其他系统架构都参照模仿。

2、系统介绍

我简单说一下我们的巡检系统。需求相对简单，主要流程描述如下：在生产现场24小时生产，有专门的巡检工，每隔一个小时到固定的地点（巡检点），查看水、电、设备、环境温度等数据。在巡检点的附近，都挂着一个纸质表格，巡检工将查得的数据填入，并签字确认。如果数据异常，立即通过电话上报。

我们的巡检系统，就是将上面的流程实现，同时，加上了任务提醒、隐患统计、隐患核销等功能。巡检工手持巡检仪，到现场扫RFID卡片定位巡检点，完成巡检工作。顺便说一下，巡检仪是一个类似于手机的设备，里面跑安卓系统，我们的应用端就安装在巡检仪上。

技术架构如下图：

这是目前巡检系统的架构图，向背景中说的一样，我们大部分系统都采用雷同的架构。服务数量最多的时候也不超过10个。各个服务用docker部署，需要查错时，登录docker，下载日志，然后人眼搜索。

服务间的相互调用几乎没有，使用的单体数据库，也不存在事务问题。nginx中配置各服务的访问规则，nginx未做保活。开发采用springboot框架，dao层使用mybatis，也有个别系统使用jpa的。系统部署在各分、子公司内部机房。

以上系统到现在为止相对稳定，除了功能升级外，技术上未出现大的升级改造。

3、思考

目前技术圈，“三高”几乎是日常讨论的话题，好像不做个高并发都不好意思跟人打招呼，这也是我目前考虑个人问题的原因。
另外，项目中也没有埋点，没有监控数据分析用户行为。