从离线部署到K8s流水线发布：一线工程师的实战总结

在没有联网的环境中部署应用，我们采取了一套离线部署 Jar 包的方案。主要步骤包括：

• 准备可执行 Jar：通过 CI 在内网构建出可执行的 uber JAR（将依赖打包），或将所有依赖手动下载好。确保版本正确且依赖完整，避免部署后因无法联网下载依赖而失败。
• 离线传输包：将 Jar 包传输至目标服务器。传输前后使用 MD5 校验保证文件完整性。例如，通过 scp 将文件拷贝到服务器：

scp app-1.0.jar [email protected]:/opt/deploy/app-1.0.jar

• 配置运行环境：在目标服务器上离线安装所需的 JDK 环境。如需特定配置（例如数据库连接、缓存地址等），通过配置文件或环境变量预先准备好。我们采用在 Jar 同目录放置 application.properties 或使用启动参数指定配置路径的方式。
• 启动应用进程：使用 nohup 或 systemd 启动 Jar 并确保其在后台持续运行：

nohup java -jar /opt/deploy/app-1.0.jar --spring.config.location=/opt/deploy/config/ &

这样即使终端关闭，应用仍持续运行，日志输出重定向到 nohup.out 或指定的日志文件。

• 验证部署结果：检查应用日志和端口监听确保启动成功。例如，通过 tail -f nohup.out 实时查看日志确认没有报错，以及使用 netstat -tunlp | grep 8080 确认服务端口已被监听。

以上流程保证了在无外网环境下顺利部署应用。但该手工方式也存在明显缺点：每次更新都需人工介入，多台服务器部署容易出现版本不一致或遗漏步骤的问题。随着发布频率提高，我们意识到需要更加自动化和标准化的方式。

Cassandra 大表导出

项目运营过程中，我们曾需要将 Cassandra 数据库中某张包含亿级记录的"大表"导出备份。这项任务在没有合适工具时非常棘手：

• 初始尝试与问题：一开始我们尝试直接用 CQL 查询全部数据并写入文件，但由于数据量太大，这种方式在客户端经常导致内存溢出或超时。随后尝试使用 cqlsh 自带的 COPY 命令：

COPY keyspace_name.table_name TO 'export.csv';

该命令可以将查询结果直接导出为 CSV 文件。然而在面对数亿行数据时，COPY TO 运行非常缓慢，中途容易因为网络波动或超时失败，恢复起来也麻烦。

• 优化方案：分片批量导出：我们决定采用分批导出策略，将大表拆分为小块依次导出。具体做法是利用主键或时间范围分段：编写脚本按范围查询数据，每次导出几十万行追加到文件。这种分段处理避免单次传输过多数据导致压力过大。在导出过程中，我们监控 Cassandra 节点的状态，错开业务高峰时间执行，以降低对线上读写的影响。
• 借助专业工具：后来我们引入了 DataStax 提供的 Bulk Loader (DSBulk) 工具，它专门用于 Cassandra 的数据批量导入导出。使用 DSBulk，我们可以一条命令完成整个表的导出：

dsbulk unload -k keyspace_name -t table_name -url export_data/ -maxRetries 5

DSBulk 内部对读取进行了优化和并行处理，导出效率较高，并提供断点续传等功能。在一次测试中，使用 DSBulk 将一张约5千万行的表导出为 CSV，耗时从最初的数小时缩短到不到1小时，大大提升了效率。

• 结果与验证：导出完成后，务必验证数据完整性。我们通过对比导出行数和 Cassandra 中记录数来校验是否有遗漏，并随机抽样对比内容。导出的 CSV 则压缩归档保存，以便日后可能的恢复或分析使用。

通过上述方法，我们成功解决了 Cassandra 大表导出难题。在没有专用工具时，分段导出是可行的折中方案；而借助专业工具后，大规模数据迁移的可靠性和效率都显著提高。

常见启动故障案例

在应用部署和运行过程中，我们还遇到过Java 应用启动失败的情况。其中两类印象深刻的故障来自第三方组件：Atomikos 分布式事务管理器和 Curator Zookeeper 客户端。下面分别分享我们排查和解决问题的经过。

