# SpringCloud+Vue3开源RuoyiOffice框架容器化实战：镜像、JVM 内存与三类探针如何配合

![镜像权限JVM内存与三类探针共同定义容器生命周期](https://developer.qcloudimg.com/http-save/yehe-7872026/f73812f54a19ebe4afa42b02b112581b.png)

Java 服务放进容器后，最容易被简化成三个参数：镜像名、内存限制和健康端口。但要让一个进程长期受平台管理，还必须明确启动容错、可写目录、堆外余量，以及"暂时不能接流量"与"必须重启"之间的区别。
RuoYi Office 实验室中的聚合后端与 BPM 服务，提供了两个具体的配置观察对象。本篇沿着镜像 → 运行权限 → 内存 → 探针生命周期依次展开，并借助已有的 OA 聚合镜像，在专用 `blog-acceptance` 环境中完成启动采样、摘流恢复和一次重启恢复实验。
实验使用独立的 MySQL/Redis 和脱敏基线，网络仅允许测试环境内部、DNS 及监控入站。探针故障只作用于测试副本，没有重启原有的四格业务。实验镜像、资源和探针设置与现有业务配置分别说明，其中的数值不作为生产容量承诺。
## 一、镜像固定的是启动材料，环境配置另有生命周期

后端镜像消费经过检查的可执行 Jar，构建模板以非 root 用户启动。以下摘自实验室 cloud 流水线的 Dockerfile 模板，其中 `@@JAVA_RUNTIME_IMAGE@@` 是渲染时替换的固定运行镜像输入，并非可直接执行的值：
```dockerfile
FROM @@JAVA_RUNTIME_IMAGE@@
WORKDIR /app
COPY --chown=1000:1000 app.jar /app/app.jar
ENV SERVER_PORT=8080 SPRING_PROFILES_ACTIVE=lab JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=65 -XX:+ExitOnOutOfMemoryError -Duser.home=/data"
USER 1000:1000
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/app.jar"]
```

`EXPOSE` 只声明镜像的端口信息，不会自动创建 Kubernetes Service，也不会向外开放网络。`USER` 指定默认启动身份，但运行时的 securityContext 还应与镜像目录权限保持一致。
这个模板将Jar整体复制进镜像，没有据此证明已经实现分层Jar构建缓存。镜像可启动、镜像可追溯和跨构建缓存有效，是不同的检查结果。

![Jenkins中本次OA聚合测试镜像对应的既有构建产物](https://developer.qcloudimg.com/http-save/yehe-7872026/4060e20c27b88fabbcb22171fd99d7cb.png)

*▲ 实验复用已有OA聚合构建#3的锁定镜像，没有为写文章重新发布业务环境。*

实际运行配置从外部挂载读取。配置文件存在、挂载更新、Spring重新绑定和Pod重建的生命周期也不同；不能因为挂载文件变了就声称应用已经热更新。

## 二、非root与只读根文件系统要分别核对

当前聚合后端与BPM容器都显式设置UID/GID为1000，禁止提权并移除全部Linux capabilities。选定字段如下：

```yaml
securityContext:
  runAsUser: 1000
  runAsGroup: 1000
  allowPrivilegeEscalation: false
  capabilities:
    drop: [ALL]
```

这不是“容器已经完全隔离”的证明，网络、挂载、内核及平台权限还各有边界。当前选定容器securityContext未设置`readOnlyRootFilesystem`，不能将非root直接写成根文件系统只读。

当前`/config`和`/trust`挂载只读，`/data`可写。把用户目录设到`/data`，有助于将应用需要的文件写入位置显式化；仍需核对临时文件、任务日志、字体或文档处理组件是否写入其他路径。

如果未来开启只读根文件系统，应先盘点实际写入路径、准备对应卷，再在隔离副本验证。直接加一个安全字段可能让应用启动失败，不能为了展示“加固”修改现有服务。

![隔离OA聚合测试Pod的实际运行详情](https://developer.qcloudimg.com/http-save/yehe-7872026/7b86bce6b493bacb4934bfc2b692227a.png)

*▲ 独立Pod、挂载和运行状态可以与实验记录对账，不能从非root推导所有目录只读。*

## 三、65%的堆配置，不代表其余内存不会超限

容器总内存不仅有Java堆，还包含元空间、代码缓存、线程栈、直接内存、JVM本身及其他原生分配。镜像中的百分比参数是一项输入，实际最大堆和使用量仍需从运行时核对。

当前BPM的资源声明如下：

```yaml
resources:
  requests:
    cpu: 100m
    memory: 768Mi
  limits:
    cpu: "2"
    memory: 2Gi
```

聚合后端的memory request为2Gi、limit为6Gi，两者承担的模块集合不同，不能用这两份声明计算架构性能倍数。request是调度预算，也不是进程不得超过的使用量上限。

`kubectl top`的单次运行快照不能回答启动峰值。因此本次另外对OA聚合测试副本采集连续时间轴：memory limit为4Gi，CPU limit为2核，沿用65%的堆配置输入，共50个采样点、约216秒，中位采样间隔4.36秒。

实验同时读取`/proc/1/status`的RSS、容器cgroup内存计数，以及Actuator的堆/非堆指标。启动阶段观察到的最大RSS采样值约1490.4MiB；包括后续重启的全窗口最大RSS采样值约1829.8MiB。两者均不是无遗漏的瞬时峰值，更不能外推所有服务。

末次采样的Java堆used约747.6MiB、非堆used约237.5MiB、RSS约1829.8MiB，cgroup内存约1836.8MiB。最大堆指标为2664MiB。堆used明显不能代表整个容器；但这些指标的范围不同、请求也非原子采集，不能简单相减就得到精确的“所有堆外内存”。

![真实隔离实验的RSS容器内存JVM指标以及就绪重启时间轴](https://developer.qcloudimg.com/http-save/yehe-7872026/000ccfe5d55dc2b957529f09dee347f8.png)

*▲ 端点尚未暴露时，图上保留堆数据缺口；没有用RSS补造JVM数据。时间从采样器开始计算，不代表完整发布耗时。*

取证中还遇到一个实际缺口：这份既有镜像有Actuator，却没有可用的`/actuator/prometheus`端点。首次采样因此未完成；保留该记录后，仅给测试副本增加实际MetricsEndpoint的暴露配置，再从冷启动重新采样。配置中写了`prometheus`，不代表镜像已经包含对应注册表和端点。

`ExitOnOutOfMemoryError`面向JVM识别到的OOM行为；容器因内存限制被内核终止时，还应检查退出原因和平台事件。不能把所有重启都归咎于Java堆不足，也不能仅看一条启动日志判断是否存在OOM。

## 四、startup给启动留窗口，不能代替服务依赖检查

两个观察对象当前使用相同TCP startup探针：

```yaml
startupProbe:
  tcpSocket:
    port: 8080
  periodSeconds: 10
  timeoutSeconds: 1
  failureThreshold: 60
  successThreshold: 1
```

配置给启动失败提供了较宽的容忍窗口。不能把`60×10`机械写成每次必然等待600秒：实际探测调度、超时和启动成功时刻都会影响观察结果，应记录平台事件时间轴。

TCP成功只说明端口能够建立连接。它不验证数据库连接、Nacos注册、租户权限或审批链已经准备好。对有业务健康端点的服务，应根据真实实现设计HTTP检查，不能直接写入一个不存在的`/health`路径。

startup成功后才进入正常的readiness/liveness探测节奏。本次测试保留TCP8080作为startup检查，周期改为5秒、失败阈值为60，观察到端口未监听时的失败事件，随后自然成功；首个同时Ready且有JVM堆数据的采样点为74.27秒。

![三类探针在现有业务配置与隔离实验中的职责对照](https://developer.qcloudimg.com/http-save/yehe-7872026/19cc5a3cb899692bb1329ca840e6be11.png)

*▲ 原有业务采用TCP探针；实验为了分离机制，使用文件开关注入readiness/liveness失败，阈值也不同，不是推荐生产参数。*

## 五、readiness失败通常先摘流，liveness失败才涉及重启

当前两个服务的readiness每10秒检查一次TCP 8080，连续失败阈值为6；liveness每30秒检查一次，失败阈值为3。最终实验需分别观察EndpointSlice就绪状态、Pod Ready条件和restartCount，不能只看容器进程是否存在。

readiness的职责是表达是否适合接收流量，不应把一个短暂下游抖动直接升级为无止境的重启。liveness应表达进程是否需要被平台重启；将所有外部依赖加入存活判断，可能在依赖故障时制造重启风暴。

这不是拒绝所有依赖检查，而是要求先定义预期行为：下游不可用时，服务是否还能完成部分请求？应拒绝流量、返回降级结果，还是确实需要重启？答案必须与业务职责相符。

本次用文件开关隔离验证两种行为，配置仅用于测试副本：

```yaml
readinessProbe:
  exec:
    command: [sh, -c, "test ! -f /data/readiness-fail"]
  periodSeconds: 3
  failureThreshold: 1
livenessProbe:
  exec:
    command:
      - sh
      - -c
      - "if test -f /data/liveness-once; then rm /data/liveness-once; exit 1; fi"
  periodSeconds: 10
  failureThreshold: 1
```

创建readiness标记后，约101.22秒的采样点显示Pod Ready和EndpointSlice ready均为false，restartCount仍为0；移除标记后恢复。随后创建一次性liveness标记，由探针删除该标记并返回失败，避免形成无限重启循环。

约119.04秒观察到restartCount变为1，进程RSS也回到启动阶段；约197.55秒同时恢复Ready、就绪端点和JVM堆指标，末段继续保持一次重启。状态接口存在传播延迟，时间只描述这次采样，不能当作平台保证的摘流/重启耗时。

![KubeSphere中同一测试Pod的启动就绪存活探针事件](https://developer.qcloudimg.com/http-save/yehe-7872026/bf356d62a2c3f8f44de9251dfa3a4a69.png)

*▲ 事件和采样共同证明失败与恢复；不是仅从最后一张Ready截图推断中间过程。*

![隔离测试Service及恢复后的后端端点详情](https://developer.qcloudimg.com/http-save/yehe-7872026/9bb3734ab1c476467fb0226a74b7b497.png)

*▲ Service用于核对接流目标；是否适合提供业务服务，还需要真实业务健康定义。*

## 六、资源与更新策略一起决定可用性

当前两个观察对象均为1副本，更新策略允许`maxSurge: 0`、`maxUnavailable: 1`。这是节约并存资源的取舍，也允许替换期间出现不可用。

即使配置了三类探针，也不能因此承诺无停机发布。探针帮助平台决定何时接流或重启，不会凭空提供第二个可用实例；扩成多副本又需要核对任务、消费者、会话与业务幂等。

资源调整同样应依据真实指标。先记录启动和稳定阶段，再区分CPU受限、堆增长、线程增长和堆外分配，逐步调整预算。本次只验证一个OA聚合副本的有限窗口，没有执行长期负载或OOM压力测试，也没有给出所有服务通用的内存推荐值。

![KubeSphere中隔离测试应用的独立部署详情](https://developer.qcloudimg.com/http-save/yehe-7872026/580bdc99fb1cd1bf853413adf684c00c.png)

*▲ 测试副本有自己的资源、配置和数据身份，原有业务没有参与探针故障注入。*

## 七、把失败与恢复留在同一条证据链

这次证据包含同一run-id下的镜像digest、配置身份、容器规格、启动日志、堆/非堆/进程采样、探针事件、EndpointSlice变化、restartCount与恢复后指标读取。

预检验证了测试库可连接，而到现有infra数据库的TCP连接被隔离策略阻断；导入的是校验过的脱敏基线，没有借用现有业务数据写入身份。实验设置了节点余量与连续重启停止条件，没有触及停止阈值。

![Loki中测试Pod首次启动与重启恢复的真实启动日志](https://developer.qcloudimg.com/http-save/yehe-7872026/b9417288938d5201ed95256a328632f5.png)

*▲ 同一Pod的两次启动记录与restartCount对应。Started只是进程启动证据，没有证明用印或审批业务闭环。*

本次文件标记已移除，探针恢复成功，临时应用保留在隔离环境供后续已授权的发布回退和应用观测实验复用。整套补测结束后按run-id回收临时资源；没有为了本篇删除或重建原四格环境。

这种方法适合先验证平台生命周期，再逐步加入业务健康语义。面对数据库不可用、下游超时、线程池耗尽或真实流量下的内存问题，应设计对应实验；本次文件开关和启动采样没有代替这些测试。

## 常见问题（FAQ）

### 设置MaxRAMPercentage后，还需要留堆外余量吗？

需要。堆只占Java进程内存的一部分，还要观察线程、直接内存、元空间及其他原生分配。

### TCP探针成功就说明业务健康吗？

不能。它只验证端口连接，业务健康必须根据真实服务职责和接口验证。

### readiness失败会立即重启容器吗？

其主要作用是改变接流资格。重启行为应结合startup/liveness、容器退出和事件判断。

### 非root是不是已经启用了只读根文件系统？

不是。运行身份和根文件系统可写性是不同配置，需要分别核对。

### 一次kubectl top能作为启动峰值吗？

不能。启动峰值需要覆盖启动窗口的连续采样并说明指标定义与采样间隔。


你们的存活检查是否也把短暂下游故障升级成了重启？欢迎结合实际依赖讨论探针边界。


Java 服务放进容器后，最容易被简化成三个参数：镜像名、内存限制和健康端口。但要让一个进程长期受平台管理，还必须明确启动容错、可写目录、堆外余量，以及"暂时不能接流量"与"必须重启"之间的区别。RuoYi Office 实验室中的聚合后端与 BPM 服务，提供了两个具体的配置观察对象。本篇沿着镜像 → 运行权限 → 内存 → 探针生命周期依次展开，并借助已有的 OA 聚合镜像，在专用 blog-acceptance 环境中完成启动采样、摘流恢复和一次重启恢复实验。实验使用独立的 MySQL/Redis 和脱敏基线，网络仅允许测试环境内部、DNS 及监控入站。探针故障只作用于测试副本，没有重启原有的四格业务。实验镜像、资源和探针设置与现有业务配置分别说明，其中的数值不作为生产容量承诺。

SpringCloud+Vue3开源RuoyiOffice框架容器化实战：镜像、JVM 内存与三类探针如何配合

SpringBoot微服务装进容器后，如何管理内存、启动与健康检查？结合RuoYi Office真实镜像模板和运行配置，拆解非root权限、可写目录、JVM堆外余量、资源声明及三类探针的分工，说明TCP检查和业务健康的边界，并以独立实验补齐启动采样与失败恢复证据。

云计算

运维

后端

SpringCloud+Vue3开源RuoyiOffice框架容器化实战：镜像构建、JVM内存配置与三类探针（startup/readiness/liveness）协同机制详解。通过OA聚合后端与BPM服务实验，演示非root权限、内存限额及探针生命周期管理，验证摘流恢复与重启策略，提供Java服务容器化部署最佳实践参考。

压力测试

文件系统

文档处理

代码解释

数据库

容器

MySQL

Redis

Java

让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

SpringCloud+Vue3开源RuoyiOffice框架容器化实战：镜像构建、JVM内存配置与三类探针（startup/readiness/liveness）协同机制详解。通过OA聚合后端与BPM服务实验，演示非root权限、内存限额及探针生命周期管理，验证摘流恢复与重启策略，提供Java服务容器化部署最佳实践参...

SpringCloud+Vue3开源RuoyiOffice框架容器化实战：镜像、JVM 内存与三类探针如何配合-腾讯云开发者社区-腾讯云

SpringCloud+Vue3开源RuoyiOffice框架容器化实战：镜像、JVM 内存与三类探针如何配合

SpringCloud+Vue3开源RuoyiOffice框架容器化实战：镜像、JVM 内存与三类探针如何配合

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