从 Jakarta EE 9 到云端：构建高密度、可观测的容器化企业应用实战

如果你是一位在企业级 Java 领域耕耘多年的开发者，最近几年可能感受到一种微妙的张力：一方面，Spring Boot 以其“约定优于配置”的理念席卷了微服务开发；另一方面，那个曾经定义了企业级 Java 标准的庞然大物——Java EE，似乎正在经历一场静默但深刻的蜕变。这场蜕变的核心，就是 Jakarta EE。它不仅仅是包名从 javax.* 到 jakarta.* 的简单变更，更是一次面向云原生时代的彻底重构。对于需要构建高可靠、标准化、且易于大规模运维的复杂系统的团队而言，Jakarta EE 9 及后续版本提供了一条被严重低估的现代化路径。今天，我们就抛开那些泛泛而谈的概念，深入实战，看看如何将一个 Jakarta EE 9 应用，通过 Docker 容器化，并为其注入云原生的灵魂，最终使其成为能在 Kubernetes 上优雅运行的现代化服务。

1. 理解 Jakarta EE 9 的云原生基因

很多人对 Jakarta EE 的印象还停留在“笨重”、“配置复杂”的旧时代。Jakarta EE 9 的出现，正是为了打破这一刻板印象。它的首要目标就是 “轻量化”和“模块化”，这与云原生应用追求的小型、独立、可组合的特性不谋而合。

核心变化 远不止包名。Jakarta EE 9 移除了大量陈旧或不常用的 API（如 JAX-RPC、EJB Entity Beans），并将平台核心规范精简为更清晰的模块。这意味着，你的应用不再需要携带一个庞大的“全家桶”运行时。你可以根据需求，只引入必要的 API，例如 Jakarta RESTful Web Services (JAX-RS)、Jakarta Contexts and Dependency Injection (CDI)、Jakarta Persistence (JPA) 和 Jakarta Security。这种模块化设计，为制作小巧的容器镜像奠定了坚实基础。

注意：从 Java EE 8 迁移到 Jakarta EE 9，包名替换是必须的，但多数 API 保持了高度兼容。自动化工具（如 Eclipse Transformer）可以辅助完成大部分机械性工作，但一些深层依赖和框架集成点仍需手动检查。

为什么说它天生适合云原生？我们来看几个关键特性：

• 内置的配置外部化支持：通过 MicroProfile Config 规范（已成为 Jakarta EE 的自然延伸），应用可以轻松地从环境变量、系统属性、外部配置文件（如 config.properties）甚至远程配置中心读取配置。这完美契合了容器化部署中通过环境变量注入配置的最佳实践。
• 健康检查与就绪/存活探针：MicroProfile Health 允许应用暴露自定义的健康检查端点。在 Kubernetes 中，这可以直接映射为 livenessProbe 和 readinessProbe，让平台能智能地管理你的应用生命周期。
• 指标与链路追踪：MicroProfile Metrics 和 OpenTracing/Jaeger 集成，让应用运行时指标（如请求次数、响应时间、JVM 状态）和分布式调用链路变得透明可视，这是运维复杂微服务系统的眼睛。

下面的表格对比了传统 Java EE 应用与基于 Jakarta EE 9 的云原生应用在几个维度的差异：

维度	传统 Java EE 应用 (Pre-Jakarta)	云原生 Jakarta EE 9 应用
部署单元	庞大的 EAR/WAR 包，包含大量隐式依赖	精简的 WAR/JAR，显式声明依赖，适合作为容器镜像内的唯一应用
配置管理	主要依赖应用服务器内部的 jndi 和 XML 配置，与环境耦合紧	通过 MicroProfile Config 实现配置外部化，与运行环境解耦
可观测性	依赖应用服务器管理控制台，指标分散，链路追踪困难	内置健康、指标、追踪端点，便于与 Prometheus、Grafana、Jaeger 集成
启动速度	应用服务器启动慢，应用部署过程重	使用轻量级运行时（如 Payara Micro, Open Liberty），启动快，适合快速扩缩容

理解了这些基因，我们就能有的放矢地进行容器化改造。

