【阶段 9】运维部署：Docker、Kubernetes 与监控

# 用 Spring Initializr 生成项目，或手动创建
curl https://start.spring.io/starter.zip 
  -d dependencies=web,actuator,lombok 
  -d type=maven-project 
  -d language=java 
  -d javaVersion=17 
  -d bootVersion=3.2.5 
  -d groupId=com.example 
  -d artifactId=order-service 
  -d name=order-service 
  -o order-service.zip
unzip order-service.zip && cd order-service

<dependency>
    <!-- Micrometer 的 Prometheus 实现：让 /actuator/prometheus 输出 Prometheus 格式指标 -->
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

# application.yml
management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus   # 只暴露这 4 个，避免把 env/beans 等敏感端点暴露出去
  endpoint:
    health:
      show-details: always                        # 健康详情始终返回（生产建议 when_authorized）

# 1. 健康检查：返回 UP / DOWN
curl http://localhost:8080/actuator/health
# {"status":"UP"}

# 2. 应用信息：来自 application.yml 里的 info.*
curl http://localhost:8080/actuator/info

# 3. 指标列表：返回所有可用指标的名字
curl http://localhost:8080/actuator/metrics | head -30

# 4. 单个指标：返回该指标的当前值
curl http://localhost:8080/actuator/metrics/jvm.memory.used

# 5. Prometheus 格式：供 Prometheus 抓取
curl http://localhost:8080/actuator/prometheus

# 看 /api/orders 接口的请求耗时（Timer 类型指标返回统计值）
curl 'http://localhost:8080/actuator/metrics/http.server.requests?tag=uri:/api/orders'
# {"name":"http.server.requests",...,"measurements":[
#   {"statistic":"COUNT","value":1234},
#   {"statistic":"TOTAL_TIME","value":98.7},
#   {"statistic":"MAX","value":0.45}]}

@Slf4j
@RestController
@RequestMapping("/api/orders")
@RequiredArgsConstructor
public class OrderController {

    // 构造器注入 MeterRegistry：Micrometer 的核心入口，所有指标都通过它注册
    private final MeterRegistry meterRegistry;

    @PostMapping
    public String createOrder() {
        // 每调用一次，order.create.total 计数 +1，标签 method=createOrder
        meterRegistry.counter("order.create.total", "method", "createOrder").increment();
        // 业务逻辑……
        return "ok";
    }
}

// service/OrderService.java
@Slf4j
@Service
@RequiredArgsConstructor
public class OrderService {

    private final MeterRegistry meterRegistry;
    // 用 AtomicInteger 保存「当前待处理订单数」，Gauge 需要引用一个可变的值源
    private final AtomicInteger pendingOrders = new AtomicInteger(0);

    /**
     * 创建订单：演示三类指标的组合使用。
     * 为什么把打点放在 Service 而不是 Controller：指标属于业务语义，
     * 放在 Service 层能被所有调用方（Controller、定时任务、MQ 消费者）复用。
     */
    public OrderVO createOrder(CreateOrderDTO dto) {
        // Timer：记录下单总耗时，自动统计 count/sum/max/p99
        return Timer.builder("order.create.duration")
                .description("下单接口耗时")          // 指标描述，进 /actuator/metrics 详情
                .tag("channel", dto.getChannel())     // 按渠道分桶，方便看哪个渠道慢
                .register(meterRegistry)
                .record(() -> {
                    // 下单开始，待处理 +1
                    pendingOrders.incrementAndGet();
                    try {
                        // 模拟业务耗时（真实场景这里是查库存、写库、发 MQ）
                        Thread.sleep(50);
                        // Counter：下单成功 +1
                        meterRegistry.counter("order.create.success", "channel", dto.getChannel()).increment();
                        return new OrderVO("ORDER-" + System.currentTimeMillis(), "SUCCESS");
                    } catch (InterruptedException e) {
                        Thread.currentThread().interrupt();   // 恢复中断标记，不吞中断
                        // Counter：下单失败 +1
                        meterRegistry.counter("order.create.failure", "channel", dto.getChannel()).increment();
                        throw new BizException(ErrorCode.SYSTEM_ERROR);
                    } finally {
                        // 无论成败，待处理 -1
                        pendingOrders.decrementAndGet();
                    }
                });
    }

    /** 当前待处理订单数：Gauge 实时反映 pendingOrders 的值 */
    @PostConstruct
    public void registerGauge() {
        // Gauge 不主动存储值，而是每次采集时回调这个 AtomicInteger 读当前值
        Gauge.builder("order.pending.count", pendingOrders, AtomicInteger::get)
                .description("当前待处理订单数")
                .register(meterRegistry);
    }
}

// config/MetricsConfig.java
@Configuration
@RequiredArgsConstructor
public class MetricsConfig {

    private final MeterRegistry meterRegistry;

    /**
     * 开启 @Timed 注解支持。
     * 为什么需要这个 Bean：@Timed 依赖 AOP 拦截，而 Actuator 默认不注册 TimedAspect，
     * 没有它 @Timed 注解会静默失效——这是新手最容易踩的坑。
     */
    @Bean
    public TimedAspect timedAspect() {
        return new TimedAspect(meterRegistry);
    }
}

