本文集中描述网管脱离uep引入springboot技术后的研发规范。

部署架构

为减少技术难度，网管在2017年只实现集中式部署。

目前第三方进程有如下

• mysql
• zookeeper(为dubbo服务)
• activemq

自研进程设计如下

• 控制台
• 主进程
• 设备进程
• APP进程
• 报表图表进程
• 北向进程

进程分工

受人力和进度的约束，暂时无法一次性实现，但是以下设计是大的方向。

控制台负责启动其他进程，管理其他进程的生命周期，为维护人员提供便利。

主进程作为最为核心的自研进程，首先启动，至少包含如下功能

• 所有用户的管理，包括管理员和消费者
• 所有设备的管理，包括停车和充电当中所用到的设备
• 所有钱的管理，负责钱的进和出，保留相关记录

简而言之，主进程是真正的主要的，核心的进程，对人财物做统一的管理。

设备进程管理所有的设备，在主进程之后启动，至少包含如下功能

• 连接所有设备
• 保存计费模板
• 对设备行为进行审计，记录和计费
• 记录告警和性能

注，如果是分层网管，那么设备进程分成上下两个

APP进程负责接入所有APP，对APP功能提供支持。

报表图表进程负责提供所有的报表和图表功能，其中报表指的是根据较为复杂的规则，生成较为复杂的表格，供用户使用。图表指的是根据较为复杂的规则，生成较为复杂的图表，供用户阅览。

北向进程，负责网管对外提供数据。

自研进程技术要求

下面的描述对所有进程都有效

• 进程都只能占用有限的服务器资源，进程必须有自我限制的手段
• 进程都要支持灵活的配置文件，方便部署和测试
• 进程都要支持打补丁，且打补丁之后，进程重启可以正常工作
• 进程都要尽量保证自身正常运行，不能无故停止运行和重启

控制台进程

下面描述控制台进程的职责

• 控制台进程需要首先启动主进程，然后再启动其他进程
• 非主进程的其他业务进程需要自己解决启动依赖
• 控制台进程接收业务进程主动查询当前进程运行状态
• 控制台进程主动向业务进程推送当前进程运行状态
• 业务进程需要主动向控制台进程推送自己的运行状态
• 控制台进程停止业务进程之前要通知对方做好相应准备

注，本文档只做技术要求，不做详细设计

业务进程技术要求

• 支持接受http请求，可以对外输出网页和json数据
• 支持发起http请求，获取json数据
• 支持接收和发起dubbo请求
• 支持连接mysql
• 支持接收和发送activemq消息
• 支持保存日志，便于故障定位
• 支持ecache，便于支持进程重启
• 支持tcp连接(设备通讯进程特有)

网页前端

• 由主进程提供登陆和主页框架
• 主页框架上方通过菜单项，进入各业务进程的网页
• 主进程提供管理员权限配置功能，各业务进程自己实现本进程内网页的权限控制

APP前端

• 所有APP的请求都由APP进程接受
• 沿用HTTP+JSON的通讯方式
• 通过第三方服务实现消息推送

版本管理

• 项目按时间来管理版本，各个进程按时间约定提供版本,原则上每月的15日和30日打标签
• 项目负责协商接口，明确计划，
• 工程网管新安装或者升级，原则上使用最近一次时间的版本，项目只负责打标签，不负责拉分支
• 开发人员利用git私服管理自己进程内代码的分支和版本，必须具备对外提供工程补丁的能力

版本升级

• 进程负责人制作进程升级包，项目负责实施
• 项目只接受以整个进程为单位的补丁，开发人员对补丁质量负责，项目安排人力做测试

工作量

• 单人单进程单目录存放代码，js和java都计算
• 当前工作量为最近三个月工作量的平均值

质量管理

• 结合工作量考核故障数量(最近六个月已解决的故障)
• 要求后台开发人员自测,提供自测后的代码覆盖率

进度管理

• 按进程按人跟踪进度
• 通过禅道管理任务进展

进程内模块

• 单个进程的功能应该按模块来划分
• 不同模块要用不同工程管理,有明显的api和service划分
• 单个进程内可以简化进程内模块访问流程，但原则上推荐用外部api访问
• 原则上不允许模块间直接用sql访问数据，数据要有一定的隔离性