代码结构-日志如何做到提高研发效率

                         代码结构-日志如何做到提高研发效率

曾经有一项调查，当一个程序员到新公司或者接手项目最怕的事情是什么，超过 90% 的人的都认为最怕接手其他人的项目。从心理学角度来看，这个结果非常正常，害怕是因为对即将接手项目的未知，不清楚项目如何启动，不清楚代码是如何分层。大家试想看，当一个单体应用被划分为 N 多个服务的时候，每个服务启动方式，代码层次各不相同，如何去维护呢？所以微服务启动阶段，首先要做的事情就是工程结构标准化和自动化，让研发人员的重点精力去做业务，而不是去搭建框架。因此基于 velocity 自定义了一套微服务代码自动生成框架，研发人员设计好表结构之后，框架根据表结构自动生成服务代码，包含 API 接口，实现类，DAO 层以及 Mybatis 的配置文件，类的名称，包名、module 名称都有严格的定义。以用户服务为例，生成后的代码格式如下：

basics-userservice
basics-userservice-api
basics-userservice-business
basics-userservice-façade
basics-userservice-model
basics-userservice-service

为了让研发效率更快，架构更清晰，又从架构层面把代码再拆分为聚合服务层和原子服务层，每一层对应的功能不一样。

聚合层：收到终端请求后，聚合多个原子服务数据，按接口要求把聚合后的数据返回给终端，需要注意点是聚合层不会和数据库交互；

原子服务层：数据库交互，实现数据的增删改查，结合缓存和工具保障服务的高响应；要遵循单表原则，禁止 2 张以上的表做 jion 查询，如有分库分表，那么对外要屏蔽具体规则。

需要说明的是，聚合层和业务比较贴近，需要了解业务更好的服务业务，和 App 端交互非常多，重点是合理设计的前后端接口，减少 App 和后端交互次数。原子服务则是关注性能，屏蔽数据库操作，屏蔽分库分表等操作。

系统日志：

日志记录的详细程度直接关系到系统在出现问题时定位的速度, 同时也可以通过对记录日志观察和分析统计，提前发现系统可能的风险，避免线上事故的发生。对于服务端开发人员来说，线上日志的监控尤其重要，能够通过日志第一时间发现线上问题并及时解决。然而通过观察收集后的日志信息内容的时候才发现日志规范这块内容一直都没有重视过，记日志永远看心情，日志记录的内容也是凭感觉。因此在实施微服务的之前，必须要先确定日志的规范，为了便于后面的日志采集、处理和分析。例如统一约定日志格式如下：

时间|事件名称|traceID|耗时时间|用户 ID|设备唯一标识|设备类型|App 版本|访问 IP|自定义参数
时间：日志产生时候系统的当前时间，格式为 YYYY-MM-DD HH:MM:SS；
事件名称：预先定义好的枚举值，例如 Login、Logout、search 等；
TraceID：当前请求的唯一标识符；
耗时时间：当前事件执行完成所消耗的时间；
用户 ID：当前登陆用户的唯一 ID，非登陆用户为空；
设备唯一标识：当前设备的唯一标识，假如某用户登录前开始操作 App，这个时间记录下设置唯一标识后，可以通该标识关联到具体用户；
设备类型：当前设备的类型，如 Android 或者 iOS；
App 版本：当前访问设置的 App 版本号；
访问 IP：当前设备所在 IP 地址；
自定义参数用：自定义参数，参数之间使用 & 分割，例如 pid=108&ptag=65

工程结构、代码框架和日志在开发过程中最容易被忽略的，但却非常的重要，前期合理的规划有助于规模化推广的时候减轻压力，在规划阶段要重点关注以下内容：

代码未编工具先行；
统一微服务工程结构；
统一服务启动方式（jar war）；
统一缓存调用方式（架构封装统一提供 jar 包和底层存储无关）；
统一 MQ 调用方式（架构封装统一提供 jar，和具体 MQ 类型无关) ；
统一日志格式；
统一多服务依赖调用方式 (串行调用方式、并行调用方式）；
统一熔断、降级处理流程；