2. 构建精益的 Jakarta EE 应用与 Docker 镜像

我们的目标不是简单地把一个 WAR 包扔进安装了 JDK 的 Ubuntu 镜像。那样做出来的镜像往往超过 500MB，甚至上 GB，存在大量安全漏洞，并且启动缓慢。我们的目标是构建一个 小而安全、快速启动 的镜像。

2.1 应用架构与依赖管理

假设我们正在构建一个简单的订单服务，提供 REST API。项目采用 Maven 管理，pom.xml 的关键部分如下：

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>order-service</artifactId>
    <version>1.0.0</version>
    <packaging>war</packaging>

    <properties>
        <version.jakarta.platform>9.1.0</version.jakarta.platform>
        <version.microprofile>5.0</version.microprofile>
    </properties>

    <dependencies>
        <!-- Jakarta EE Web Profile API (提供 Servlet, JAX-RS, JSON-P, CDI等) -->
        <dependency>
            <groupId>jakarta.platform</groupId>
            <artifactId>jakarta.jakartaee-web-profile-api</artifactId>
            <version>${version.jakarta.platform}</version>
            <scope>provided</scope>
        </dependency>
        <!-- MicroProfile 健康检查 -->
        <dependency>
            <groupId>org.eclipse.microprofile.health</groupId>
            <artifactId>microprofile-health-api</artifactId>
            <version>4.0</version>
            <scope>provided</scope>
        </dependency>
        <!-- MicroProfile 配置 -->
        <dependency>
            <groupId>org.eclipse.microprofile.config</groupId>
            <artifactId>microprofile-config-api</artifactId>
            <version>3.0.2</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>

    <build>
        <finalName>order-service</finalName>
    </build>
</project>

注意依赖的 scope 设为 provided，这意味着这些 API 将在运行时由 Jakarta EE 实现服务器提供，不会被打进 WAR 包，从而保持应用包的轻量。

2.2 编写 Dockerfile：多阶段构建的艺术

这是容器化最核心的一步。我们将使用 多阶段构建 来分离构建环境和运行环境，确保最终镜像只包含运行所需的最少内容。

# 第一阶段：构建阶段
FROM maven:3.8.6-eclipse-temurin-17-alpine AS builder
WORKDIR /app
COPY pom.xml .
# 利用 Docker 层缓存，先下载依赖
RUN mvn dependency:go-offline -B
COPY src ./src
# 打包应用
RUN mvn clean package -DskipTests

# 第二阶段：运行阶段 - 使用轻量级 Jakarta EE 运行时
FROM icr.io/appcafe/open-liberty:kernel-slim-java17-openj9-ubi AS runtime

# 从构建阶段复制 WAR 包
COPY --from=builder /app/target/order-service.war /config/dropins/

# 复制服务器配置文件，启用 MicroProfile 特性
COPY --from=builder /app/src/main/liberty/config/server.xml /config/

