T31实战-Day8：工程结构规约

一、应用分层
1.1分层目的

       应用分层的目的主要包括分工协作的效率更高；分层后更容易扩展和维护。

比较经典的分层结构有MVC等，MVC主要分为Model，Controller、View三层。

1.2最佳实践

根据实践的推荐的应用分层为DAO层、Service层、Web层、开放接口层4层。

DAO层：

       异常类型很多，不需要打印日志。

Service层

必须记录出错日志到磁盘，尽可能带上参数信息，保护案发现场，方便出现异常时定位解决问题。

       Web层

              绝不能往上抛异常，应跳转到友好错误页面，友好的错误提示信息。

开放接口层

       将异常处理成错误码和错误信息方式返回。

结构层次如下图



各个分层领域的模型对象，主要包括

DO （Data Object）：此对象与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。

DTO （Data Transfer Object）：数据传输对象，Service 或Manager 向外传输的对象。

BO （Business Object）：业务对象，可以由 Service 层输出的封装业务逻辑的对象。

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

VO （View Object）：显示层对象，通常是 Web 向模板渲染引擎层传输的对象。

类来传输。

maven
maven主要管理项目中的依赖关系以及构建项目。

详细包括：依赖管理、规范目录结构、完整的项目构建、支持多种插件。

2.2.GAV

       GAV就是工程的坐标，是英文Groupid、Artifactld、Version的缩写。

二方依赖库
二方库指的是同一个公司下的其他内部项目的依赖库。

定义GAV的规则以及版本规则

 二方库中GroupID、ArtifactID的定义

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

              说明：{公司/BU} 例如：alibaba/taobao/tmall/aliexpress 等 BU 一级；

              正例：com.taobao.jstorm 或com.alibaba.dubbo.register

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

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

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

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

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

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

       二方库的引用规约包括

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

              1.底层基础技术框架、核心数据管理平台、或近硬件端系统谨慎

              引入第三方实现。

              2.所有版本仲裁使用 <dependencyManagement>语句块

              3.二方库不要有配置项

              4.不要使用不稳定的工具包或者 Utils 类

       二方库的发布原则

              精简可控原则

              1.移除不必要的API和依赖

             2.只包含 Service API、以及必要的工具类

              3.如果依赖其它二方库，尽量 provided 引入

              4.无 log具体实现，只依赖日志框架

              稳定可追溯原则

记录每个版本的变化
二方库维护者
源码的位置
公共二方库的行为不变
TCP/IP
TCP/IP是在多个不同网络间实现信息传输的协议簇。

TCP/IP进行5层分层，包括：应用层、传输层、网络层、链路层、物理层。

应用层
       定义从端口获取到程序中的数据格式并解读和返回数据。

传输层
       主要工作是定义端口，实现端口到端口的通信。

网络层
       定义IP地址和子网，并对于不同子网的数据包进行路由。

链路层
       对电信号进行分组并形成具有特定意义的数据帧。

物理层
       接口规格，信号电平，IEEE 802.1定义传送频率，帧结构。

IP协议

       IP协议包括报头和数据2部分，其中报头包括版本号、头长度、总长度等，具体见下图



TCP协议

       TCP包括报头和数据2部分，详细的见下图



       TCP建立连接需要3次握手

       见

为何一定要3次握手？1.信息对等，需要确认双方都能成功的接收和发送消息；2.防止超时。

TCP断开连接则需要4次握手



1.在 TIME_WAIT 等待的 2MSL （默认2分钟）是报文在网络上生存的最长时间，超期则

被丢弃（默认MSL>TTL）。2 分钟太长，在服务器上通常会使用更小的值。

2.既然 TIME_WAIT 貌似是百害而无一利的，为何不直接关闭，进入 CLOSED 状态呢?原

因有两点：第一，确认被动关闭方能够顺利进入 CLOSED 状态

                第二，防止失效请求

3.TIME_WAIT 状态无法真正释放句柄资源，在此期间，Socket 中使用的本地端口

在默认情况下不能再被使用。建议将 高并发服务器 TIME_WAIT 超时时间调小。

在 服 务 器 上 通 修 改 该 省 略 值( 秒 ): net.ipv4.tcp_fin_timeout = 30

(建议小于 30 秒为宜)

服务器设定
       为了适应高并发的服务器设定规约。

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

接。

              2. 调大服务器所支持的最大文件句柄数（ File Descriptor ，

简写为 fd ）

                     Linux系统一个连接对应一个文件描述符

               Linux系统默认所支持最大fd数量为1024，连接数很大时很容易无法建立连接。

JVM建议
1.VM 环境参数设置-

        XX:+HeapDumpOnOutOfMemoryError 参数

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