Atomikos 导致的启动异常

我们有一套服务使用 Atomikos 作为分布式事务管理器（用于多数据源事务）。某次在同一台服务器上启动两套服务时，应用在初始化 Atomikos 事务管理器时抛出了异常，导致启动失败。日志片段如下：

com.atomikos.icatch.SysException: Error in init: Log already in use? tmlog in ./
    at com.atomikos.icatch.impux.TransactionServiceImp <...> 
Caused by: com.atomikos.recovery.LogException: Log already in use by another process.

从错误可以看出，Atomikos 尝试创建事务日志文件时发生冲突（Log already in use）。原因是同一环境中同时运行了多个使用 Atomikos 的应用，且它们默认使用相同路径的事务日志文件，导致后启动的进程无法获取文件锁。

解决过程：我们确认前一个服务正在使用 Atomikos 默认的事务日志（通常存放于应用运行目录下的 transaction-logs 文件夹）。为了解决冲突，我们采取了两种措施之一：

• 方案一：分隔事务日志路径 – 修改每个应用的 Atomikos 日志配置，使其使用不同的日志目录或文件名称。比如在 Spring Boot 配置中指定：

spring.jta.atomikos.log-dir=./transaction-logs-app2

这样第二个应用的事务日志将写入独立目录，避免与第一个应用争用同一文件。

• 方案二：错开启动顺序或合并应用 – 如业务允许，将相关模块合并部署到同一个 JVM 内，避免多个进程争夺资源；或者确保同时运行的只有一个 Atomikos 实例。如果必须分开部署，也可以通过容器化等方式隔离运行环境。

采用了修改日志路径的方法后，我们重新启动应用，Atomikos 初始化成功，冲突不再发生。这个案例提醒我们：中间件的默认配置不一定适用于特殊场景，需根据部署情况做适当调整。例如，对于需要在同一主机部署多实例的组件，要检查是否有共享资源（文件、端口等）冲突，并通过配置加以区分。

Curator 导致的启动卡顿

另一问题来自于 Apache Curator，一个常用的 ZooKeeper 客户端框架。某微服务在启动时使用 Curator 连接 ZooKeeper 做服务注册，但我们发现在某环境下启动过程长时间卡住，日志不断打印异常：

org.apache.curator.CuratorConnectionLossException: KeeperErrorCode = ConnectionLoss
	at org.apache.curator.ConnectionState.getZooKeeper(ConnectionState.java:123)
	... 

日志提示 Curator 连接丢失，一直在重试 (ConnectionLoss 表明无法连接 ZooKeeper 集群)。这种情况导致应用阻塞在启动阶段。经过排查，我们找到以下原因：

• ZooKeeper 服务未启动：首先怀疑 ZooKeeper 本身不可用。我们登陆到 ZooKeeper 所在服务器，运行 zkServer.sh status 发现服务确实没有启动。在这个测试环境中，ZooKeeper 被意外关闭而我们没有注意。
• 防火墙或网络问题：在确认启动 ZooKeeper 服务后，依然出现连接失败。这让我们检查服务器防火墙设置，结果发现 ZooKeeper 默认端口被防火墙拦截。关闭或开放防火墙相关端口后，Curator 客户端才成功连上 ZooKeeper。
• 错误的连接配置：另一种常见原因是配置的连接字符串不正确。例如写错了 ZooKeeper 集群的 IP 地址或端口，或者 DNS 无法解析。在本次事件中虽未出现这种错误，但我们在自查过程中也验证了配置项以排除这类因素。

解决方案：针对上述原因采取了相应措施——启动 ZooKeeper 服务进程，并调整防火墙策略允许访问 ZooKeeper 的端口（例如2181）。随后重启微服务，Curator 成功建立连接，应用顺利启动。为防止此类问题再次发生，我们还完善了启动脚本：在部署应用前增加对依赖服务的健康检查，如自动检测 ZooKeeper 的状态，如果未就绪则给予提示或延迟启动。同时，将 Curator 客户端的超时和重试参数调得更加合理，使其在连接异常时能及早抛出错误而非无限卡顿。