# 复制应用特定配置（可选，优先使用环境变量）
COPY --from=builder /app/src/main/resources/config/* /config/

# 声明健康检查端点（与 MicroProfile Health 对应）
HEALTHCHECK --interval=30s --timeout=3s --start-period=60s --retries=3 \
  CMD curl --fail http://localhost:9080/health || exit 1

# 使用非 root 用户运行，增强安全性
USER 1001
EXPOSE 9080 9443

这个 Dockerfile 的精髓在于：

1. 构建阶段：使用包含 Maven 和 JDK 的镜像，完成编译打包。dependency:go-offline 能优化构建缓存。
2. 运行阶段：选择了 Open Liberty 的 kernel-slim 镜像作为基础。它非常小巧（约 200MB），并且允许你通过 server.xml 动态添加所需的功能特性（如 microProfile-5.0），而不是包含一个全功能的服务器。其他优秀选择还包括 Payara Micro。
3. 安全性：使用 USER 1001 切换非 root 用户，遵循容器安全最佳实践。
4. 健康检查：内置了 HEALTHCHECK 指令，与我们将要暴露的 MicroProfile Health 端点配合。

对应的 Open Liberty server.xml 配置示例：

<server description="Order Service">
    <featureManager>
        <!-- 启用 Jakarta EE Web Profile 和 MicroProfile 特性 -->
        <feature>jakartaee-9.1</feature>
        <feature>microProfile-5.0</feature>
    </featureManager>
    <httpEndpoint id="defaultHttpEndpoint"
                  httpPort="9080"
                  httpsPort="9443" />
    <webApplication location="order-service.war" contextRoot="/"/>
</server>

通过 mvn clean package 和 docker build -t order-service:latest . 命令，你将得到一个经过高度优化的 Docker 镜像。

3. 注入云原生能力：配置、健康与指标

容器化只是第一步，让应用在云上“活得好”才是关键。Jakarta EE 配合 MicroProfile 生态，让这些能力的实现变得异常简单。

3.1 外部化配置

在应用中，使用 @Inject @ConfigProperty 来注入配置：

import jakarta.enterprise.context.ApplicationScoped;
import jakarta.inject.Inject;
import org.eclipse.microprofile.config.inject.ConfigProperty;

@ApplicationScoped
public class OrderService {

    @Inject
    @ConfigProperty(name = "ORDER_PAGE_SIZE", defaultValue = "20")
    private int pageSize;

    @Inject
    @ConfigProperty(name = "DB_CONNECTION_URL")
    private String dbUrl; // 从环境变量注入

    // ... 业务方法
}

在 Kubernetes Deployment 的 YAML 中，你可以轻松地通过环境变量或 ConfigMap 来设置这些值：

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: order-service
        image: order-service:latest
        env:
        - name: ORDER_PAGE_SIZE
          value: "50"
        - name: DB_CONNECTION_URL
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: database.url
        - name: JAVA_TOOL_OPTIONS # 传递 JVM 参数也很方便
          value: "-Xmx512m -XX:+UseContainerSupport"

3.2 实现健康检查

创建一个健康检查类：

import org.eclipse.microprofile.health.HealthCheck;
import org.eclipse.microprofile.health.HealthCheckResponse;
import org.eclipse.microprofile.health.Readiness;
import jakarta.enterprise.context.ApplicationScoped;

@Readiness // 标记为就绪检查
@ApplicationScoped
public class DatabaseConnectionHealthCheck implements HealthCheck {

    @Override
    public HealthCheckResponse call() {
        // 模拟检查数据库连接
        boolean isUp = checkDatabase();
        return HealthCheckResponse.named("order-service-db")
                .status(isUp)
                .withData("connection", isUp ? "established" : "failed")
                .build();
    }

    private boolean checkDatabase() {
        // 实际连接检查逻辑
        return true;
    }
}

应用启动后，会自动暴露 /health/ready 和 /health/live 端点。Kubernetes 的探针配置可以这样写：

livenessProbe:
  httpGet:
    path: /health/live
    port: 9080
  initialDelaySeconds: 60
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /health/ready
    port: 9080
  initialDelaySeconds: 20
  periodSeconds: 5

3.3 暴露应用指标

MicroProfile Metrics 会自动收集 JVM 和 HTTP 请求的基础指标。要添加自定义业务指标，同样简单：

import org.eclipse.microprofile.metrics.annotation.Counted;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;

@Path("/orders")
public class OrderResource {

    @GET
    @Counted(name = "getAllOrdersCount", description = "调用获取所有订单接口的次数")
    public List<Order> getAllOrders() {
        // ... 业务逻辑
    }
}

应用会暴露 /metrics 端点，输出格式兼容 Prometheus。在 Kubernetes 中，只需通过 ServiceMonitor 或 Pod Annotations 让 Prometheus 自动发现并抓取这些指标，即可在 Grafana 中构建丰富的监控仪表盘。

4. 在 Kubernetes 中编排与部署

当你的 Jakarta EE 应用被打包成一个健康的容器后，Kubernetes 就是它最好的舞台。这里我们关注几个对生产环境至关重要的实战要点。

4.1 资源管理与弹性伸缩

精确的资源请求和限制是稳定性的基石。在 Deployment 中定义：

resources:
  requests:
    memory: "512Mi"
    cpu: "250m"
  limits:
    memory: "1Gi"
    cpu: "500m"

结合前面配置的健康检查和指标，你可以轻松配置 Horizontal Pod Autoscaler (HPA)，基于 CPU 利用率或自定义指标（如每秒订单请求数）自动扩缩容：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

4.2 服务发现与网络

Jakarta EE 应用通过 JAX-RS Client 或 MicroProfile Rest Client 进行服务间调用。在 Kubernetes 中，你可以直接使用 Kubernetes 的 Service DNS 名称（如 http://inventory-service.default.svc.cluster.local:8080/）。为了更灵活，可以集成 MicroProfile Config 来从配置中心或环境变量获取服务地址。

4.3 持续交付流水线设计

一个完整的 CI/CD 流水线可以自动化从代码提交到生产部署的全过程。核心步骤通常包括：

1. 代码检出与构建：使用 Maven/Gradle 编译、运行单元测试。
2. 容器镜像构建：使用上述 Dockerfile 构建镜像，并利用 BuildKit 缓存提升速度。
3. 安全扫描：使用 Trivy、Grype 等工具扫描镜像漏洞，阻断高风险镜像。
4. 镜像推送：将镜像推送到私有镜像仓库（如 Harbor, ECR, GCR）。
5. 部署到环境：使用 kubectl、Helm 或 GitOps 工具（如 ArgoCD, Flux）将新镜像部署到开发、测试或生产集群。
6. 集成测试与验证：自动运行 API 集成测试，验证健康检查和指标端点。

关键在于，Jakarta EE 应用的标准化和轻量化，使得它在流水线的每个环节都表现得可预测和高效。

5. 进阶考量与生产环境调优

当应用在 Kubernetes 上平稳运行后，还有一些进阶话题值得深入，它们能进一步提升系统的韧性、可观测性和开发体验。

分布式链路追踪的集成：在微服务架构中，一个请求可能穿越多个 Jakarta EE 服务。集成 OpenTelemetry 或 Jaeger 客户端库，并在服务器配置中启用相关特性，可以自动实现跨服务的链路追踪。你需要做的是在 server.xml 中添加 mpTelemetry 特性，并在应用中为关键操作添加适当的 Span。

无状态化与会话管理：云原生应用倡导无状态。如果应用必须维护会话，应将会话数据存储到外部缓存（如 Redis），而不是内存中。Jakarta EE 的 jakarta.servlet.http.HttpSession 可以通过配置，轻松将会话持久化到 Redis 等外部存储，确保 Pod 重启或扩容时用户会话不丢失。

JVM 调优 for Containers：容器内的 JVM 需要特别配置。确保使用支持容器感知的 JDK 版本（如 Eclipse Temurin, OpenJDK 11+），并设置以下关键参数：

-XX:+UseContainerSupport
-XX:MaxRAMPercentage=75.0
-XX:InitialRAMPercentage=50.0
-XX:+UseG1GC

这些参数让 JVM 根据容器内存限制自动调整堆大小，并选择适合容器环境的垃圾回收器。

开发体验优化：在本地开发时，你可以利用 docker-compose 快速拉起一个包含数据库、缓存等依赖的模拟环境。更高级的做法是使用 Telepresence 或 Skaffold 这类工具，将本地开发机直接接入远程 Kubernetes 集群，实现代码修改的即时生效和调试，极大提升开发效率。

从 Jakarta EE 9 出发，通过精益的容器化构建、深度的云原生能力注入，再到 Kubernetes 上的现代化编排，这条路径为传统企业级 Java 应用提供了一条清晰、标准且高效的转型通道。它或许没有某些框架那么“炫酷”，但其背后的规范性、稳定性和对开放标准的坚持，对于构建需要长期维护、大规模协作的关键业务系统而言，是一种经过时间考验的智慧。当你下次面对一个复杂的业务系统设计时，不妨重新审视一下这个正在焕发新生的生态，它可能正是你寻找的那块坚实基石。