隐藏下层业务逻辑的复杂性
提高系统复用度，扩展性，可维护性。
*计算机领域的任何问题都可以通过增加一个中间层解决（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
