Java 程序员第 43 阶段15：微服务整合大模型，跨服务调用架构设计实战，Docker容器化部署

原创于 2026-06-20 11:00:00 发布 · 189 阅读

本内容遵循CC 4.0 BY-SA版权协议

标签

#java #微服务 #docker

容器化技术已经成为现代云原生应用部署的标准方式。Docker 作为容器技术的代表，以其轻量级、可移植、易管理的特性，彻底改变了应用的构建、分发和运行方式。当大模型服务被整合到微服务架构中时，容器化部署不仅能够简化依赖管理，还能提供资源隔离、环境一致性、可弹性伸缩等关键能力。

本章将全面介绍 Docker 容器化在微服务大模型架构中的应用，从 Docker 基础概念到企业级镜像构建实践，帮助读者掌握构建生产级别容器化部署的核心技术。

15.1.1 容器化技术概述与核心原理

Docker 是一个开源的容器化平台，于 2013 年由 dotCloud 公司发布（后更名为 Docker Inc.）。Docker 通过操作系统级虚拟化技术，将应用程序及其所有依赖打包为一个轻量级的可移植容器镜像，使得应用程序可以在任何支持 Docker 的环境中一致地运行。

Docker 的核心原理建立在 Linux 内核的命名空间（Namespace）和控制组（Cgroups）两大特性之上。命名空间提供了进程隔离的能力，每个容器都有自己的网络命名空间、进程命名空间、挂载命名空间等，容器内的进程看不到宿主机的其他进程，也无法访问宿主机的资源。Cgroups 则提供了资源限制和优先级管理的能力，可以限制容器使用的 CPU、内存、磁盘 I/O 等资源。

与传统的虚拟机相比，Docker 容器的启动速度更快（秒级 vs 分钟级），资源开销更低（容器共享操作系统内核，无需虚拟化硬件），镜像体积更小（MB 级别 vs GB 级别）。这些特性使得 Docker 成为微服务架构中服务封装和部署的理想选择。

15.1.2 容器化对大模型服务的价值

大模型服务的部署面临着独特的挑战：模型文件体积庞大（从数 GB 到数十 GB 不等），推理计算需要大量 GPU 资源，依赖环境复杂（深度学习框架、CUDA 驱动等）。容器化技术为解决这些挑战提供了有效手段。

首先，容器化实现了环境一致性。在传统部署模式下，将大模型服务从开发环境迁移到测试环境，再到生产环境，常常遇到依赖版本不一致、路径差异、权限问题等各种"环境差异常见病"。通过 Docker 镜像，这些问题得到根本解决——应用及其所有依赖被打包在一起，在任何环境中都保持完全一致。

其次，容器化简化了复杂依赖的管理。大模型服务通常依赖特定的 Python 版本、CUDA 版本、深度学习框架版本等，这些依赖之间的兼容性往往比较脆弱。使用 Docker，可以将这些依赖与基础镜像一起打包，形成一个稳定、可复现的运行环境。

# 大模型服务的基础镜像选择
FROM nvidia/cuda:12.1.0-runtime-ubuntu22.04
# 设置中文 locale
RUN apt-get update && apt-get install -y \
    locales \
    && locale-gen zh_CN.UTF-8 \
    && apt-get clean
ENV LANG=zh_CN.UTF-8 \
    LC_ALL=zh_CN.UTF-8
# 安装 Python 和基础依赖
RUN apt-get update && apt-get install -y \
    python3.11 \
    python3.11-dev \
    python3-pip \
    && ln -sf /usr/bin/python3.11 /usr/bin/python \
    && ln -sf /usr/bin/pip3 /usr/bin/pip \
    && apt-get clean
# 安装 PyTorch 和 Transformers
RUN pip install --no-cache-dir \
    torch==2.1.0 \
    transformers==4.35.0 \
    accelerate==0.24.0 \
    sentencepiece==0.1.99 \
    protobuf==3.20.3

第三，容器化提供了良好的资源隔离能力。在多模型部署场景中，不同的模型可能需要不同的依赖版本或配置，通过容器化可以将它们隔离运行，避免相互影响。同时，Kubernetes 等容器编排平台可以根据资源使用情况动态调度容器，充分利用 GPU 等稀缺资源。

15.1.3 Docker 核心组件与架构

