今天有幸发现了阿里的这份 Java 开发手册，可以说算了 Google 的风格指南与惯例（conventions）的一个补充和快速实践手册。个人感觉对开发中有很大的帮助，对一些之前模棱两可的概念有了较为明确的回答。虽然只有30多页，但是目前足以包含开发中大部分问题。接下来针对没一点，尤其是自己之前没有注意过的问题进行解析，目的是在以后开发中应用这些准则。
总体目录如下
- 编程规约
- 异常日志
- MySQL 数据库
- 工程结构
- 安全归约
应用分层
1【推荐】图中默认上层依赖于下层，箭头关系表示可直接依赖，如：开放接口层可以依赖于 Web 层，也可以直接依赖于 Service 层，依此类推：
开放接口层：可直接封装 Service 方法暴露成 RPC 接口；通过 Web 封装成 http 接口；进行 网关安全控制、流量控制等。
终端显示层：各个端的模板渲染并执行显示的层。当前主要是 velocity 渲染，JS 渲染， JSP 渲染，移动端展示等。
Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。
Service 层：相对具体的业务逻辑服务层。
Manager 层：通用业务处理层，它有如下特征：
1） 对第三方平台封装的层，预处理返回结果及转化异常信息；
2）对 Service 层通用能力的下沉，如缓存方案、中间件通用处理；
3）与 DAO 层交互，对多个 DAO 的组合复用。DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase 进行数据交互。
外部接口或第三方平台：包括其它部门 RPC 开放接口，基础平台，其它公司的 HTTP 接口。
我们的程序基本可以参考这个模型在该模型上进行拓展。其中 Manager 层之前没有涉及，更多的是放到 service 层中，以后需要对 service 层中的某些业务处理下沉到 manager 层，提供更好的低耦合性。
同时这个层次说明是不是可以作为我们程序的子模块划分的依据呢？至少应该算是一个参考，具体划分还需要更多的实践在参考。
2【参考】分层异常处理规约
在
DAO层，产生的异常类型有很多，无法用细粒度的异常进行catch，使用catch(Exception e)方式，并throw new DAOException(e)，不需要打印日志，因为日志在 Manager/Service 层一定需要捕获并打到日志文件中去，如果同台服务器 再打日志，浪费性能和存储。在 Service 层出现异常时，必须记录出错日志到磁盘，尽可能带 上参数信息，相当于保护案发现场。如果 Manager 层与 Service 同机部署，日志方式与 DAO 层处理一致，如果是单独部署，则采用与 Service 一致的处理方式。Web 层绝不应该继续往上 抛异常，因为已经处于顶层，无继续处理异常的方式，如果意识到这个异常将导致页面无法正常渲染，那么就应该直接跳转到友好错误页面，加上友好的错误提示信息。开放接口层要将异常处理成错误码和错误信息方式返回。
异常处理是一个十分重要的话题，而且我们需要对整体有提纲挈领的设计，进而保证整个应用能够友好的处理错误，并且记录错误。
3【参考】分层领域模型规约：
DO（Data Object）：与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。
DTO（Data Transfer Object）：数据传输对象，Service 和 Manager 向外传输的对象。
BO（Business Object）：业务对象。可以由 Service 层输出的封装业务逻辑的对象。
Query：数据查询对象，各层接收上层的查询请求。注：超过 2 个参数的查询封装，禁止 使用 Map 类来传输。
VO（View Object）：显示层对象，通常是 Web 向模板渲染引擎层传输的对象。
二方库依赖
二方库：公司内部发布到中央仓库，可供公司内部其它应用依赖的库（jar 包）。
一方库：本工程内部子项目模块依赖的库（jar 包）。
三方库：公司之外的开源库（jar 包）。
比如公司内部统一使用一套工具类 java-support 就可以作为二方库，？？同时如果公司自行管理（或者重新 patch 过）的第三方库也可以成为二方库。而作为多模块项目中的某些模块仅仅是自己项目中使用，那么这个模块可以成为一方库。三方库就是诸如 open-saml，jackson 等非本公司开发维护的库，一般是放在 central repository 中的。
1【强制】定义 GAV 遵从以下规则
这一点可以说是对开发中帮助最大的，
1） GroupID 格式：com.{公司/BU }.业务线.[子业务线]，最多 4 级。
（注：BU 是业务单元的缩写 Business Unit）
说明：{公司/BU} 例如：alibaba/taobao/tmall/aliexpress 等 BU 一级 子业务线可选。
正例：com.taobao.jstorm 或 com.alibaba.dubbo.register
2） ArtifactID 格式：产品线名-模块名。语义不重复不遗漏，先到中央仓库去查证一下。
正例：dubbo-client / fastjson-api / jstorm-tool
工具项目
1 | java-support |
xxxx-xx 项目1
xxxx-xx-parent
3） Version：详细规定参考下方。
2【强制】二方库版本号命名方式：主版本号.次版本号.修订号
- 主版本号：当做了不兼容的 API 修改，或者增加了能改变产品方向的新功能。
- 次版本号：当做了向下兼容的功能性新增（新增类、接口等）。
- 修订号：修复 bug，没有修改方法签名的功能加强，保持 API 兼容性。
说明：注意：起始版本号必须为：1.0.0，而不是 0.0.1 正式发布的类库必须先去中央仓库进行查证，使版本号有延续性，正式版本号不允许覆盖升级。如当前版本：1.3.3，那么下一个合理的版本号：1.3.4 或 1.4.0 或 2.0.0
这个版本控制应该是 Semantic Versioning 的一个简化说明。这里强制约束了初始版本号为1.0.0。
Semantic Versioning 对1.0.0 版本有如下解释：
Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.
How do I know when to release 1.0.0?
If your software is being used in production, it should probably already be 1.0.0.
If you have a stable API on which users have come to depend, you should be 1.0.0.
If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.
也就是说1.0.0应该是上线的第一个版本，如果开发阶段的版本号应该加入后缀，上述文档同样给予约束：
A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes(注：指的是不能有诸如 01，002 这样的编码，应该直接写成1和2). Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
所以我认为项目开始开发后的版本号可以从 1.0.0-0.0.1 开始，逐步增加 pre-version 版本号，然后当即将发布时可以更改为 1.0.0-alpha，1.0.0-alpha.1，1.0.0-beta，1.0.0-beta.1。最后发布 1.0.0 版本。（注：需要探讨）
3【强制】线上应用不要依赖 SNAPSHOT 版本（安全包除外）
说明：不依赖 SNAPSHOT 版本是保证应用发布的幂等性。另外，也可以加快编译时的打包构建。
通过搜索一些 maven 的文章逐渐了解了这个要求的含义。所谓幂等性（idempotent）是一个数学领域的词汇，现应用到很多计算机领域，这里主要是指应用在构建发布的时候，同一个版本号所构建的发布版必须是一致的，这也就要求其依赖是稳定的。而 SNAPSHOT 版本是不稳定的，会导致同样版本号的源码构建出的应用依赖了不同版本的库。有时间把幂等性的概念与应用单独学习。
4【强制】二方库的新增或升级，保持除功能点之外的其它 jar 包仲裁结果不变。如果有改变， 必须明确评估和验证，建议进行 dependency:resolve 前后信息比对，如果仲裁结果完全不一 致，那么通过 dependency:tree 命令，找出差异点，进行排除 jar 包。
（注：这里的仲裁就是指主项目最终依赖包的选择，比如有两个二方库，一个二方库依赖了 log-1.0.0 放在前面, 另外一个二方库依赖了 log-1.0.2 放在后面，那么最终的仲裁结果是依赖了 log-1.0.0，因为对于 maven 中的间接依赖，哪个依赖在pom文件中定义的位置在前面，就采用在前面定义的那个依赖。）
这一条实际上是针对于 maven 包依赖解析的使用约束。因为 maven 在进行处理依赖传递中有着自己的规则，所以一旦我们对现有二方库依赖进行增加或升级，那么这个二方库本身的依赖就有可能更改，进而传递更改主项目的依赖。所以我们需要在增加或升级二方库时确保其他的库不变，因为我们无法确定一旦这些库更改会不会造成问题。如果有冲突，我们就只能<excludes>排除冲突的 jar 包。
当然这里也有可能新增加的功能点因为排除了相应的 jar 包导致出问题，那么只能想办法解决这个新加的功能点的问题，否则只能考虑整体升级出问题的依赖。
5【强制】二方库里可以定义枚举类型，参数可以使用枚举类型，但是接口返回值不允许使用枚举类型或者包含枚举类型的 POJO 对象。
这也就是说二方库不能依赖自定义的枚举类型，这个设定的原因需要探究。
6【强制】依赖于一个二方库群时，必须定义一个统一的版本变量，避免版本号不一致。
说明：依赖 springframework-core,-context,-beans，它们都是同一个版本，可以定义一个变量来保存版本：${spring.version}，定义依赖的时候，引用该版本。
三方库群是不是一样要约束版本，比如 opensaml 3.x？这一点十分重要，这样可以保证依赖库群的正确性，同时也减少修改依赖时犯错误。
7【强制】禁止在子项目的 pom 依赖中出现相同的 GroupId，相同的 ArtifactId，但是不同的 Version。
说明：在本地调试时会使用各子项目指定的版本号，但是合并成一个 war，只能有一个版本号 出现在最后的 lib 目录中。可能出现线下调试是正确的，发布到线上却出故障的问题。
如果子项目依赖了相同的库，这些库的版本需要一致。
8【推荐】所有 pom 文件中的依赖声明放在语句块中，所有版本仲裁放在 语句块中。
说明：
里只是声明版本，并不实现引入，因此子项目需要显式的声 明依赖，version 和 scope 都读取自父 pom。而 所有声明在主 pom 的 里的依赖都会自动引入，并默认被所有的子项目继承。
dependencyManagement只会影响现有依赖的配置，但不会引入依赖。这个配置项常见于多模块的 maven 项目中。
9【推荐】二方库不要有配置项，最低限度不要再增
10【参考】为避免应用二方库的依赖冲突问题，二方库发布者应当遵循以下原则：
1）精简可控原则。移除一切不必要的 API 和依赖，只包含 Service API、必要的领域模型对象、Utils类、常量、枚举等。如果依赖其它二方库，尽量是 provided 引入，让二方库使用者去依赖具体版本号；无 log 具体实现，只依赖日志框架。
2）稳定可追溯原则。每个版本的变化应该被记录，二方库由谁维护，源码在哪里，都需要能方便查到。除非用户主动升级版本，否则公共二方库的行为不应该发生变化。
如果使用多个二方库，势必存在依赖重复冲突等问题，所以尽可能的对二方库的依赖进行优化控制。
服务器
1. 【推荐】高并发服务器建议调小 TCP 协议的 time_wait 超时时间。
说明：操作系统默认 240 秒后，才会关闭处于
time_wait状态的连接，在高并发访问下，服 务器端会因为处于time_wait的连接数太多，可能无法建立新的连接，所以需要在服务器上 调小此等待值。 正例：在 linux 服务器上请通过变更/etc/sysctl.conf文件去修改该缺省值（秒）：net.ipv4.tcp_fin_timeout = 30
2. 【推荐】调大服务器所支持的最大文件句柄数（File Descriptor，简写为 fd）。
说明：主流操作系统的设计是将
TCP/UDP连接采用与文件一样的方式去管理，即一个连接对 应于一个 fd。主流的 linux 服务器默认所支持最大 fd 数量为 1024，当并发连接数很大时很容易因为 fd 不足而出现“open too many files”错误，导致新的连接无法建立。 建议将 linux 服务器所支持的最大句柄数调高数倍（与服务器的内存数量相关）。
3. 【推荐】给 JVM 设置-XX:+HeapDumpOnOutOfMemoryError 参数，让 JVM 碰到 OOM 场景时输出 dump 信息。
说明：OOM 的发生是有概率的，甚至有规律地相隔数月才出现一例，出现时的现场信息对查错 非常有价值。
4. 【参考】服务器重定向问题
服务器内部重定向使用forward；
外部重定向地址使用 URL 拼装工具类来生成，否则会带来 URL 维护不一致的问题和潜在的安全风险。