目录

规范分别从上线前，上线中，上线后三个阶段：

上线前：

上线中：

上线后：

规范分别从上线前，上线中，上线后三个阶段：

上线前：

1、  确保测试环境及预发布环境测试通过，才允许上线；

2、  提前知晓关联系统负责人关注各自系统（以咚咚或邮件的方式）；

3、  提前梳理好本次上线需要修改的配置文件等信息，提醒开发进行配置备份；

4、  提前准备好本次上线验证所需的测试数据，线上测试商品必须打测试标识，且在测试分类下（必须使用白名单下单）；

上线中：

1、  测试和开发必须结对上线；

2、  监督开发需先下线机器，再进行任务发布；

3、  单台机器验证通过后，才允许开发对该分组下的其他机器进行任务发布；

4、  以分组为单位，依次进行上线操作；

5、  上线功能着重测试，关联的核心系统和业务场景必须回归测试；

6、  线上功能验证的同时，提醒并监督开发实时关注后台日志及系统情况；

7、  配置文件修改上线，必须监督至少两名开发人员一起检查修改配置信息；

8、  实时关注后台日志，若出现报错、异常等情况，立即通知相关开发人员迅速定位问题；

9、  实时监控risk数据信息，若出现业务量下降等情况，立即通知相关开发人员迅速定位问题；

10、 重点关注UMP关键监控点的调用次数、可用率、性能、端口存活等情况；

11、 重点关注JSF接口是否正常；

12、 若涉及JMQ，则重点关注消息是否有积压、重试等情况；

13、 若上线导致重大影响，需要求开发立即进行回滚；

上线后：

1、  进行整体系统流程验证；

2、  持续关注UMP、Risk、JSF、JMQ、后台日志等相关监控系统信息（至少15分钟），各系统监控信息均保持平稳，则代表上线成功；

3、  邮件回复或通报本次成功上线的内容；

4、  评估上线过程中测试所用的数据是否需要还原或清除；

国标《电动汽车远程服务与管理系统技术规范》解读三部曲：

系统架构及协议概述： https://blog.csdn.net/XiuHua_Wu/article/details/113530169
车载设备设计规范： https://blog.csdn.net/XiuHua_Wu/article/details/113530895
协议数据包结构及定义（重点）：https://blog.csdn.net/XiuHua_Wu/article/details/113732636

本文为国标的阅读笔记第1篇：

•  国标：《电动车远程服务于管理系统技术规范 第3部分：通讯协议及数据格式》GB/T 32960.3-2016 http://c.gb688.cn/bzgk/gb/showGb?type=online&hcno=674DE45C0AD3DE2CD75B9C4CD8ED57C1
• 若要落实到具体实现，还请仔细阅读国标。

目录

《电动汽车远程服务与管理系统技术规范》

适用范围及系统架构

通讯协议及数据格式

范围

术语与定义

一般要求

通讯连接

《电动汽车远程服务与管理系统技术规范》

1. 《电动汽车远程服务与管理系统技术规范 第1部分：总则》GB/T 32960.1-2016、http://c.gb688.cn/bzgk/gb/showGb?type=online&hcno=0C4E83CE82045550C147C782750B221A
2. 《电动汽车远程服务与管理系统技术规范 第2部分：车载终端》GB/T 32960.2-2016 http://c.gb688.cn/bzgk/gb/showGb?type=online&hcno=D14B66D67EF2F4AFD71C1285B9BA3FDC
3. 《电动车远程服务于管理系统技术规范 第3部分：通讯协议及数据格式》GB/T 32960.3-2016 http://c.gb688.cn/bzgk/gb/showGb?type=online&hcno=674DE45C0AD3DE2CD75B9C4CD8ED57C1

适用范围及系统架构

以下车型的车载终端、车辆企业平台和公共平台之间的数据通信。

1. 纯电动汽车
2. 插电式混合动力电动汽车
3. 燃料电池电动汽车

电动汽车远程服务与管理系统， remote service and management system fot electric vehicles：对电动汽车信息进行采集、处理和管理，并为联网用户提供信息服务的系统

组成：

1、公共平台， public service and management platform：国家、地方政府或其他指定机构建立的、对管辖范围内电动汽车进行数据采集和统一管理的平台

