深圳网站设计廊坊公司,购物系统数据库设计,网页源码app,上海娱乐场所关闭公平地说#xff0c;我有时会怀念 JavaEE 流行的日子。
当然#xff0c;当时的情况很复杂#xff0c;但整个 JavaEE 平台设计合理#xff0c;符合企业开发的需要。
我可以很轻松地将当时的 JavaEE 应用服务器与现代 Kubernetes 架构进行比较#xff0c;后者现在也有同样…公平地说我有时会怀念 JavaEE 流行的日子。
当然当时的情况很复杂但整个 JavaEE 平台设计合理符合企业开发的需要。
我可以很轻松地将当时的 JavaEE 应用服务器与现代 Kubernetes 架构进行比较后者现在也有同样的复杂性、安全性和可维护性问题甚至可能更糟。而且与 JavaEE 时代不同的是它没有真正的替代方案。
当时的 JavaEE 和现在的 Kubernetes 都试图但都失败了将开发人员从构建可扩展分布式应用的复杂性中解脱出来。
事实上还有更多的类比我发现我们现在正在绕一个大圈先是尝试应用服务器集群然后是微服务、容器、Kubernetes现在又回到了模块化单体而使用类似应用服务器这样允许多个应用/模块并排部署的东西可能并不是那么疯狂的想法。
考虑到 uber jar 在容器镜像中的效率太低而将应用程序与其依赖关系分开部署在一个单独的镜像层中更有意义你就会再次想到单独的应用程序服务器只不过是在无休止的螺旋式上升的另一个层次上。
JavaEE 规范成功地度过了 Spring 占据主导地位的时代现在可能会迎来复兴。不知何故基于 JavaEE 标准的 Quarkus 如今看起来比 Spring 更现代。
欢迎回到新旧 JavaEE 世界。
网友讨论 JEE 背后的许多设计决策都是考虑垂直扩展容器和微服务有利于水平扩展不需要应用程序服务器的复杂性。与之互补的是像 kubernetes 这样的东西使集群充当平台有可能比大型应用程序服务器规模更大并且成本更低许多小型机器与一台大型专用机器。 如果您想在容器中运行 JVM 应用程序以获得它能带来的所有好处可扩展性、声明式方法、自动重启......那么您绝不会想运行一个完整的应用服务器。
在容器中运行一个完整的应用服务器是没有意义的它很重启动速度慢而且失去了应用服务器的优势。
这不是唯一的原因因为在容器出现之前人们就已经开始远离应用服务器了但这无疑 扼杀 了应用服务器。 这其实是个很好的问题考虑到 Spring Boot 捆绑了Web服务器--我在 Docker 中对捆绑了 Wildfly 服务器的 Jakarta EE 应用程序也做了同样的处理机制相同结果相同。
但不管怎么说Spring Boot 已经过时了Micronaut、Quarkus 和 GraalVM 的本地可执行文件才是未来的趋势--速度更快占用内存更少。 应用服务器的最大优点是你可以用一个 JVM 来管理一切。最大的缺点是只有 1 个 JVM。如果我运行 10 个应用程序其中一个占用了 JVM 的所有可用内存那么就会有 10 个应用程序崩溃。而在容器中尽管内存效率较低但一个应用程序崩溃也只是该应用程序崩溃。
甚至在容器出现之前我们公司就遇到过这个问题。我们编写了自己的调度程序和 Java 运行程序因为这比让大型 tomcat 服务器运行所有程序要简单得多。结果我们的可靠性大大提高了。
如果 Java 有类似 erlang 的内存空间/进程那么 EE 模型就会更好用。但是Java 并不具备这种能力以后也不会有太贵了。 可能是因为 Java EE 的最后一次发布是在 2017 年。真实答案为什么你认为它不流行Jakarta 工作组正在向前推进。你可以在这里看到所有兼容的实现https://jakarta.ee/compatibility/。很多人正在在 Jakarta EE 上部署应用程序。很抱歉它在 twitter/tiktok/youtube 上并不流行。 不可变容器是一种卓越的部署模式。我们这些多年来一直在管理应用程序/Web 服务器的人再也不想回到那种模式了。先不说容器模式为生产系统管理带来的相对便利单是开发人员工作效率上的差异就值得我们这样做。
此外由于部署单元是容器因此不需要胖 jar。我个人更喜欢使用 Quarkus 的瘦 jar。
在你的容器中你要么需要一个内嵌有 servlet 容器的胖jar要么需要一个预部署了应用程序的 servlet 容器。
人们通常会选择带有嵌入式 servlet 容器的 胖jar。
胖 jar 只是一个包含所有依赖项的 jar当你把应用程序从一个地方复制到另一个地方或者分发你的应用程序以便在其他地方运行时它非常方便。
在容器化的世界里你分发的就是一个容器在容器中如果你的应用程序是一个单独的 jar而它的依赖项在文件系统的其他地方或者它们作为胖 jar 的一部分包含在 jar 中那么这并不重要。
我的意思是如果你要分发一个容器就真的不需要像 Spring Boot 那样将应用程序及其依赖项打包在一个单一的 jar 中。
Jib 在某种程度上就是这么做的它不是创建一个胖Jar而是创建一个多层容器在不同的层上有不同类别的依赖关系。一个额外的步骤/层可以是网络服务器。
对于这样的应用来说Jib 就显得有些矫枉过正了。在 Spring Boot 中spring-boot-thin-launcher 可以生成应用程序的精简 jar 发行版。您必须在容器创建前或作为创建过程的一部分将其配置为下载依赖项。否则它会在您启动容器时下载您的依赖项这不是好的做法。
Quarkus 默认生成 fast-jar瘦 jar:
它使用自定义类加载器加载依赖项速度比系统类加载器快很多。任何生成瘦 jar 的构建都会将所有依赖项和构建的应用程序 jar 复制到 target 下的文件夹中。然后你只需在构建容器时复制该文件夹即可。
这种瘦 jar方式为什么比胖Jar好 如果你在编译/编辑/运行循环中进行 docker 部署它就会非常有用。或者当你在更高的环境中四处奔波试图让东西正常工作时它也非常有用。
如果把复制 jar 分成两个 COPY 命令 第一个复制所有依赖库 第二个复制应用逻辑 jar
这意味着 docker 会创建两个独立的层。依赖库很少变化所以 docker 只需要在极少数情况下推送这一层。
对于有大量依赖库的大型项目来说在网络连接速度较慢的情况下我在家里工作网络连接速度很差大多数情况下推送操作可以从 2-3 分钟缩短到小于 30 秒。
它还能节省推送到的 docker 仓库的空间。所有使用相同依赖关系的镜像都指向同一层。
因此在容器环境中生成胖 jar 是不必要的。瘦 jar 格式是自然的 Java 方式。
生成廋Jar的小技巧 很少有人知道 MANIFEST.MF classpath 条目。Maven 可以自动生成这个条目例如 ${settings.localRepository} org.apache.maven.plugins maven-jar-plugin default-jar true ${exec.mainClass} ${exec.classpathPrefix} repository false
这将使 JAR 可以运行前提是类路径条目是相对或绝对的。
这比 Spring Boot 的 fatjar 启动时间要快得多
基本上你在开发过程中的运行方式已经发生了变化。由于无需为开发和 CI 打包一个巨大的 jar构建时间大大缩短。
至于 docker你可以先构建然后复制依赖项更改 classpathprefix 并使用依赖项插件或者使用 maven 构建插件和 Transitive Deps~/.m2/接受一个稍大的镜像......例如你可以用本地 maven 仓库装运一个容器。