Docker 引擎是 Docker 技术的核心，由三个主要组件构成：Docker Daemon（dockerd）是运行在后台的守护进程，负责管理镜像、容器、网络、卷等 Docker 对象；Docker Client 是命令行工具，用户通过它与 Docker Daemon 交互；Docker Registry 是存储和分发镜像的仓库服务，Docker Hub 是官方公共仓库。

容器是 Docker 的运行实例，通过镜像创建。一个镜像可以创建多个容器，每个容器都是相互隔离的运行实例。容器可以被启动、停止、删除，数据可以通过卷（Volume）持久化。

# Docker 常用命令速查
# 镜像操作
docker pull python:3.11-slim          # 从仓库拉取镜像
docker images                          # 列出本地镜像
docker build -t llm-service:v1.0 .     # 构建镜像
docker rmi llm-service:v1.0            # 删除镜像
docker tag source:tag target:tag       # 为镜像打标签
# 容器操作
docker run -d --name llm-container \
    -p 8080:8080 \
    --gpus all \
    -v /data/models:/models \
    llm-service:v1.0                   # 创建并启动容器
docker ps -a                           # 列出所有容器
docker start/stop/restart container    # 启停容器
docker logs -f container               # 查看容器日志
docker exec -it container /bin/bash   # 进入容器终端
docker cp file container:/path         # 复制文件到容器
docker rm -f container                 # 删除容器

15.2.1 多阶段构建与镜像优化

Docker 镜像体积直接影响构建速度、部署效率和存储成本。一个优化良好的镜像应该只包含运行应用必需的内容，去除所有构建工具和中间产物。多阶段构建（Multi-stage Build）是实现这一目标的核心技术。

多阶段构建允许在 Dockerfile 中使用多个 FROM 指令，每个 FROM 指令开启一个独立的构建阶段。通常的做法是：在第一个阶段中使用包含完整开发工具的基础镜像进行代码编译和依赖安装；在第二个阶段中只复制编译产物和运行时依赖，使用轻量级基础镜像创建最终镜像。

对于 Java 微服务应用，多阶段构建尤为重要。可以使用 Maven 或 Gradle 官方提供的构建镜像进行编译，然后将编译得到的 JAR 文件复制到 JRE 基础镜像中创建最终镜像。这种方式可以将最终镜像体积从数百 MB 降低到一百 MB 左右。