通过以上两个案例，我们深刻体会到启动故障排查需要结合日志迅速定位，并关注依赖组件的配置与运行环境。无论是事务管理器还是注册中心客户端，理解其工作机制和配置项，有助于快速找到问题根源并加以解决。

Kubernetes 标准发布流程

在解决了初步的部署和运行问题后，我们着手引入 Kubernetes (K8s) 来重构发布流程。目标是实现从构建、部署到发布的流水线自动化，将过去繁琐的手工步骤标准化。下面介绍我们落地 K8s 标准发布的实践过程：

• 容器化应用：首先，我们为应用创建了 Docker 镜像。编写了简洁的 Dockerfile，将可执行 Jar 包打入镜像。例如：

FROM openjdk:8-jre-slim
COPY app-1.0.jar /app/app.jar
CMD ["java", "-jar", "/app/app.jar", "--spring.config.location=/app/config/"]

我们将应用运行所需的配置文件也打包进镜像的 /app/config/ 目录（或挂载 ConfigMap，见后续），以确保容器启动时能找到正确配置。完成 Dockerfile 后，通过内网的 CI 工具构建镜像并推送到私有镜像仓库（如 registry.example.com/myteam/app:1.0）。

• 编写 K8s 部署清单：接着，我们编写 Kubernetes 清单文件，包括 Deployment、Service 等资源。示例 Deployment 清单片段：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: registry.example.com/myteam/app:1.0
        ports:
        - containerPort: 8080
        env:
        - name: JAVA_OPTS
          value: "-Xms512m -Xmx512m"
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 5
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10

上述清单定义了两个副本的部署，并配置了应用容器使用我们构建的镜像。同时设置了 就绪探针 (Readiness Probe) 和 存活探针 (Liveness Probe)，定期访问应用的健康检查接口 /health。这些探针确保应用只有在健康时才接受流量，并在异常时自动重启容器，提高发布过程的可靠性。

• 配置管理：对于应用需要的配置和敏感信息，我们避免硬编码进镜像，而是使用 ConfigMap 和 Secret 来提供。在 Deployment 清单中通过挂载方式或环境变量引用这些配置。例如数据库连接字符串用 Secret 存储，启动时通过环境变量注入。这样在不同环境下（测试、生产）可以使用不同的配置而不需更改镜像。
• CI/CD 流水线：我们将构建和部署步骤集成到 CI/CD 工具（如 Jenkins 或 GitLab CI）的流水线中。当代码合并到主干分支时，流水线自动执行：编译测试 -> 构建Docker镜像 -> 推送镜像 -> 部署到 K8s 集群。部署阶段通过 kubectl apply -f 或 Helmsman 等工具将预先编写的 K8s 清单应用到集群。配合 Deployment 控制器的滚动更新策略，发布新版本时旧容器逐步替换为新容器，实现零停机发布或最小化服务中断。
• 发布规范和审核：为了保障每次发布质量，我们制定了发布前的检查清单，例如：
  • 确认新版本在测试环境通过完整回归测试；
  • 镜像扫描无高危漏洞；
  • YAML 清单遵循公司内部规范（如标签、资源配额Requests/Limits设置齐全等）；
  • 灰度发布策略：对于重大版本采用分批发布，先在一小部分实例上部署观察运行状况，再逐步扩至全量。

通过 Kubernetes 的标准化部署，我们的应用发布从此进入流水线作业，实现了一键部署和回滚，减少了人为失误。每次部署都有记录和监控，使得问题追溯和快速恢复更加方便。

日志监控体系搭建

随着系统逐步走向容器化和分布式，我们同步建立了完善的日志和监控体系，用于运维过程中的故障诊断和性能调优。

