工程结构规约

「这是我参与11月更文挑战的第3天，活动详情查看：2021最后一次更文挑战」

1.应用分层

1.1 目的

隐藏下层业务逻辑的复杂性
提高系统的组件化和可维护性

为什么要分层？

提升系统的可扩展性、可维护性
分工协作效率高

1.2 分层异常处理

DAO层： 异常类型很多，不需要打印日志

Manager/Service层： 必须记录出错日志到磁盘，尽可能带上参数信息，保护案发现场

web层： 绝不能往上抛，应跳转到友好错误页面，友好的错误提示信息

开发接口层： 将异常处理成错误码和错误信息方式返回

1.3 分层领域模型

DO(Data Object): 此对象与数据库表结构一一对应，通过DAO层向上传输数据源对象

DTO(Data Transfer Object): 数据传输对象，Service或Manager向外传输的对象

BO(Business Object): 业务对象，可以有Service层输出的封装业务逻辑的对象

Query： 数据查询对象，各层接收上层的查询请求，注意超过2个参数的查询封装，禁止使用Map类来传输

VO(View Object): 显示层对象，通常是web向模板渲染引擎层传输对象

2. Maven

2.1 mavan的主要功能

依赖管理

规范目录结构

完整的项目构建阶段

支持多种插件

2.2Maven的依赖仲裁

按照DependencyManager版本声明进行仲裁
如无仲裁声明，则按照依赖最短路径确定版本
若相同路径，则按照第一声明优先原则

3. 二方库依赖

3.1 什么是二方库

一方库：本工程中的各个模块的相互依赖
二方库：公司内部的依赖库，一般指公司内容的其他项目发布的jar包
三方库：公司之外的开源库，比如apache、google、alibaba等发布的依赖

3.2 二方库的命名

GroupID：

格式：com.{公司/BU }.业务线 [.子业务线]，最多 4 级

说明：{公司/BU} 例如： alibaba/taobao/tmall/aliexpress 等 BU 一级；子业务线可选

ArtifactID：

格式：产品线名-模块名。语义不重复不遗漏，先到中央仓库去查证一下

正例：dubbo-client / fastjson-api / jstorm-tool

3.3 二方库中Version的命名方式

二方库版本号命名方式：主版本号.次版本号.修订号

主版本号： 产品方向改变，或者大规模 API 不兼容，或者架构不兼容升级

次版本号： 保持相对兼容性，增加主要功能特性，影响范围极小的 API 不兼容修改

修订号： 保持完全兼容性，修复 BUG、新增次要功能特性等

3.4 二方库引用规约

 1. 线上应用不要依赖 SNAPSHOT 版本
 2. 正式发布的类库必须去中央仓库查证，使 RELEASE 版本号有延续性
 3. 正式发布的类库版本号不允许覆盖升级
 4. 二方库的新增或升级，保持除功能点之外的其它 jar 包仲裁结果不变
 5. 二方库里定义的枚举类型，参数中可以使用返回值不允许使用
 6. 依赖于一个二方库群时，必须定义一个统一的版本变量，避免版本号不一致
 7. 禁止在依赖中出现相同的 GroupId，相同的 ArtifactId，但是不同的 Version

3.5 二方库发布原则

稳定可追溯原则

 1. 移除不必要的API和依赖
 2. 只包含 Service API、以及必要的工具类
 3. 如果依赖其它二方库，尽量 provided 引入
 4. 无 log具体实现，只依赖日志框架

稳定可追溯原则

 1. 记录每个版本的变化
 2. 二方库维护者
 3. 源码的位置
 4. 公共二方库的行为不变

4. 服务器设定

4.1 高并发服务器参数调优

1. 高并发服务器建议

调小 TCP 协议的 time_wait 超时时间
操作系统默认 240 秒后超时
在高并发访问下，可能无法建立新的连接

2. 调大服务器

调大服务器所支持的最大文件句柄数（File Descriptor，简写为 fd）
Linux系统一个连接对应一个文件描述符
Linux系统默认所支持最大fd数量为1024
连接数很大时很容易无法建立连接

3. JVM 环境参数设置

JVM 环境参数设置- XX:+HeapDumpOnOutOfMemoryError 参数
JVM 碰到 OOM场景时输出 dump 信息

4. JVM 的 Xms 和 Xmx 设置

JVM 的 Xms 和 Xmx 设置一样大小的内存容量
避免在 GC 后调整堆大小带来的压力

代码分层与版本依赖