• 具备整车企业使用的信息录入及维护功能，用于企业录入车辆静态信息及上报故障与报警的处置措施、处置进度和处置结果。公共平台应对企业录入信息进行审核。
• 从企业平台获取车辆行驶、充电等运行数据，进行监管和相关数据分析
• 公共平台与企业平台的数据传输可加密处理
• 具有故障和报警的处置措施、处置进度和结果的统计和分析功能
• 公共平台之间应具备数据交换的功能

2、企业平台， enterprise service and management platform：整车企业自建或委托第三方技术单位，对服务范围内的电动汽车和用户进行管理，并提供安全运营服务与管理的平台。

• 应具备车辆故障监控和安全报警的功能。根据可能对车辆造成的安全隐患严重程度，对故障和报警进行分级管理，不同的级别应设置相应的处置措施。
• 应定期将故障和报警的处置措施、处置进度和结果上报至公共平台。
• 在车辆出现GB/T 32960.3规定的3级故障或报警时，整车企业应具备提供动力蓄电池单体电池电压和各个电池包探针温度数据的能力，确保故障相关数据的完备。

3、车载终端， on-board terminal：安装在电动汽车上，采集及保存整车及系统部件的关键状态参数并发送到平台的装置或系统。车载终端应按照GB/T 32960.2的要求，从车辆上采集整车及各个部件的数据，参数范围至少要包含GB/T 32960.3的要求，并将数据发送到企业平台。

通讯协议及数据格式

范围

电动车汽车远程服务与管理系统中协议接收、通讯连接、数据包结构与定义、数据单元格式与定义

术语与定义

1. 客户端平台，client platform：平台间进行数据交互时，作为车辆数据发送方的远程服务与管理平台
2. 服务端平台，server platform：平台间进行数据交互时，作为车辆数据接收方的远程服务与管理平台
3. 注册，register：客户端平台向服务端平台提供平台和车辆静态信息，用于平台和车辆身份验证的过程
4. 上行，upstream：从客户端到服务端的数据传输方向
5. 下行，downstream：从服务端到客户端的数据传输方向
6. 车辆登入，vehicle login：客户端向服务端上报车辆状态信息前进行登入认证
7. 车辆登出，vehicle logout：客户端平台因故停滞数据传输并从服务端平台登出

一般要求

协议结构：TCP/IP网络控制协议作为底层通信承载协议

通讯连接

1、连接建立

2、信息传输

3、统计信息上报

统计数据应以FTP、HTTP或HTTPS方式传输到服务端平台。

4、连接断开

• 服务端平台与客户端平台的会话连接断开情况：TCP连接断开。
• 客户端平台与服务端平台的会话连接断开情况：
  • TCP连接中断
  • TCP连接正常，达到重新发送次数后仍未收到应答

5、补发机制

• 当数据通信链路异常时，客户端平台应将实时上报数据进行本地存储。
• 在数据通讯链路恢复正常后，在发送实时上报数据的空闲时间完成补发存储的上报数据。
• 补发的上报数据应为7日内通信链路异常期间存储的数据，数据格式与实时上报数据相同，并标识为补发信息上报（0x03）

业务系统日志记录规范

注意

1. 应用中应该充满了日志记录信息，日志甚至比逻辑代码还要多；
2. 集成 seluth ，开启消息链路；不开启日志上传,不集成 zipkin;
3. 应该避免日志记录过程中出现异常，比如 log.debug(requst.getid) ,这条日志记录之前一定要判断 request 是否为空；日志记录中使用的信息一定时稳定的，提前准备好的，最好不是专门为此次日志记录专门准备的；
4. 日志应只记录标识性信息，具体信息从具体存储里取；
5. 日志应该同时支持人和计算机都可以读；人可读的意思的，要成句子；计算机可读的意思是要有明确的分割符，可以支持正则等工具抽取其中有意义的信息；
6. service 或 manager 层内有 if…else 或者 switch 这样的分支时，要在分支的首行打印日志，用来确定进入了哪个分支；
7. 对于 trace / debug / info 级别的日志输出,必须进行日志级别的开关判断。warn 和 error 不用开关判断；

日志级别 trace 和 debug

测试环境要实现的目标是，不需要重新完整的调试程序，可以直接定位到出问题的 service 内的逻辑分支，最多在进行一次小范围的测试；
要实现这个目标，需要记录 service 入参出参，debug级别的日志，只在非生产环境中使用；

日志级别 info