// 方法上加 @Timed，自动计时并生成 http 之外的业务指标
@Timed(value = "order.query.duration", description = "订单查询耗时", percentiles = {0.5, 0.95, 0.99})
public OrderVO queryOrder(String orderId) {
    // 业务逻辑……
    return new OrderVO(orderId, "SUCCESS");
}

// health/DependencyHealthIndicator.java
@Component
@RequiredArgsConstructor
@Slf4j
public class DependencyHealthIndicator implements HealthIndicator {

    // 注入 DataSource，探测数据库是否真的可用
    private final DataSource dataSource;

    @Override
    public Health health() {
        try (Connection conn = dataSource.getConnection()) {
            // 真的执行一条 SQL，而不是只看连接对象非空
            boolean ok = conn.isValid(2);
            if (ok) {
                return Health.up().withDetail("database", "UP").build();
            }
            return Health.down().withDetail("database", "connection invalid").build();
        } catch (Exception e) {
            log.error("数据库健康检查失败", e);
            // 关键点：返回 down 而不是抛异常；抛异常会让整个 health 端点 500
            return Health.down(e).withDetail("database", "DOWN").build();
        }
    }
}

# application.yml
management:
  endpoint:
    health:
      probes:
        enabled: true     # 自动生成 /actuator/health/liveness 和 /actuator/health/readiness
      show-details: always

curl http://localhost:8080/actuator/health/liveness
# {"status":"UP"}
curl http://localhost:8080/actuator/health/readiness
# {"status":"UP"}

management:
  endpoint:
    health:
      group:
        readiness:
          include: readinessState,db          # 就绪 = 进程就绪 + 数据库可用
        liveness:
          include: livenessState              # 存活 = 只要进程活着

# prometheus/prometheus.yml —— Prometheus 抓取配置
global:
  scrape_interval: 15s        # 每 15 秒抓一次

scrape_configs:
  - job_name: 'order-service'
    metrics_path: '/actuator/prometheus'     # 抓 Prometheus 格式的指标
    static_configs:
      - targets: ['order-service:8080']      # 应用地址

# prometheus/rules.yml —— 告警规则
groups:
  - name: order-service-alerts
    rules:
      - alert: HighMemoryUsage
        expr: sum(jvm_memory_used_bytes{area="heap"}) / sum(jvm_memory_max_bytes{area="heap"}) > 0.8
        for: 5m                       # 持续 5 分钟才告警，避免毛刺
        labels: { severity: warning }
        annotations: { summary: "堆内存使用率超过 80%" }
      - alert: SlowEndpoint
        expr: histogram_quantile(0.99, http_server_requests_seconds_bucket) > 1
        for: 5m
        labels: { severity: warning }
        annotations: { summary: "接口 p99 耗时超过 1s" }

// 反例：用 orderId 做 tag —— 每个订单一个序列，Prometheus 内存爆炸
meterRegistry.counter("order.create", "orderId", orderId).increment();

// 正例：只用低基数的维度（渠道、结果、状态），订单号放日志不进指标
meterRegistry.counter("order.create.success", "channel", channel).increment();

# 查看某个包的当前日志级别
curl http://localhost:8080/actuator/loggers/com.example.order

# 临时把某个包的日志级别调到 DEBUG
curl -X POST http://localhost:8080/actuator/loggers/com.example.order 
  -H "Content-Type: application/json" 
  -d '{"configuredLevel":"DEBUG"}'

# 排查完调回 INFO（或调成 null 恢复默认）
curl -X POST http://localhost:8080/actuator/loggers/com.example.order 
  -H "Content-Type: application/json" 
  -d '{"configuredLevel":"INFO"}'

# 最小可用 Dockerfile（能跑，但镜像巨大，仅用于理解指令）
FROM maven:3.9-eclipse-temurin-17            # 基础镜像：带 Maven + JDK 17，约 600MB
WORKDIR /app                                 # 后续指令的工作目录
COPY . .                                    # 把整个项目（含 src、pom.xml）拷进镜像
RUN mvn -B package -DskipTests              # 在镜像里执行 Maven 打包
EXPOSE 8080                                 # 声明容器监听 8080（仅文档作用，不真正发布端口）
ENTRYPOINT ["java", "-jar", "target/order-service-0.0.1-SNAPSHOT.jar"]

docker build -t order-service:naive .
docker images order-service   # 看镜像大小：通常 700MB+

# ============ 阶段 1：构建（builder）============
# 用带 Maven + JDK 的大镜像做编译，这个镜像只存在于构建过程，不进最终镜像
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /app
# 先只拷 pom.xml，单独执行依赖下载，利用 Docker 分层缓存（详见 2.4）
COPY pom.xml .
RUN mvn -B dependency:go-offline
# 再拷源码编译。改代码时，上面的依赖层不变，这步才重新执行
COPY src ./src
RUN mvn -B package -DskipTests

