第四节 工程结构规约笔记
分层目的
隐藏下层业务逻辑的复杂性
提高系统复用度,扩展性,可维护性。
*计算机领域的任何问题都可以通过增加一个中间层解决(java跨平台:不同平台对应不同的虚拟机统一标准)
MVC框架
M:Model 。对象和逻辑业务处理
V:View 。视图
C:Controller 。控制层
推荐分层结构
表现层:终端显示层,开放API层,请求处理层(WEB层)
业务逻辑层:业务逻辑层(service层),通用逻辑层(manager层,比如通用的三方manager,发短信,rocketMQ等)
数据持久层:数据持久层(DAO),数据存储系统,第三方服务(会有防腐层,将第三方服务的状态码,数据结构做转换处理),外部数据接口
分层规约
异常处理
DAO层:异常类型很多,不需要打印日志。
Manager/Service层:必须记录出错日志到磁盘,尽可能带上参数信息,保护案发现场,跨系统发送请求必须记录日志。
Web:决不能网上抛异常,应该跳转到友好错误页面,友好的错误提示信息。
开放接口层:API,将异常处理成错误码和错误信息方式返回。
领域模型
DO(Data Object):与数据库表一一对应。
DTO(Data Transfer Object):数据传输对象,service/manager向外传输的对象,需要序列化。
BO(Business Objet):业务对象,可以有Service层输出的封装业务逻辑的对象,不需要序列化,可以封装多个DO。
Query:数据查询对象,各层接受上层的查询请求。禁止使用Map。
VO(View Object):显示层对象,通常是web向模板渲染引擎层传入的对象。
Java项目构建工具
传统:ant
主流:maven
新兴:gradle (android用的比较多)
Maven的主要功能
依赖管理,规范目录结构,完整的项目构建阶段,支持多种插件
工程坐标
groupId:组织ID。格式:com.{公司/BU}.业务线.子业务线,最多四级。
artifactId:项目ID。格式:产品线名-模块名。语义不重复不歧义,先到版本库查询确保不出问题。
version:版本号。格式:主版本号.次版本号.修订号。
主版本号:产品方向改编,或者大规模API不兼容,或者架构不兼容升级。
次版本号:保持相对兼容性,增加主要功能疼,影响范围极小的API不兼容修改。
修订号:保持完全兼容,修复bug,新增次要功能特性等。
Maven的依赖仲裁
按照DependencyManager版本声音进行仲裁,在父工程中定义版本仲裁。
如无仲裁声明,则按照依赖最短路径确定版本
若路径相同,则按照第一声明原则优先。
如果多版本冲突,可以用exclusions排除。
二方库
一方库:本工程中的各模块的相互依赖
二方库:公司内部的依赖库,一般指公司内部的其他项目发布的jar包。
三方库:公司之外的开源库,如apache,google,alibaba等发布的依赖。
二方库引用规约
1.线上应用不要依赖SNAPSHOT版本(快照版本,随时可能更新,版本号不变)
2.正式发布的类库必须去中央仓库查证,使RELEASE版本号有延续性。
3.正式发布的类库版本号不允许覆盖升级。
4.二方库的新增或升级,保持除功能点之外的其他jar包仲裁结果不变。
5.二方库里定义的枚举类型,参数中可以使用,返回值中不允许使用。(出现过一些问题)
6.依赖与一个二方库群时,必须定义一个统一的版本变量,避免版本号不一致。
7.禁止在依赖中出现相同的GroupId,相同的ArtifactId,但是Version不同。
二方库引用建议
1.底层基础技术框架、核心数据管理平台、或近硬件端系统谨慎引入第三方实现。
2.所有版本仲裁使用dependencyManagement语句块。
3.二方库不要有配置项
4.不要使用不稳定的工具包或者Utils类。
二方库发布原则
精简可控原则
1.移除不必要的API和依赖
2.只包含Service API以及必要的工具类
3.如果依赖其他二方库,尽量provided引入
4.无log具体实现,只依赖日志框架
稳定可追溯原则
1.记录每个版本的变化,不要覆盖升级。
2.标明二方库的维护者。
3.源码的位置要让人知道在哪。
4.公共二方库的行为不变,保持二方库稳定。
TCP/IP
在多个不同网络间实现信息传输的协议簇。
三次握手,四次挥手均是为了保证双方功能正常,能接收和发送信息。
服务器会向很多其他服务器发送请求。所以需要减少time_wait时间提高效率,释放socket资源(缺乏,默认1024),端口资源(不缺乏)。
Linux服务器的fd可以设置高一些,直接设置到65535