1. info级别的日志只在 service 层和 manager 层存在，体现业务逻辑运行的路径，工具类等的不要记录；
2. Service 方法中对于系统/业务状态的变更处记录
3. 主要逻辑中的分步骤记录

日志级别 warn

1. 有容错机制的时候出现的错误情况，有异常，但是你有 Plan B;
2. 业务异常的记录,比如:当接口抛出业务异常时，应该记录此异常;
3. warn 日志级别来记录用户输入参数错误的情况,避免用户投诉时,可以追溯信息;

日志级别 error

error 级别只记录系统逻辑出错、异常或者重要的错误信息。
异常在程序中，一般会沿着调用链路，层层上抛，直到service层，在最终处理异常的地方记录log.error(e)；log.error和往外抛异常，不应该同时出现；

错误异常

错误异常分为程序异常（系统异常）和业务异常；

程序异常会导致程序不能正常执行；业务异常不会，业务异常的处理属于业务逻辑的一部分；
ERROR 级别的日志，一出，意味着开发运维人员要介入了，要操作确认一下东西，要维修一些东西了；

业务系统开发过程中，不需要 log.error 记录异常，让框架和容器（Tomcat等）来做；
业务异常的需要开发者开发对应的异常处理逻辑，业务异常不是程序异常；比如用户登陆失败；
业务异常的处理属于正常的业务逻辑，不应该log.error，不重要的可以不log，重要的可以使用log.warn记录，避免用户投诉时,可以追溯信息;

数据库或者kafka在应用启动时连不上是如何处理的，在应用运行过程中是如何处理的？启动时，依赖的插件有问题，应用直接启动不起来；如果应用已经启动起来了，触发到跟其交互时，抛出异常，程序还是正常执行；

ExceptionHandler的默认的处理逻辑

ExceptionHandler的默认的处理逻辑不要吃掉所有的异常，log.error打印出来，这个逻辑主要用来处理程序异常，业务异常都应有对应的处理逻辑；

@ExceptionHandler(Throwable.class)
@ResponseBody
public String handle(Throwable e) {
	log.error(e.getMessage(),e);
	//构造返回信息
	return e.getMessage();
}

程序异常

各个组件的异常信息可以各自处理；比如SQLExcption，需要如果SQL 出异常，异常的信息中会有SQL相关的信息，如果直接返回给前端，会造成安全问题，前端对此异常也不关心，而后端开发者关心的信息应该都记录在日志中，以方便分析问题；

@ExceptionHandler(SQLException.class)
@ResponseBody
public String handle(SQLException e) {
	log.error(e.getMessage(),e);
	//构造返回信息，记得脱敏
	return e.getMessage();
}

各个组件的SDK一般都会有自己的异常体系；可以根据情况直接对顶级异常类，或者典型的异常子类进行处理；
接入外部组件时，首先分析其SDK的异常体系，编写对应的ExceptionHandler

org.apache.kafka.common.KafkaException
org.springframework.kafka.KafkaException
java.sql.SQLException

链路追踪

多个进程间的日志联动
集中式日志存储系统的存在，让在一个入口处理业务系统的日志成为了可能，产生了高级的用法，链路追踪；
用户的一个动作触发的在各个系统的所有的执行逻辑，使用一个标识将其联系起来，开发人员分析的时候，可以根据此标识查询所有相关的日志，哪里出问题，一目了然；

远程调用

远程调用的plan b，就是熔断降级里面的Plan B；
外部接口部分,客户端请求参数(REST/WS),调用第三方时的调用参数和调用结果使用info

如果出异常，调用过程异常或者返回错误码，根据情况选择抛出异常或者启用Plan B；
抛出异常意味着程序正常流程执行结束，需要处理这个异常，warn记录此异常，然后返回用户结果；
Plan B意味着程序还可以正常执行下去，warn记录发生了此事件，出现异常转入Plan B；

远程调用过程中出异常，意味着需要开发人员介入，应该记录 error 级别的异常；
如果是返回的错误码是非成功执行的错误码，这时候应该根据错误码的级别抛出不同的异常，处理异常的地方根据远程调用的接口的重要程度评估使用不同的日志级别。

验证日志

提交代码前，确定通过日志可以看到一个功能的整个执行流程，可以通过日志进行问题定位程序执行的路径；

参考

用JAVA日志来写诗
JAVA - 优雅的记录日志(log4j实战篇)
Alibaba Java Coding Guidelines
小白学习如何打日志
正确的打日志姿势
Java常用日志框架介绍