# Java 微服务的多阶段构建示例
# 阶段一：构建阶段
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /build
# 复制依赖文件先下载，提升构建缓存命中率
COPY pom.xml .
RUN mvn dependency:go-offline -B
# 复制源代码并构建
COPY src ./src
RUN mvn package -DskipTests -B
# 阶段二：运行环境
FROM eclipse-temurin:17-jre-jammy
WORKDIR /app
# 从构建阶段复制 JAR 文件
COPY --from=builder /build/target/*.jar app.jar
# 添加非 root 用户，提高安全性
RUN groupadd -r appgroup && useradd -r -g appgroup appuser
RUN chown -R appuser:appgroup /app
USER appuser
# 暴露端口
EXPOSE 8080
# 健康检查
HEALTHCHECK --interval=30s --timeout=10s --start-period=60s --retries=3 \
CMD curl -f http://localhost:8080/actuator/health || exit 1
# 启动命令
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

15.2.2 大模型服务的镜像构建策略

大模型服务的镜像构建有其特殊性，因为模型文件通常体积庞大（从几 GB 到几十 GB 不等），且可能涉及敏感的知识产权。在实际生产环境中，模型文件通常不会打包在 Docker 镜像中，而是通过卷挂载或配置中心下载的方式加载。

一种推荐的策略是构建一个通用的基础镜像，包含所有运行时依赖，但不含具体模型文件。应用启动时从配置的模型路径加载模型。这种方式既保证了镜像的可复用性，又提供了部署灵活性。

# 大模型服务的通用基础镜像
FROM nvidia/cuda:12.1.0-runtime-ubuntu22.04
ENV DEBIAN_FRONTEND=noninteractive
ENV PYTHONUNBUFFERED=1
# 系统依赖
RUN apt-get update && apt-get install -y \
    python3.11 \
    python3.11-dev \
    python3-pip \
    curl \
    git \
    wget \
    vim \
    && rm -rf /var/lib/apt/lists/*
# Python 依赖 - 使用国内镜像加速
RUN pip config set global.index-url https://mirrors.aliyun.com/pypi/simple/ \
    && pip install --no-cache-dir \
    torch==2.1.0 \
    transformers==4.35.0 \
    accelerate==0.24.0 \
    langchain==0.0.340 \
    fastapi==0.104.0 \
    uvicorn==0.24.0 \
    pydantic==2.4.2 \
    httpx==0.25.1 \
    && pip cache purge
# 创建应用目录
RUN mkdir -p /app/models /app/logs /app/data
WORKDIR /app
# 健康检查脚本
COPY healthcheck.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/healthcheck.sh
# 默认启动脚本
COPY start.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/start.sh
EXPOSE 8000
ENTRYPOINT ["/usr/local/bin/start.sh"]

15.2.3 镜像安全与权限管理

容器安全是生产环境部署的重要考量。在构建镜像时，应该遵循最小权限原则，避免在容器中以 root 用户运行应用，尽可能使用官方认证的基础镜像，及时修复已知漏洞。

首先，应该创建专用的非 root 用户运行应用。容器的默认用户是 root，虽然 Docker 容器内的 root 与宿主机 root 是隔离的（得益于用户命名空间），但以 root 运行仍然存在安全风险。

其次，应该仔细审查基础镜像的选择。优先使用官方镜像或经过认证的镜像，定期更新基础镜像以获取安全补丁。对于大模型服务使用的 CUDA 镜像，应该从 NVIDIA 官方渠道获取，并验证镜像签名。

第三，可以使用 Trivy 或 Clair 等工具对镜像进行漏洞扫描，在 CI/CD 流程中集成安全检查，及时发现和修复已知漏洞。

# 安全强化的 Dockerfile
FROM eclipse-temurin:17-jre-jammy
# 安全相关的构建参数
ARG APP_USER=llmuser
ARG APP_GROUP=llmgroup
ARG APP_UID=1000
ARG APP_GID=1000
# 创建应用用户和组
RUN groupadd --gid ${APP_GID} ${APP_GROUP} \
&& useradd --uid ${APP_UID} --gid ${APP_GID} --shell /bin/bash --create-home ${APP_USER}
WORKDIR /app
# 复制应用文件
COPY --chown=${APP_USER}:${APP_GROUP} app.jar /app/app.jar
# 切换到非 root 用户
USER ${APP_USER}
# 只读文件系统（需要配合 tmpfs 挂载可写目录）
READONLY_ROOTFS=true
# Capabilities 限制 - 移除所有默认 Capabilities，只保留需要的
CAP_drop=ALL
# 安全相关环境变量
ENV JAVA_OPTS="-Xms512m -Xmx2g -XX:+UseG1GC"
EXPOSE 8080
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar /app/app.jar"]

15.3.1 Docker Compose 核心概念

Docker Compose 是 Docker 官方提供的容器编排工具，用于定义和运行多容器应用。通过一个 YAML 文件，可以声明应用包含哪些服务、每个服务的配置（如镜像、端口、环境变量、卷挂载）、服务之间的依赖关系等，然后通过简单的命令一键启动整个应用。

Docker Compose 的核心概念包括：Services（服务）定义了容器的运行配置；Networks（网络）定义了容器之间的通信方式；Volumes（卷）定义了持久化存储的挂载方式。

对于微服务大模型应用的本地开发，Docker Compose 提供了一个便捷的方式来启动完整的开发环境，包括 API 服务、大模型推理服务、Redis 缓存、数据库等所有依赖组件。

# docker-compose.yml 示例
version: '3.8'
services:
  # API 网关服务
  api-gateway:
    build:
      context: ./api-gateway
      dockerfile: Dockerfile
    ports:
      - "8080:8080"
    environment:
      - SPRING_PROFILES_ACTIVE=local
      - ETCD_HOSTS=etcd:2379
    depends_on:
      - etcd
      - redis
    networks:
      - llm-network
  # LLM 推理服务
  llm-inference:
    build:
      context: ./llm-inference
      dockerfile: Dockerfile
    ports:
      - "8000:8000"
    environment:
      - MODEL_PATH=/models/chatglm3-6b
      - CUDA_VISIBLE_DEVICES=0
    volumes:
      - model-data:/models
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    networks:
      - llm-network
  # Redis 缓存
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
    volumes:
      - redis-data:/data
    command: redis-server --appendonly yes
    networks:
      - llm-network
  # etcd 配置中心
  etcd:
    image: quay.io/coreos/etcd:v3.5.9
    ports:
      - "2379:2379"
    environment:
      - ETCD_NAME=etcd
      - ETCD_ADVERTISE_CLIENT_URLS=http://etcd:2379
      - ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379
    volumes:
      - etcd-data:/etcd
    networks:
      - llm-network
volumes:
  model-data:
  redis-data:
  etcd-data:
networks:
  llm-network:
    driver: bridge

15.3.2 本地开发环境配置

在本地开发环境中使用 Docker Compose，可以快速搭建完整的大模型微服务开发环境，而无需在本地安装各种依赖。这种方式特别适合团队协作场景，确保所有开发人员使用一致的开发环境。

一个完整的本地开发环境通常包含以下服务：应用服务（API 网关、业务微服务）、大模型推理服务（用于本地测试，可能使用量化后的轻量模型）、中间件服务（Redis、MySQL、Kafka 等）、监控服务（Prometheus、Grafana 等）。

# 本地开发环境的 docker-compose.yml
version: '3.8'
services:
  # 开发者友好的配置
  api-service:
    build:
      context: .
      dockerfile: Dockerfile.dev
    ports:
      - "8080:8080"
      - "5005:5005" # 远程调试端口
    environment:
      - SPRING_PROFILES_ACTIVE=dev
      - DEBUG=true
      - JAVA_OPTS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005
    volumes:
      - ./src:/app/src      # 源代码热加载
      - maven-cache:/root/.m2
    depends_on:
      - redis
      - mysql
  # LLM 服务（轻量模型用于开发）
  llm-service-dev:
    build:
      context: ./llm-service
      dockerfile: Dockerfile
    ports:
      - "8000:8000"
    environment:
      - MODEL_NAME=chatglm2-6b-int4 # 开发环境使用量化模型
      - MAX_CONCURRENT=2
    volumes:
      - ./models:/models
    deploy:
      resources:
        limits:
          memory: 8G
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
    volumes:
      - redis-data:/data
  mysql:
    image: mysql:8.0
    ports:
      - "3306:3306"
    environment:
      - MYSQL_ROOT_PASSWORD=dev123
      - MYSQL_DATABASE=llm_app
    volumes:
      - mysql-data:/var/lib/mysql
  # 开发工具
  prometheus:
    image: prom/prometheus:v2.47.0
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
  grafana:
    image: grafana/grafana:10.1.0
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - grafana-data:/var/lib/grafana
    depends_on:
      - prometheus
volumes:
  maven-cache:
  redis-data:
  mysql-data:
  prometheus-data:
  grafana-data:

15.3.3 环境变量与配置管理

在大模型服务中，配置管理是一个重要课题。不同环境（开发、测试、生产）需要不同的配置，如模型路径、API 密钥、并发限制等。Docker Compose 提供了多种配置方式，可以灵活满足不同场景的需求。

最基本的方式是通过 `environment` 关键字直接定义环境变量。对于敏感配置（如 API 密钥），可以使用 Docker Secrets 或通过 `.env` 文件管理。对于复杂的配置，可以通过挂载配置文件的方式注入。

# 配置管理示例
services:
  llm-service:
    build: ./llm-service
    environment:
      # 通用配置
      - LOG_LEVEL=INFO
      - MAX_BATCH_SIZE=16
      - MAX_TIMEOUT_MS=60000
      # 敏感配置 - 通过 .env 文件
      - OPENAI_API_KEY=${OPENAI_API_KEY}
      - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
    env_file:
      - .env.prod # 环境专用配置
    volumes:
      # 配置文件挂载
      - ./config/model_config.yaml:/app/config/model_config.yaml:ro
      # 模型文件挂载
      - model-storage:/models
    secrets:
      - api_credentials
# Docker Secrets 定义
secrets:
  api_credentials:
    file: ./secrets/api_credentials.json

15.4.1 企业级镜像构建流程

在企业级应用中，镜像构建是 CI/CD 流程的核心环节。一个完善的镜像构建流程应该具备以下特性：构建过程可重复、构建结果可追溯、构建速度快（利用缓存）、构建产物安全。

推荐的企业级镜像构建流程如下：首先在代码提交触发构建后，CI 系统（如 Jenkins、GitLab CI）执行代码编译和单元测试；测试通过后，使用多阶段构建创建应用镜像；在镜像创建过程中，执行代码扫描、单元测试覆盖率收集等质量检查；最后，将经过验证的镜像推送到私有镜像仓库，并打上版本标签。

对于大模型服务，镜像构建还需要考虑模型文件的处理。由于模型文件通常较大，建议将镜像分为基础镜像和应用镜像两层：基础镜像包含运行时环境，应用镜像在此基础上加入具体的模型配置。

# CI 友好的多阶段构建
# 阶段一：代码质量和编译
FROM maven:3.9-eclipse-temurin-17 AS code-quality
WORKDIR /app
# 复制依赖和源代码
COPY pom.xml pom.xml
COPY src src
# 运行代码质量检查
RUN mvn verify -DskipTests=false -Dcheckstyle.skip=false
# 编译打包
RUN mvn package -DskipTests
# 阶段二：单元测试
FROM code-quality AS unit-test
# 运行单元测试
RUN mvn test
# 阶段三：构建镜像
FROM eclipse-temurin:17-jre-jammy AS builder
WORKDIR /app
# 从测试阶段复制产物
COPY --from=unit-test /app/target/*.jar app.jar
# 创建非 root 用户
RUN groupadd -r app && useradd -r -g app app
RUN chown -R app:app /app
USER app
EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
CMD curl -f http://localhost:8080/actuator/health || exit 1
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

15.4.2 GitHub Actions 自动化构建

GitHub Actions 是 GitHub 提供的 CI/CD 功能，可以与代码仓库无缝集成。下面是一个典型的 Docker 镜像构建 workflow 配置示例。

# .github/workflows/docker-build.yml
name: Docker Build and Push
on:
  push:
    branches: [ main, release/* ]
    tags: [ 'v*' ]
  pull_request:
    branches: [ main ]
env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
    - name: Checkout code
      uses: actions/checkout@v4
    - name: Set up Docker Buildx
      uses: docker/setup-buildx-action@v3
    - name: Log in to Container Registry
      if: github.event_name != 'pull_request'
      uses: docker/login-action@v3
      with:
        registry: ${{ env.REGISTRY }}
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}
    - name: Extract metadata
      id: meta
      uses: docker/metadata-action@v5
      with:
        images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
        tags: |
          type=ref,event=branch
          type=ref,event=pr
          type=semver,pattern={{version}}
          type=sha,prefix=
    - name: Build and push
      uses: docker/build-push-action@v5
      with:
        context: .
        push: ${{ github.event_name != 'pull_request' }}
        tags: ${{ steps.meta.outputs.tags }}
        labels: ${{ steps.meta.outputs.labels }}
        cache-from: type=gha
        cache-to: type=gha,mode=max
        build-args: |
          GIT_COMMIT=${{ github.sha }}
          BUILD_TIME=${{ github.event.head_commit.timestamp }}

15.4.3 镜像安全扫描与签名

容器安全是生产环境部署的重中之重。在镜像构建和部署流程中，应该集成安全扫描和签名验证机制，确保只有经过验证的安全镜像才能进入生产环境。

镜像安全扫描工具可以检测镜像中已知的安全漏洞，常见的工具包括 Trivy、Clair、Anchore 等。这些工具可以集成到 CI/CD 流程中，在镜像构建完成后自动执行扫描，扫描结果可以作为镜像准入的判断依据。

镜像签名则是确保镜像在传输和存储过程中未被篡改的重要手段。通过 Docker Content Trust 和 Notary 工具，可以对镜像进行数字签名，在部署时验证镜像的完整性和发布者身份。

# 集成 Trivy 安全扫描的 CI 流程
jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v4
    - name: Build Docker image
      run: docker build -t ${{ env.IMAGE_NAME }}:${{ github.sha }} .
    - name: Run Trivy vulnerability scanner
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: ${{ env.IMAGE_NAME }}:${{ github.sha }}
        format: 'sarif'
        output: 'trivy-results.sarif'
        severity: 'CRITICAL,HIGH'
    - name: Upload Trivy scan results
      uses: github/codeql-action/upload-sarif@v2
      with:
        sarif_file: 'trivy-results.sarif'
    - name: Fail on critical vulnerabilities
      run: |
        if grep -q "CRITICAL" trivy-results.sarif; then
          echo "Critical vulnerabilities found, failing build"
          exit 1
        fi

15.5.1 生产环境镜像优化

生产环境的 Docker 镜像需要针对性能和安全性进行专门优化。与开发环境不同，生产镜像通常需要更小的体积、更快的启动速度、更严格的安全配置。

首先，生产镜像应该移除所有开发工具和调试信息。开发依赖如 Maven、Gradle、测试框架等不应该出现在生产镜像中。使用 distroless 或 alpine 等精简基础镜像可以显著减小镜像体积。

其次，对于 Java 应用，可以通过 jlink 创建自定义 JRE，只包含应用实际需要的 Java 模块，进一步减小运行时体积。GraalVM Native Image 可以将 Java 应用编译为原生可执行文件，实现秒级启动和极小内存占用。

# 生产级别的 Java 应用 Dockerfile
# 使用 jlink 创建自定义 JRE
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /app
COPY pom.xml pom.xml
COPY src src
RUN mvn package -DskipTests
# 创建自定义 JRE（仅包含需要的模块）
FROM eclipse-temurin:17-jdk AS jre-builder
RUN $JAVA_HOME/bin/jlink \
    --add-modules java.base,java.logging,java.sql,java.naming,java.desktop,java.security.sasl,java.instrument \
    --compress=2 \
    --no-header-files \
    --output /jre
# 最终生产镜像
FROM ubuntu:22.04
COPY --from=jre-builder /jre /opt/java/jre
ENV JAVA_HOME=/opt/java/jre
ENV PATH=$JAVA_HOME/bin:$PATH
WORKDIR /app
COPY --from=builder /app/target/*.jar app.jar
# 安全配置
RUN groupadd -r appuser && useradd -r -g appuser appuser
RUN chown -R appuser:appuser /app
USER appuser
# 使用 tini 作为 init 系统
RUN apt-get update && apt-get install -y --no-install-recommends tini && rm -rf /var/lib/apt/lists/*
ENTRYPOINT ["/usr/bin/tini", "--", "java", "-jar", "/app/app.jar"]
EXPOSE 8080

15.5.2 日志与监控集成

在容器化环境中，日志和监控的收集方式与传统部署有所不同。Docker 容器将日志输出到标准输出和标准错误流，这些日志由 Docker Daemon 收集。推荐使用 JSON File 日志驱动，便于后续的日志聚合系统采集。

对于 Kubernetes 环境，通常使用 Fluent Bit 或 Fluentd 作为日志采集代理，它们以 DaemonSet 形式部署在每个节点上，收集所有容器写入 stdout 的日志。在应用层面，应该遵循十二要素应用原则，将日志输出到标准输出，由基础设施负责日志收集和处理。

# Docker 日志配置
services:
  api-service:
    image: api-service:v1.0
    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "3"
        labels: "service,environment"
    labels:
      service: api-gateway
      environment: production
# Kubernetes Pod 日志配置（通过 Fluent Bit）
apiVersion: v1
kind: ConfigMap
metadata:
  name: fluent-bit-config
data:
  fluent-bit.conf: |
    [SERVICE]
        Flush         5
        Log_Level     info
        Daemon        off
    [INPUT]
        Name              tail
        Path              /var/log/containers/*.log
        Parser            docker
        Tag               kube.*
        Refresh_Interval 5
    [OUTPUT]
        Name        loki
        Match       *
        Host        loki-service
        Port        3100
        Labels      job=fluent-bit

15.5.3 资源限制与健康检查

容器资源限制是保障服务稳定运行的重要手段。通过合理的资源限制，可以防止单个容器耗尽宿主机资源，影响其他容器的正常运行。同时，健康检查配置对于容器的自动恢复和滚动更新至关重要。

# 带资源限制和健康检查的服务配置
apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-api-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: llm-api
  template:
    metadata:
      labels:
        app: llm-api
    spec:
      containers:
      - name: llm-api
        image: llm-api:v1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "512Mi"
            cpu: "500m"
          limits:
            memory: "2Gi"
            cpu: "2000m"
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8080
          initialDelaySeconds: 60
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 5
          timeoutSeconds: 3
          failureThreshold: 2
        startupProbe:
          httpGet:
            path: /actuator/health/startup
            port: 8080
          failureThreshold: 30
          periodSeconds: 10