• 集中式日志系统：过去日志分散在各台服务器，出问题时需要逐台登录检索。我们引入了 ELK/EFK 日志系统，将容器日志集中收集。具体做法是在 Kubernetes 集群部署 Filebeat/Fluentd 日志收集器，从各容器的 stdout 和 stderr 获取日志流，发送到集中存储（Elasticsearch 日志库）。在应用中，我们使用统一的日志格式（例如 JSON 格式日志），包含时间戳、级别、线程、请求ID等字段，方便在 Kibana 中检索和过滤。现在，当某服务发生错误，我们可以在 Kibana 一处查看该服务所有实例的日志，按照时间线追踪问题，大大提升排查效率。
• 性能指标监控：我们搭建了基于 Prometheus + Grafana 的监控系统。Prometheus 定时抓取各服务的指标数据（包括基础资源如CPU、内存，及应用自定义指标如请求次数、错误率），Grafana 则用来可视化展示。我们在应用中集成了 Micrometer 库，将业务指标暴露给 Prometheus。通过定制仪表盘，可以实时看到系统的 QPS、响应时间分布、数据库连接数等关键指标。配合 Alertmanager 设置告警规则，一旦某指标超过阈值（如 CPU 长时间过高、错误率突增），系统会自动通过短信或钉钉机器人通知相关人员及时响应。
• 链路追踪和分析：除了日志和指标，我们还评估了链路追踪工具（如 SkyWalking、Jaeger）用于分布式调用跟踪。在复杂的微服务环境中，这类工具可以帮助我们追踪一次用户请求经过的多个服务，定位在哪一环节出现瓶颈或错误。不过由于部署和使用成本较高，我们团队根据实际需要选择了逐步试点部分核心链路的追踪，而日志和指标监控仍是主要的运维手段。

通过日志和监控体系的搭建，我们实现了对系统 可观察性（Observability） 的极大提升。从以前出故障"盲人摸象"式的猜测，转变为现在有数据支撑的精准分析。不仅故障恢复时间（MTTR）降低了，日常性能调优也有据可依，整体运行维护更加从容。

效果评估（优化前后对比）

通过上述一系列改进，我们对比了优化前后的效果：

（表：系统在部署和运维方面优化前后的对比）

从上表可以看出，系统经过改造后在发布效率、可靠性和可维护性方面都有了显著提升。例如发布效率方面，由原来的每次发布耗时半小时、需多人配合，优化为流水线后通常几分钟即可完成，且基本零人工干预。再如故障排查，以前可能需要1-2小时集中分析日志才能找到问题，现在借助集中日志和监控报警，很多问题在几分钟内就能检测并通知相关人员。总体而言，这些实践优化了团队的 DevOps 工作模式，为业务快速迭代提供了坚实保障。

总结提升

通过这次从离线部署到 K8s 流水线发布的实践，我们团队收获了宝贵的经验教训，也验证了新技术在生产环境中的价值。在总结几点体会的同时，我们也展望未来的改进方向：

• 实践体会：
  1. 基础设施即代码的重要性：无论是部署脚本、K8s 清单还是监控告警配置，都应纳入版本管理，通过代码审阅和流水线执行确保一致性。
  2. 工具选型需结合实际：例如在大数据导出时，选择专业工具大幅提高效率；在监控方面，不盲目追新，而是根据团队能力循序渐进地引入适合的组件。
  3. 故障演练和预案：在实现了自动化和监控后，更应定期演练故障场景（如单点故障、发布失败回滚等），确保团队对新体系下的异常处理熟练有素。
• 未来改进：我们计划进一步完善持续交付，实现一键部署到多环境和蓝绿发布/金丝雀发布等高级策略。同时，在 Observability 方面引入分布式追踪全面监控请求链路，并评估服务网格(Service Mesh)等技术来增强流量控制和安全治理。这些将成为下一步提升的方向。

最后，希望本次实战总结对各位读者有所启发。技术改进是一个渐进的过程，从离线部署的摸索到云原生实践的落地，每一步都伴随着挑战和收获。作为一线工程师，我们应当拥抱新技术带来的变革，同时保持对细节问题的敏感，积累经验，不断优化系统的稳定性和交付效率。在未来的项目中，我们将继续沉淀更多实践案例，与大家分享交流！