确保高效发展进程的建议
很久以前, J2EE, 特别是应用程序服务器被认为过于臃肿和 "重量级". 对于开发人员来说, 使用此技术开发应用程序会非常繁琐且令人沮丧. 但是, 由于 J2EE 框架的名称已更改为 Java EE, 因此该假设不再适用. Java EE 与其他企业框架相比区别在哪以及框架轻量级的标准是什么?
在选择技术时, 需要考虑的最重要方面之一是开发人员在开发过程中的生产力. 工程师应该花费尽可能多的时间来实现用例和创收功能, 因为这将使公司朝着目标前进.
所选择的技术和方法应该最大限度地缩短开发人员的时间. 具体哪些时间呢: 等待构建, 测试和部署; 配置应用; 实施与业务用例无关的管道; 并配置构建环境和外部依赖项. 但是大多数可用技术都没有这样做.
1. 为什么标准?
与其他框架相比, Java EE 的最大优势之一是使用的 API 的标准化. 标准听起来可能很无聊而且不够创新 - 从本质上讲, 这是真的, 因为 Java 规范请求 (JSR) 已经成为行业内过去已经过充分证明的结果. 但使用这些标准有几个优点.
2. 整合规范
Java EE 中的特定 API - 例如上下文和依赖注入 (CDI),JAX-RS,JSON 处理(JSR 353) 和 Bean 验证 - 可以很好地协同工作, 并且可以无缝地相互组合. 最重要的是, CDI 被用作应用程序组件之间的 "粘合剂". 该规范包含诸如 "如果容器支持规范 A 和 B, 那么 A 必须与 B 无缝集成并良好地工作."
例如, JAX-RS 支持 JSONP 类型, 例如 JsonObject 用作请求或响应实体, 它支持调用 Bean 校验功能 - 如果验证失败, 则包括正确的 HTTP 状态代码(参见清单 1).
- @Path("duke")
- public class DukeResource {
- @GET
- public JsonObject getDuke() {
- return JSON.createObjectBuilder().add("name", "Duke").build();
- }
- @POST
- public void create(@Valid @NotPlayedYet Game game) {
- // game object has been validated at this point
- }
- }
清单 1. JAX-RS 的 JSONP 和 Bean Validation 集成
使用 JSONP 类型意味着内容类型将是 application / JSON, 并且如果验证失败, 将发送 HTTP 状态代码 400 Bad Request. 这无需编写任何配置代码就能使一切都完成.
另一个例子是 CDI 使开发人员能够通过 @Inject 将任何 bean 和用户定义的对象注入 Java EE 托管组件. 请参阅清单 2, 了解一个 bean 验证 Validator, 它直接使用另一个 CDI 托管 bean.
- public class GameNotPlayedValidator implements ConstraintValidator<NotPlayedYet, Game> {
- @Inject
- GameHistory history;
- public void initialize(NotPlayedYet constraint) {
- // no initialization needed
- }
- public boolean isValid(Game game, ConstraintValidatorContext context) {
- return !history.exists(game);
- }
- }
清单 2. bean 验证的 CDI 集成
集成是规范的一个主要方面, 可以提供直接的开发人员体验. 开发人员可以依赖应用程序服务器进行集成和配置工作, 从而可以专注于应用程序的业务逻辑.
3. 按配置约定驱动开发
由于 Java EE 的配置约定驱动方法, 大多数实际应用程序不需要大量配置. 繁琐的 xml 描述符的日子结束了. 对于简单的 Java EE 应用程序, 您不需要单个 xml 文件.
由于声明性注释, 一个简单的带注释的普通旧 Java 对象 (POJO) 处理 HTTP 请求(@Path), 或分别作为 Enterprise JavaBeans(EJB)bean(@ Stateless) - 包括事务, 监视或拦截器. 过去, 这些方法已在各种框架中得到很好的证明, 并已在 Java EE 中进行了标准化.
如果需要, xml 描述符仍可用于部署时配置, 但是配置约定有助于最大限度地提高开发人员的工作效率.
4. 外部依赖
少数实际企业项目在部署工件中没有任何额外依赖项的情况下工作. 但这些依赖关系的理由主要是由技术驱动 - 例如包括日志记录或实体映射框架或 Apache Commons 或 Google Guava 等常用库 - 而不是用例.
Java EE 7 - 尤其是与 Java 8 一起使用时 - 具有足够的功能来覆盖大多数用例而没有任何其他依赖性. 开箱即用的内容大部分都可以用最少量的代码来实现, 例如, 通过 CDI 提供商的可注入配置, 通过拦截器的断路器(查看 Adam Bien 的开源库), 或通过复杂的收集操作 Java 8 lambda 表达式和流.
当然, 你可以争辩说不要在这里重新发明轮子. 但实际上, 为了节省一些自编写的代码行, 将兆字节的外部依赖项包含在部署工件中并没有多大意义.
经验表明, 最大的问题不是直接引入的依赖, 而是传递的依赖. 传递的依赖经常与应用程序服务器上已有的库版本冲突, 并导致具有挑战性的冲突. 在一天的工作时间内, 开发人员要花费更多时间来管理这些冲突, 而不是聚焦在将小功能实现到项目中所需的时间. 这主要适用于具有技术驱动而非用例驱动的依赖关系的情况.
有关简单的 Java EE 7 项目 Maven 项目对象模型 (POM) 的文件启发, 请参阅清单 3, 该文档受 Adam Bien 的启发 Java EE 7 Essentials Archetype.
- <project xmlns="http://maven.apache.org/POM/4.0.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
- <modelVersion>4.0.0</modelVersion>
- <groupId>com.sebastian-daschner</groupId>
- <artifactId>game-of-duke</artifactId>
- <version>1.0-SNAPSHOT</version>
- <packaging>war</packaging>
- <dependencies>
- <dependency>
- <groupId>javax</groupId>
- <artifactId>javaee-API</artifactId>
- <version>7.0</version>
- <scope>provided</scope>
- </dependency>
- </dependencies>
- <build>
- <finalName>game-of-duke</finalName>
- </build>
- <properties>
- <maven.compiler.source>1.8</maven.compiler.source>
- <maven.compiler.target>1.8</maven.compiler.target>
- <failOnMissingwebXml>false</failOnMissingWebXml>
- <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
- </properties>
- </project>
清单 3. Java EE 7 Maven POM 文件
当然, 有时应用程序确实需要集成对于实现软件目标至关重要的库. 但是, 这些依赖关系需要通过业务需求来证明. 一般来说, 它很有意义, 可以节省时间和精力来最小化外部生产库.
对于测试依赖关系, 这是一个不同的故事, 因为库, 例如 JUnit,Mockito 或者在某些情况下, Arquillian - 是至关重要的. 但同样, 关注测试依赖项列表也是有意义的.
5. 精简部署 Artifacts
由于应用程序服务器知道 Java EE API, 因此该 API 不必包含在部署 artifact 中. 只包含业务逻辑 - 只需最少的胶水代码和交叉关注点.
因此, 这些千字节大小的工件可以使构建时间非常短, 因为构建过程不需要复制很多东西. 这可以在每个构建上产生几秒钟的差异. 如果总结开发人员和持续集成 (CI) 服务器所花费的所有额外时间, 那就会产生很大的不同. 项目建设的频率越高 - 对于持续交付 (CD) 情景尤其如此 - 影响越大.
除了较短的构建时间外, 小型部署 artifacts 还可确保较短的发布和部署时间. 由于实现已经包含在运行时中, 所以在所有情况下, 移动部件花费的时间都是最小的.
6.Docker 的理想框架
这正是 Java EE 成为 Docker 等容器技术的完美框架的原因. Docker 镜像基于图层, 构建图像时, 基本图像已包含操作系统, Java 运行时和应用程序. 因此, 在每个构建中添加的唯一内容是部署工件的最后一个千字节薄层. 与胖 WAR 或独立 JAR 方法相比, 这节省了时间和存储 - 不仅在每个构建上, 而且在图像版本化或发布版本时 .
无论在哪个阶段, 拥有精简的部署 artifacts 都可以实现非常快速和高效的部署管道.
7. 现代应用服务器
J2EE 应用程序服务器是重量级软件在启动和部署时间, 安装大小和资源占用空间方面的体现. 但是在 Java EE 的新世界中, 这已不再适用.
所有现代 Java EE 7 应用程序服务器 (如 WildFly,Payara,WebSphere Liberty,Profile 和 TomEE) 都可在几秒钟内启动和部署. 由于内部, 全面的模块化, 他们只能加载所需的组件并尽快部署精简的应用程序 artifacts.
现在的安装尺寸和占地面积非常合理. 应用程序服务器不会消耗比简单的 servlet 容器更多的东西, 但它具有完整的 Java EE 功能. 有趣的是, 现在运行的浏览器实例消耗更多内存.
话虽如此, 每个服务器只部署一个应用程序是可能的, 也可以是合理的 - 无论是在容器中还是在内部. 通过 "每个容器每个应用程序服务器一个应用程序" 方法, 您可以为现代微服务架构提供高效且灵活的解决方案.
8. 打包
在打包过程中, 不应该继续使用 EAR 文件了. 将整个应用程序部署在独立的专门的服务器上, 要求我们在那个环境中必须可以访问所有的组件方法, 这样做可以节省更多的构建和部署时间. 除此之外, 这还避免了 EAR 文件倾向于导致的类加载层次结构问题.
在大多数云和微服务部署中, 使用独立的 JAR 包. 它们包含应用程序和运行时实现. 在 Java EE 领域, 这种方法可以使用特定于供应商的工具链来实现, 例如 WildFly Swarm,Payara Micro 或 TomEE Embedded.
但是, 由于上述原因, 我强烈建议尽可能将业务逻辑与运行时分开. 这意味着将应用程序打包在仅包含应用程序代码的 WAR 文件中.
在我看来, 如果由于公司 "政治" 问题而不是技术原因而无法控制安装或操作流程, 则独立 JAR 文件是一种有用的解决方法. 然后运送部署工件中所需的所有内容并且只需要 JRE 时可以解决相当多的非技术问题.
9. 关于高效研发进程的建议
企业项目最有效的解决方案之一如下:
仅在提供 API 时使用 Java EE 7 和 Java 8
构建一个千字节大小的 WAR 文件, 其中仅包含业务逻辑和最小管道(例如 JAX-RS 资源或 JPA)
构建 Docker 镜像 - 仅将 WAR 文件添加到包含已配置的应用程序服务器的基础镜像
通过使用容器部署应用程序的 CD 管道进行传送
10. 结论
"重量级 Java EE" 的日子肯定结束了. Java EE 中包含的 API 提供了高效且愉快的开发人员体验以及标准内的无缝集成. 特别是, 将应用程序代码与运行时分离的方法可实现快速, 高效的开发过程.
通过由多个供应商发起的新 MicroProfile https://microprofile.io/ 计划, 将来可能会进一步缩小 Java EE 所需的组件.
参考资料
Java EE 7 Essentials Archetype
博客文章: "Stop saying'heavyweight'"
Java EE circuit breaker implementation
来源: https://www.cnblogs.com/liululee/p/11517579.html