确保高效发展进程的建议
很久以前,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计划,将来可能会进一步缩小Java EE所需的组件。
参考资料
- Java EE 7 Essentials Archetype
- 博客文章: "Stop saying 'heavyweight'"
- Java EE circuit breaker implementation
原文:https://community.oracle.com/...作者:Sebastian Daschner
译者:[KeepGoingPawn](https://blog.csdn.net/hengji666
9月福利,关注公众号
后台回复:004,领取8月翻译集锦!
往期福利回复:001,002, 003即可领取!