# ============ 阶段 2：运行（runtime）============
# 用精简的 JRE 镜像（只有运行时，无编译工具），约 250MB，是 JDK 镜像的一半不到
FROM eclipse-temurin:17-jre
WORKDIR /app
# 只从 builder 阶段拷贝最终的 jar，Maven、源码、依赖缓存统统不带走
COPY --from=builder /app/target/*.jar app.jar
EXPOSE 8080
# 用 exec 形式 ENTRYPOINT，让 java 成为 PID 1，能正确接收 SIGTERM 优雅停机
ENTRYPOINT ["java", "-jar", "app.jar"]

docker build -t order-service:1.0 .
docker images order-service   # 对比：naive 700MB+，多阶段后约 300MB 左右

FROM eclipse-temurin:17-jre
# 创建普通用户 appuser（-r 表示系统用户，无登录 shell）
RUN groupadd -r app && useradd -r -g app appuser
WORKDIR /app
COPY --from=builder /app/target/*.jar app.jar
# 关键：先拷贝文件再 chown，最后才 USER 切换；顺序反了会导致 appuser 无写权限
RUN chown -R appuser:app /app
USER appuser
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

docker run -d --name check order-service:1.0
docker exec check whoami   # 输出应为 appuser 而不是 root

FROM eclipse-temurin:17-jre-alpine
# alpine 没有 groupadd/useradd，用 addgroup/adduser
RUN addgroup -S app && adduser -S app -G app
WORKDIR /app
COPY --from=builder /app/target/*.jar app.jar
RUN chown -R app:app /app
USER app
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

# 阶段 1：构建（同上，略）
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn -B dependency:go-offline
COPY src ./src
RUN mvn -B package -DskipTests

# 阶段 2：用 jlink 裁剪定制 JRE
# jdeps 扫描 jar 依赖哪些 JDK 模块，jlink 只保留这些模块
FROM eclipse-temurin:17-jre AS jre-builder
RUN jlink --add-modules java.base,java.logging,java.sql,java.naming,java.desktop,java.management,java.security.jgss,java.instrument 
          --strip-debug --no-header-files --no-man-pages 
          --output /custom-jre

# 阶段 3：运行（alpine + 定制 JRE，最终镜像可压到 100MB 以内）
FROM alpine:3.19
RUN addgroup -S app && adduser -S app -G app
WORKDIR /app
COPY --from=builder /app/target/*.jar app.jar
COPY --from=jre-builder /custom-jre /opt/jre
RUN chown -R app:app /app
USER app
EXPOSE 8080
ENTRYPOINT ["/opt/jre/bin/java", "-jar", "app.jar"]

# 构建并打 tag
docker build -t order-service:1.0 .

# 本地运行：-d 后台，-p 端口映射，-e 传环境变量，--name 命名
docker run -d 
  -p 8080:8080 
  --name order-service 
  -e SPRING_PROFILES_ACTIVE=prod 
  --memory=1g --cpus=1               # 容器资源限制（对应 K8s 的 limits）
  order-service:1.0

# 看日志（容器 stdout）
docker logs -f order-service

# 进入容器排查
docker exec -it order-service sh

# 停止/删除
docker stop order-service && docker rm order-service

# 1. 登录仓库
docker login ghcr.io -u <用户名>

# 2. 打上「仓库前缀」的 tag（仓库名是 tag 的一部分）
docker tag order-service:1.0 ghcr.io/yourname/order-service:1.0

# 3. 推送
docker push ghcr.io/yourname/order-service:1.0

# 4. 别的机器拉取
docker pull ghcr.io/yourname/order-service:1.0

# Docker 自带的 Scout 扫描
docker scout quickview order-service:1.0

# 或用开源 Trivy
trivy image order-service:1.0

# docker-compose.yml
services:
  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: password
      MYSQL_DATABASE: order_db
    ports: ["3306:3306"]
    volumes:
      - mysql-data:/var/lib/mysql    # 数据持久化，容器删了数据还在
    healthcheck:                     # 等 MySQL 就绪再启动应用
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 5s
      timeout: 3s
      retries: 10

  order-service:
    build: .                         # 直接用 Dockerfile 构建
    ports: ["8080:8080"]
    environment:
      SPRING_PROFILES_ACTIVE: prod
      DB_URL: jdbc:mysql://mysql:3306/order_db
      DB_USERNAME: root
      DB_PASSWORD: password
    depends_on:
      mysql:
        condition: service_healthy   # 依赖 MySQL 健康检查通过
    mem_limit: 1g                    # 本地也设资源限制

volumes:
  mysql-data:

docker compose up -d       # 一键启动所有服务
docker compose logs -f order-service
docker compose down        # 停止并删除（加 -v 连数据卷一起删）

# 镜像
docker images                                   # 列出本地镜像
docker rmi <镜像id>                              # 删除镜像
docker image prune                              # 清理悬空镜像

# 容器
docker ps -a                                    # 列出所有容器（含已停止）
docker start/stop/restart <容器名>
docker rm -f <容器名>                            # 强制删除

# 日志与排查
docker logs -f --tail 200 <容器名>               # 跟读最近 200 行
docker exec -it <容器名> sh                      # 进入容器
docker inspect <容器名>                          # 看容器详细配置（含 IP、资源限制）

# 资源占用
docker stats                                    # 实时看每个容器 CPU/内存

# 进入一个正在运行的容器排查，但不安装任何工具（用宿主机命令）
docker cp <容器名>:/app/app.jar ./               # 从容器拷文件出来

# 构建前自查
[ ] 用了多阶段构建（构建 JDK、运行 JRE 分离）
[ ] 先 COPY pom.xml 再 COPY src（利用依赖缓存）
[ ] 有 .dockerignore，排除了 target/.git/IDE 文件
[ ] 运行阶段用 JRE/alpine 而非 JDK
[ ] 有 USER 切换到非 root 用户
[ ] ENTRYPOINT 用 exec 形式
[ ] 镜像 tag 用版本号/SHA 而非 latest
[ ] 构建后跑过 docker scout/trivy 扫描

# 方案 A：普通单阶段构建
docker build -f Dockerfile.naive -t order-service:naive .
docker images order-service:naive
# REPOSITORY          TAG     IMAGE ID       SIZE
# order-service       naive   xxxxxxxxxxxx   742MB

# 方案 B：多阶段构建（JRE）
docker build -f Dockerfile -t order-service:jre .
docker images order-service:jre
# REPOSITORY          TAG     IMAGE ID       SIZE
# order-service       jre     xxxxxxxxxxxx   312MB

# 方案 C：多阶段 + alpine JRE
docker build -f Dockerfile.alpine -t order-service:alpine .
docker images order-service:alpine
# REPOSITORY          TAG     IMAGE ID       SIZE
# order-service       alpine  xxxxxxxxxxxx   208MB

# 阶段 0：测试（test）—— 跑单元测试，失败则整个构建失败
FROM maven:3.9-eclipse-temurin-17 AS test
WORKDIR /app
COPY pom.xml .
RUN mvn -B dependency:go-offline
COPY src ./src
RUN mvn -B test                          # 测试失败，docker build 直接报错中断

# 阶段 1：构建（builder）
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn -B dependency:go-offline
COPY src ./src
RUN mvn -B package -DskipTests           # 测试已在 test 阶段跑过

# 阶段 2：运行（runtime）
FROM eclipse-temurin:17-jre-alpine
RUN addgroup -S app && adduser -S app -G app
WORKDIR /app
COPY --from=builder /app/target/*.jar app.jar
RUN chown -R app:app /app
USER app
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

# pod.yaml —— 单个 Pod（一般不用，仅供理解，生产用 Deployment 管理）
apiVersion: v1
kind: Pod
metadata:
  name: order-service-pod
  labels:
    app: order-service            # label 是 Service 选择 Pod 的依据
spec:
  containers:
    - name: order-service
      image: order-service:1.0
      ports:
        - containerPort: 8080

kubectl apply -f pod.yaml
kubectl get pods            # 看 Pod 状态
kubectl logs order-service-pod   # 看日志
kubectl delete pod order-service-pod   # Pod 删了就没了，不会自动重建

# k8s/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  labels:
    app: order-service
spec:
  replicas: 3                       # 3 副本高可用
  selector:
    matchLabels:
      app: order-service            # 必须与 template.metadata.labels 一致，否则报错
  strategy:                         # 滚动更新策略
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1                   # 更新时最多多出 1 个新 Pod
      maxUnavailable: 0             # 更新时不允许可用副本数减少（保证零停机）
  template:                         # Pod 模板，下面才是真正的 Pod 定义
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service
          image: order-service:1.0
          imagePullPolicy: IfNotPresent   # 本地镜像不重复拉取；生产配 Always 或带 digest
          ports:
            - containerPort: 8080
          envFrom:                  # 从 ConfigMap 批量注入环境变量
            - configMapRef:
                name: order-service-config
            - secretRef:
                name: order-service-secret
          # ---- 健康检查：本章 3.5 重点 ----
          startupProbe:             # 启动探针：给慢启动留足时间
            httpGet:
              path: /actuator/health/liveness
              port: 8080
            failureThreshold: 30    # 最多等 30 * 10s = 300s 启动
            periodSeconds: 10
          readinessProbe:           # 就绪探针：就绪才接流量
            httpGet:
              path: /actuator/health/readiness
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5
            failureThreshold: 3     # 连续 3 次失败摘除流量
          livenessProbe:            # 存活探针：挂了就重启
            httpGet:
              path: /actuator/health/liveness
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 10
            failureThreshold: 3     # 连续 3 次失败才重启，避免误杀
          # ---- 资源限制：必须设置（本章 3.6 重点）----
          resources:
            requests:               # 调度保证量：向集群申请的最小资源
              memory: "512Mi"
              cpu: "500m"           # 500m = 0.5 核
            limits:                 # 硬上限：超出会被限流/OOM 杀死
              memory: "1Gi"
              cpu: "1"

probes:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  initialDelaySeconds: 30   # 容器启动后等多久才开始第一次探测
  periodSeconds: 10         # 每隔多久探测一次
  timeoutSeconds: 3         # 单次探测超时时间
  successThreshold: 1       # 连续成功几次算就绪（readiness 默认 1）
  failureThreshold: 3       # 连续失败几次算失败（liveness 失败则重启）

resources:
  requests:            # 声明「我需要这么多」——调度器按它找节点，也是 HPA 计算的基准
    memory: "512Mi"
    cpu: "500m"
  limits:              # 声明「我最多用这么多」——超了就被限流（CPU）或杀死（内存）
    memory: "1Gi"
    cpu: "1"

# k8s/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  selector:
    app: order-service          # 通过 label 选择后端 Pod
  ports:
    - port: 8080                # Service 对外端口
      targetPort: 8080          # 后端 Pod 的端口
      protocol: TCP
  type: ClusterIP               # 集群内部访问；对外暴露用 LoadBalancer 或 NodePort

# k8s/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: order-service-config
data:
  SPRING_PROFILES_ACTIVE: "prod"
  SERVER_PORT: "8080"
  DB_URL: "jdbc:mysql://mysql:3306/order_db"
---
# k8s/secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: order-service-secret
type: Opaque
# 注意：secret 的值必须 base64 编码；这里为演示写的原文，实际先 echo -n 'xxx' | base64
data:
  DB_USERNAME: cm9vdA==          # base64("root")
  DB_PASSWORD: cGFzc3dvcmQ=      # base64("password")

# 生成 base64 的正确姿势
echo -n 'root' | base64        # cm9vdA==
kubectl apply -f configmap.yaml -f secret.yaml

# k8s/ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: order-service
spec:
  rules:
    - host: order.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: order-service
                port:
                  number: 8080

# k8s/hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 3
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # 平均 CPU 使用率超 70% 就扩容

# 依次应用所有资源
kubectl apply -f k8s/configmap.yaml -f k8s/secret.yaml
kubectl apply -f k8s/deployment.yaml -f k8s/service.yaml
kubectl apply -f k8s/ingress.yaml -f k8s/hpa.yaml

# 查看状态
kubectl get pods -w                    # 持续观察 Pod 状态变化
kubectl get deployment order-service
kubectl describe pod <pod-name>        # 排障首选：看事件、探针、资源

# 滚动更新：改镜像 tag 后 apply，或直接 set image
kubectl set image deployment/order-service order-service=order-service:2.0
kubectl rollout status deployment/order-service   # 等待更新完成

# 回滚：发版出问题时的救命稻草
kubectl rollout undo deployment/order-service     # 回滚到上一个版本
kubectl rollout history deployment/order-service  # 看历史版本

# 查看探针与资源是否生效
kubectl get pod <pod-name> -o yaml | grep -A5 -E 'probe|resources'

# 查看集群组件状态
kubectl get nodes            # 看节点
kubectl get namespaces       # 看命名空间
kubectl cluster-info         # 看控制面地址

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1              # 更新时可多创建的新 Pod 上限
    maxUnavailable: 0        # 更新时不可用 Pod 上限（0 = 始终满员服务）

kubectl rollout undo deployment/order-service            # 回滚上一版
kubectl rollout undo deployment/order-service --to-revision=2   # 回滚到指定版本
kubectl rollout history deployment/order-service         # 看所有历史版本

# namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: prod

kubectl create namespace prod
kubectl apply -f k8s/deployment.yaml -n prod      # 部署到 prod 命名空间
kubectl get pods -n prod

# 把整个 application.yml 塞进 ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: order-service-config-file
data:
  application.yml: |
    server:
      port: 8080
    management:
      endpoints:
        web:
          exposure:
            include: health,info,metrics,prometheus
---
# Deployment 里挂载成文件，覆盖 jar 内的 application.yml
spec:
  containers:
    - name: order-service
      volumeMounts:
        - name: config
          mountPath: /app/config
  volumes:
    - name: config
      configMap:
        name: order-service-config-file

# k8s/pdb.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: order-service-pdb
spec:
  minAvailable: 2              # 任何时刻至少 2 个副本可用
  selector:
    matchLabels:
      app: order-service

# 1. 看 Pod 状态（CrashLoopBackOff / Pending / OOMKilled 都是关键信号）
kubectl get pods -o wide

# 2. 看事件：describe 会告诉你探针失败、资源不足、镜像拉取失败等直接原因
kubectl describe pod <pod-name>
# 关键字段：Events 段、Last State（上次退出原因）、探针状态

# 3. 看日志：容器 stdout
kubectl logs <pod-name>            # 当前容器
kubectl logs <pod-name> --previous # 上次崩溃的容器（CrashLoop 时必看）

# 4. 看资源使用（确认是不是 OOMKilled）
kubectl top pod <pod-name>

# 5. 进入容器内排查
kubectl exec -it <pod-name> -- sh

# .github/workflows/ci.yml
name: CI                          # workflow 名字
on:                               # 触发条件：push 到任何分支
  push:
jobs:
  build:                          # 一个 job
    runs-on: ubuntu-latest        # 跑在哪个操作系统
    steps:
      - uses: actions/checkout@v4         # 检出代码
      - uses: actions/setup-java@v4       # 装 JDK
        with:
          distribution: 'temurin'
          java-version: '17'
      - run: mvn -B test          # 跑测试
      - run: mvn -B package -DskipTests   # 打包（测试已跑过，这里跳过）

# .github/workflows/ci.yml —— 生产级 CI/CD
name: CI/CD
on:
  push:
    branches: [ main ]           # 只有 main 分支触发，避免 feature 分支频繁构建
  pull_request:
    branches: [ main ]           # PR 也触发，但只跑测试不部署（见下方条件）

env:
  IMAGE_NAME: ghcr.io/${{ github.repository }}   # 用 GitHub 容器仓库，免额外配置
  K8S_NAMESPACE: prod

jobs:
  build-test:                    # Job 1：构建 + 测试
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'
          cache: 'maven'         # 自动缓存 ~/.m2，加速依赖下载

      - name: Run unit tests
        run: mvn -B test

      - name: Package application
        run: mvn -B package -DskipTests

      # 上传构建产物，供下一个 job 使用（job 之间文件不共享）
      - name: Upload artifact
        uses: actions/upload-artifact@v4
        with:
          name: order-service-jar
          path: target/*.jar

  build-push:                    # Job 2：构建镜像 + 推送
    needs: build-test            # 依赖 Job 1 成功才执行
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write            # 允许推送容器镜像
    steps:
      - uses: actions/checkout@v4

      # 登录 GitHub 容器仓库
      - name: Log in to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      # 构建并推送（利用 Docker 分层缓存加速）
      - name: Build and push Docker image
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          # 用 commit SHA 打 tag，保证镜像不可变、可追溯
          tags: |
            ${{ env.IMAGE_NAME }}:${{ github.sha }}
            ${{ env.IMAGE_NAME }}:latest
          cache-from: type=gha      # 从 GitHub Actions 缓存读取构建层
          cache-to: type=gha,mode=max

  deploy:                        # Job 3：部署到 K8s
    needs: build-push
    if: github.ref == 'refs/heads/main'   # 只有 main 分支才部署，PR 只跑前两个 job
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure kubectl
        uses: azure/k8s-set-context@v4
        with:
          method: kubeconfig
          kubeconfig: ${{ secrets.KUBECONFIG }}   # 集群凭据存 Secret，不进代码

      # 用 sed 把镜像 tag 替换成当前 commit SHA，实现「每次提交一个可追溯版本」
      - name: Update image tag
        run: sed -i "s|IMAGE_TAG_PLACEHOLDER|${{ github.sha }}|g" k8s/deployment.yaml

      - name: Deploy to Kubernetes
        run: |
          kubectl apply -f k8s/configmap.yaml -f k8s/secret.yaml
          kubectl apply -f k8s/deployment.yaml -f k8s/service.yaml -f k8s/ingress.yaml

      - name: Wait for rollout
        run: kubectl rollout status deployment/order-service --namespace ${{ env.K8S_NAMESPACE }} --timeout=300s

      - name: Rollback on failure
        if: failure()               # 部署失败自动回滚
        run: kubectl rollout undo deployment/order-service --namespace ${{ env.K8S_NAMESPACE }}

# k8s/deployment.yaml 里的 image 字段
containers:
  - name: order-service
    image: IMAGE_TAG_PLACEHOLDER     # 由 CI 替换成 ghcr.io/xxx/order-service:<sha>

deploy-prod:
  needs: build-push
  if: github.ref == 'refs/heads/main'
  environment: prod               # 关联 GitHub Environment，可配审批和密钥隔离
  runs-on: ubuntu-latest
  steps:
    # ... 同上面的部署步骤，namespace 换成 prod

on:                      # 触发器：什么事件启动 workflow
  push:
    branches: [ main ]
  pull_request:
  workflow_dispatch:      # 允许手动触发

jobs:
  job1:                  # job 之间默认并行，用 needs 声明依赖才串行
    runs-on: ubuntu-latest
    steps: [ ... ]
  job2:
    needs: job1          # job2 等 job1 成功后才跑
    runs-on: ubuntu-latest
    steps: [ ... ]

name: Multi-Env CI/CD
on:
  push:
    branches: [ main ]

jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with: { distribution: 'temurin', java-version: '17', cache: 'maven' }
      - run: mvn -B test
      - run: mvn -B package -DskipTests

  build-push:
    needs: build-test
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

  deploy-dev:
    needs: build-push
    runs-on: ubuntu-latest
    environment: dev                       # 关联 dev 环境
    steps:
      - name: Deploy to dev
        run: |
          kubectl set image deployment/order-service order-service=ghcr.io/${{ github.repository }}:${{ github.sha }} -n dev
          kubectl rollout status deployment/order-service -n dev --timeout=180s

  deploy-prod:
    needs: build-push
    runs-on: ubuntu-latest
    environment: prod                      # prod 环境配了「required reviewers」
    steps:
      - name: Deploy to prod
        run: |
          kubectl set image deployment/order-service order-service=ghcr.io/${{ github.repository }}:${{ github.sha }} -n prod
          kubectl rollout status deployment/order-service -n prod --timeout=300s

# 1. 部署绿色版本（用不同的 label 区分）
kubectl apply -f deployment-green.yaml     # labels: version=green

# 2. 验证绿色版本正常（单独开一个测试 Service 或直接 curl Pod）

# 3. 切换流量：改 Service 的 selector 指向 version=green
kubectl patch service order-service -p '{"spec":{"selector":{"app":"order-service","version":"green"}}}'

# 4. 观察一段时间没问题后，删掉蓝色版本
kubectl delete deployment order-service-blue

# 用 Istio 的 VirtualService 做金丝雀（10% 流量到 v2）
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: order-service
spec:
  hosts: ["order-service"]
  http:
    - route:
        - destination:
            host: order-service
            subset: v1
          weight: 90            # 90% 流量到旧版本
        - destination:
            host: order-service
            subset: v2
          weight: 10            # 10% 流量到新版本

# 在 docker/build-push-action 里打多个 tag
tags: |
  ghcr.io/${{ github.repository }}:${{ github.sha }}
  ghcr.io/${{ github.repository }}:1.2.0

kubectl rollout undo deployment/order-service

<!-- pom.xml 增加 -->
<dependency>
    <groupId>net.logstash.logback</groupId>
    <artifactId>logstash-logback-encoder</artifactId>
    <version>7.4</version>
</dependency>

<!-- src/main/resources/logback-spring.xml -->
<configuration>
    <!-- 控制台输出：JSON 格式，直接打到 stdout，由容器/DaemonSet 采集 -->
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="net.logstash.logback.encoder.LogstashEncoder">
            <!-- 附加应用名和环境，方便在 ES 里按维度过滤 -->
            <customFields>{"app":"order-service","env":"prod"}</customFields>
        </encoder>
    </appender>

    <root level="INFO">
        <appender-ref ref="CONSOLE"/>
    </root>
</configuration>

# filebeat/filebeat.yml —— Filebeat 配置
filebeat.inputs:
  - type: container              # 采集所有容器的 stdout
    paths:
      - /var/log/containers/*.log
    # 从容器日志里提取 namespace/pod/container 元数据，方便检索
    processors:
      - add_kubernetes_metadata:
          host: ${NODE_NAME}
          matchers:
            - logs_path:
                logs_path: "/var/log/containers/"

output.logstash:
  hosts: ["logstash:5044"]       # 转发给 Logstash 处理

# logstash/pipeline.conf —— Logstash 处理管道
input {
  beats { port => 5044 }         # 接收 Filebeat 传来的日志
}

filter {
  # 应用已经输出 JSON，这里直接解析即可，无需写 grok 正则
  json {
    source => "message"
    target => "parsed"
  }
}

output {
  elasticsearch {
    hosts => ["elasticsearch:9200"]
    index => "order-service-%{+YYYY.MM.dd}"   # 按天建索引，方便按天清理
  }
}

# 查所有 ERROR 日志
level:ERROR

# 查某个 traceId 的完整链路
traceId:"b3f4a1c2d3e4f5a6"

# 查某个接口的所有日志
uri:"/api/orders"

// config/TraceIdFilter.java
@Component
@Slf4j
public class TraceIdFilter extends OncePerRequestFilter {

    private static final String TRACE_ID_HEADER = "X-Trace-Id";

    @Override
    protected void doFilterInternal(HttpServletRequest request,
                                    HttpServletResponse response,
                                    FilterChain chain) throws IOException, ServletException {
        // 优先取上游传来的 traceId（透传），没有就生成一个，保证跨服务链路是同一个 id
        String traceId = request.getHeader(TRACE_ID_HEADER);
        if (traceId == null || traceId.isBlank()) {
            traceId = UUID.randomUUID().toString().replace("-", "");
        }
        // 放进 MDC：logback 的 JSON encoder 会自动把它加进每条日志
        MDC.put("traceId", traceId);
        // 回写响应头，方便前端/客户端报障时带上 traceId
        response.setHeader(TRACE_ID_HEADER, traceId);
        try {
            chain.doFilter(request, response);
        } finally {
            // 关键：请求结束必须清理 MDC，否则线程池复用线程会串号
            MDC.remove("traceId");
        }
    }
}

# filebeat-daemonset.yaml（精简版，完整镜像名略）
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: filebeat
  namespace: kube-system
spec:
  selector:
    matchLabels: { app: filebeat }
  template:
    metadata:
      labels: { app: filebeat }
    spec:
      containers:
        - name: filebeat
          image: docker.elastic.co/beats/filebeat:8.12.0
          args: ["-c", "/etc/filebeat.yml", "-e"]
          env:
            - name: NODE_NAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName    # 注入节点名，用于日志元数据
          volumeMounts:
            - name: varlog
              mountPath: /var/log/containers   # 容器日志所在目录（宿主机）
              readOnly: true
            - name: config
              mountPath: /etc/filebeat.yml
              subPath: filebeat.yml
      volumes:
        - name: varlog
          hostPath:
            path: /var/log/containers          # 挂载宿主机日志目录
        - name: config
          configMap:
            name: filebeat-config

// ILM 策略：索引 7 天后转冷，30 天后删除
PUT _ilm/policy/order-service-logs
{
  "policy": {
    "phases": {
      "hot": { "actions": { "rollover": { "max_age": "1d", "max_size": "50gb" } } },
      "delete": { "min_age": "30d", "actions": { "delete": {} } }
    }
  }
}

{
  "@timestamp": "2026-08-14T10:30:00.000Z",   // 日志时间（ES 的 @timestamp）
  "level": "INFO",                              // 日志级别，按级别过滤
  "logger_name": "com.example.order.service.OrderService",  // 来源类
  "thread_name": "http-nio-8080-exec-3",       // 线程名
  "message": "下单成功, orderId=ORDER-123",     // 日志正文
  "app": "order-service",                       // 应用名（customFields）
  "env": "prod",                                // 环境（customFields）
  "traceId": "b3f4a1c2d3e4f5a6"                 // 链路 id（MDC）
}

java 
  -Xms2g -Xmx2g                           # 堆初始/最大设为相等，避免运行中动态扩缩容带来的抖动
  -XX:+UseG1GC                            # 使用 G1
  -XX:MaxGCPauseMillis=200                # 目标最大 GC 停顿 200ms
  -XX:InitiatingHeapOccupancyPercent=45   # 堆占用 45% 就开始并发标记，避免 full GC
  -XX:+HeapDumpOnOutOfMemoryError         # OOM 时自动 dump 堆（排障的救命稻草）
  -XX:HeapDumpPath=/tmp/heapdump.hprof    # dump 文件路径（容器里挂到持久卷，否则重启丢失）
  -XX:+ExitOnOutOfMemoryError             # OOM 后主动退出，让 K8s 重启，而不是僵死
  -jar app.jar

# application-prod.yml
server:
  shutdown: graceful                 # 开启优雅停机
spring:
  lifecycle:
    timeout-per-shutdown-phase: 30s  # 最多等 30 秒让在途请求处理完

# 堆内存不足
java.lang.OutOfMemoryError: Java heap space
# 元空间不足
java.lang.OutOfMemoryError: Metaspace
# 直接内存不足
java.lang.OutOfMemoryError: Direct buffer memory

# 找到 Java 进程 PID
jps -l
# 或容器内：ps aux | grep java

# 手动 dump 堆到文件
jcmd <PID> GC.heap_dump /tmp/heapdump.hprof

# 查看 GC 情况，判断是「回收不过来」还是「对象真的多」
jstat -gcutil <PID> 1000 10   # 每秒打印一次 GC 占比，共 10 次

# 也可以先用 jmap 看个粗略的类占用排行（无需 MAT）
jmap -histo:live <PID> | head -20

// service/MemoryLeakDemo.java —— 故意制造内存泄漏的代码（用于演示排查）
@Slf4j
@Service
public class MemoryLeakDemo {

    // 致命问题：static 集合，持有所有订单对象引用，GC 永远无法回收
    // static 字段的生命周期 = JVM 生命周期，这里的 List 会无限增长直到 OOM
    private static final List<OrderVO> CACHE = new ArrayList<>();

    @Scheduled(fixedRate = 100)
    public void leak() {
        // 每 100ms 往静态集合里塞一个对象，模拟「缓存忘记清理」
        CACHE.add(new OrderVO("ORDER-" + System.currentTimeMillis(), "SUCCESS"));
    }
}

# 1. 用受限堆内存启动，加速 OOM 复现
java -Xmx256m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof -jar app.jar

# 2. 观察内存曲线（另一个终端）
curl http://localhost:8080/actuator/metrics/jvm.memory.used
# 可以看到 used 持续上升，GC 后也不回落 —— 典型的泄漏特征

# 3. OOM 后，dump 文件已自动生成
ls -lh /tmp/heapdump.hprof

@Slf4j
@Service
public class MemoryLeakDemo {

    // 修复：用有界缓存，超过 1000 条自动淘汰最旧的，内存有上限
    private final Queue<OrderVO> cache = new ArrayDeque<>(1000);

    @Scheduled(fixedRate = 100)
    public void leak() {
        cache.offer(new OrderVO("ORDER-" + System.currentTimeMillis(), "SUCCESS"));
        if (cache.size() > 1000) {
            cache.poll();   // 淘汰最旧，控制内存上界
        }
    }
}

java -Xlog:gc*:file=/tmp/gc.log:time,uptime,level,tags -jar app.jar

# 用 jstat 实时看 GC 占用比例（最实用的一个命令）
jstat -gcutil <PID> 1000
# 输出列：S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
# E=新生代占用、O=老年代占用、YGC=年轻代GC次数、FGC=Full GC次数、GCT=总停顿时间

# 或用 jcmd 打印详细 GC 统计
jcmd <PID> GC.heap_info

# 1. 找到 CPU 占用最高的线程
top -H -p <PID>              # 看进程内各线程的 CPU 占用，记下最高的线程号（TID）

# 2. TID 转十六进制（jstack 里线程号是十六进制）
printf '%xn' <TID>          # 得到 nid

# 3. dump 线程栈，搜这个 nid
jstack <PID> > thread.txt
grep -A 20 'nid=0x<十六进制>' thread.txt

jstack <PID> | grep -A 20 'Found one Java-level deadlock'
# 会打印出互相等待的两个线程及其持有的锁

# 引用链的典型形态（读懂它就能定位泄漏）
# class java.util.ArrayList
#   └── static field: com.example.order.service.MemoryLeakDemo.CACHE
#         └── ...
# 含义：MemoryLeakDemo.CACHE 这个 static 字段持有一个 ArrayList，
#       它又持有了海量 OrderVO 对象，导致无法 GC

# 用 Actuator 指标手动观察（配合 Grafana 更直观）
watch -n 2 'curl -s http://localhost:8080/actuator/metrics/jvm.memory.used'