1. 项目概述：企业级内容服务的“一键式”蓝图

如果你正在为团队寻找一个既能管理海量文档，又能支撑复杂业务流程，并且可以随着业务增长灵活扩展的企业级内容管理平台，那么 Alfresco Content Services (ACS) 绝对是一个绕不开的名字。而 acs-deployment 这个项目，就是让你能快速、稳定地将这个强大的平台部署到生产环境的关键。简单来说，它不是一个简单的安装包，而是一套经过精心设计的、基于 Docker 和 Kubernetes 的现代化部署方案集合。

想象一下，你要部署的不是一个简单的博客系统，而是一个需要处理成千上万用户并发访问、管理 PB 级非结构化数据、并与数十个其他企业系统（如 CRM、ERP）集成的核心平台。传统的“下载-安装-配置”模式在这里会变得异常脆弱和低效。 acs-deployment 项目正是为了解决这个问题而生。它通过容器化和编排技术，将 ACS 复杂的分布式架构（包括内容存储库、搜索服务、转换引擎、同步服务等）打包成可重复、可版本控制、可一键部署的标准化单元。

对于我这样的运维和架构师而言，这个项目的价值在于它提供了一套“最佳实践”的起点。无论是想快速搭建一个开发测试环境，还是规划一个高可用的生产集群，你都可以从这里找到经过社区验证的可靠配置。它极大地降低了从“软件评估”到“系统上线”之间的技术门槛和部署风险。接下来，我将带你深入拆解这个项目，从设计思路到实操细节，分享我在多个生产环境部署中积累的经验和踩过的坑。

2. 核心架构与设计哲学解析

2.1 为什么选择 Docker Compose 与 Kubernetes 双轨制？

打开 acs-deployment 的代码仓库，你会立刻发现它主要提供了两种部署方式：基于 Docker Compose 的单机或小型环境部署，以及基于 Kubernetes (Helm Charts) 的云原生分布式部署。这种“双轨制”设计绝非偶然，它精准地覆盖了从开发到生产的不同阶段需求。

Docker Compose 路径：快速验证与开发利器 对于开发者、架构师或小型团队，Docker Compose 方案是入门和原型验证的首选。它的核心优势在于“简单”。你只需要在本地或一台虚拟机上有 Docker 环境，通过一个 docker-compose.yml 文件，就能在几分钟内拉起一个包含 ACS 所有核心组件（Alfresco Repository, Alfresco Share, Alfresco Search Services, PostgreSQL, ActiveMQ）的完整环境。所有的服务依赖、网络配置、数据卷挂载都定义在这个文件里，一目了然。

注意：虽然 Docker Compose 方便，但它默认配置并不适用于生产环境。例如，它通常使用嵌入式数据库（如 H2）或简单配置的 PostgreSQL，且没有配置持久化存储的高可用、负载均衡和健康检查。它的定位很明确： 快速启动，功能验证，开发调试 。

Kubernetes (Helm) 路径：生产就绪的基石 当你的需求转向高可用、弹性伸缩、CI/CD 集成和复杂的运维管理时，Kubernetes 路径是唯一的选择。 acs-deployment 项目中的 Helm Chart 将 ACS 的每个微服务（或组件）打包成一个独立的、可配置的 Kubernetes 部署单元。通过 Helm 的价值文件（ values.yaml ），你可以像搭积木一样灵活地定制整个集群：

• 副本数与弹性伸缩 ：你可以轻松地为 Repository 或 Share 服务配置多个 Pod 副本，并通过 Horizontal Pod Autoscaler 根据 CPU/内存指标自动扩缩容。
• 配置与密钥管理 ：所有敏感信息（数据库密码、许可证密钥）和运行时配置都可以通过 Kubernetes 的 ConfigMap 和 Secret 来管理，与镜像解耦，更安全、更易维护。
• 存储与网络 ：可以灵活对接云厂商的持久卷（如 AWS EBS, Azure Disk, Google Persistent Disk）或企业存储（如 NFS, Ceph），并配置 Ingress 控制器来管理外部访问和 TLS 终止。

这种双轨制设计体现了一个清晰的演进路径：用 Docker Compose 快速上手和概念验证，用 Kubernetes Helm Chart 规划和实施生产系统。在实际项目中，我经常建议团队先使用 Compose 版本让业务方快速体验核心功能，同时在后台基于 Helm Chart 设计和搭建生产级的 Kubernetes 集群。

2.2 核心组件交互与数据流剖析

要成功部署和运维 ACS，必须理解其内部组件如何协同工作。 acs-deployment 的配置清单本身就是一份绝佳的架构说明书。

1. 内容存储核心：Alfresco Repository 这是 ACS 的大脑，一个运行在 Tomcat 上的 Java 应用。它直接与 PostgreSQL 数据库交互，存储元数据（如文档属性、权限、版本信息）；同时，它通过内容存储（Content Store）将实际的文档文件（如 PDF, Word）保存到指定的文件系统或对象存储（如 S3）中。在 Kubernetes 部署中，Repository 的 Pod 通常会挂载一个持久化卷用于本地缓存，并配置指向外部对象存储的连接。

2. 用户交互界面：Alfresco Share / Alfresco Digital Workspace Share 是经典的 Web 客户端，而 Alfresco Digital Workspace (ADW) 是更现代化的替代品。它们都是独立的前端应用，通过 REST API 与 Repository 通信。在部署时，需要确保它们能正确解析后端 API 的地址。在 Kubernetes 中，这通常通过 Service 的 DNS 名称来实现。

3. 搜索与索引引擎：Alfresco Search Services (ASS) 基于 Apache Solr，ASS 为 Repository 中的内容建立全文索引。这里有一个关键的数据流：当 Repository 中的内容发生变化（增删改）时，它会通过 ActiveMQ 消息队列异步地发送索引更新事件。ASS 监听这个消息队列，消费事件并更新 Solr 索引。这种异步解耦的设计保证了即使搜索服务暂时不可用，内容操作也能正常进行，索引最终会保持一致。在 acs-deployment 的配置中，你需要仔细配置 ActiveMQ 的连接信息和 Solr 的核心配置。

4. 后台处理与集成：ActiveMQ 与 Transform Service ActiveMQ 是中枢神经，除了处理搜索索引事件，还负责驱动内容转换（如 Word 转 PDF）、工作流任务等异步作业。Transform Service 是一个独立的微服务，专门处理内容格式转换。当用户请求预览一个文档时，Repository 会通过消息队列将转换任务分发给 Transform Service，转换完成后的文件会存储到指定的“已转换内容存储”中。

理解这些数据流至关重要。当部署后出现“搜索不到新文件”或“文档无法预览”的问题时，你的排查链路应该是：Repository 日志 -> ActiveMQ 状态 -> Search Services 或 Transform Service 日志。 acs-deployment 的 Kubernetes 配置通常已经为这些服务设置了就绪探针（Readiness Probe）和存活探针（Liveness Probe），帮助你快速定位故障点。

3. 基于 Docker Compose 的快速部署实战

3.1 环境准备与前置检查

在拉取代码之前，确保你的环境满足最低要求：

• Docker Engine ：版本 20.10.x 或更高。建议使用 Docker Desktop（Mac/Windows）或社区版（Linux）。
• Docker Compose ：版本 1.29.x 或更高。现在 Docker Desktop 已内置 Compose V2，命令通常是 docker compose （无短横线）。
• 系统资源 ：这是最容易低估的部分。一个完整的 ACS 组合至少需要 8GB 可用内存 和 4核 CPU 。如果资源不足，PostgreSQL 或 Solr 可能会启动失败，表现就是容器不断重启。建议在 Linux 上使用 free -h 和 nproc 检查资源。

克隆项目仓库：

git clone https://github.com/Alfresco/acs-deployment.git
cd acs-deployment

进入 docker-compose 目录，你会看到多个配置文件。对于首次体验，我们使用最基础的 docker-compose.yml 。

实操心得：在运行前，先花一分钟浏览一下 docker-compose.yml 文件。重点关注 volumes 部分，了解哪些数据（数据库、索引、内容文件）被挂载到了本地主机。这有助于你后续备份或迁移数据。默认配置下，数据会保存在 Docker 管理的匿名卷中，重启容器不会丢失，但删除容器会。对于开发，这没问题；对于想保留数据的测试，建议在文件中将卷映射改为本地目录，例如 - ./alf_data:/usr/local/tomcat/alf_data 。

3.2 一键启动与初始访问

启动服务非常简单：

docker-compose up -d

-d 参数让服务在后台运行。接下来，使用 docker-compose logs -f 来跟踪启动日志。这是一个关键步骤，不要启动后就离开。你需要观察所有容器是否都成功进入健康状态。特别是 alfresco 容器，它的启动时间最长（可能需要3-5分钟），因为它需要初始化数据库和内部组件。

当你看到日志中出现类似 “Server startup in [XXXXX] milliseconds” 的信息时，说明 Repository 启动成功了。此时，你可以访问以下服务：

• Alfresco Share : http://localhost:8080/share
• Alfresco Repository REST API : http://localhost:8080/alfresco
• Alfresco Digital Workspace (如果包含): http://localhost:8080/workspace

默认的管理员账号密码是 admin / admin 。首次登录 Share 时，系统可能会花一点时间初始化用户界面。

常见启动问题与排查：

1. 端口冲突 ：如果 8080, 5432 (PostgreSQL), 61616 (ActiveMQ) 等端口被占用，Compose 会启动失败。修改 docker-compose.yml 中服务的 ports 映射即可，例如将 “8080:8080” 改为 “8081:8080” 。
2. 数据库初始化失败 ：如果 postgres 容器启动比 alfresco 慢，可能导致 Alfresco 连接数据库失败。观察日志，如果看到数据库连接错误，可以尝试先单独启动数据库： docker-compose up -d postgres ，等待其就绪后再启动全部服务。
3. 内存不足导致容器退出 ：使用 docker-compose ps 查看容器状态，如果某个容器不断重启，使用 docker-compose logs [服务名] 查看其日志，很可能会看到 OutOfMemoryError 或 killed 提示。这时你必须增加 Docker 的资源分配（在 Docker Desktop 的设置中）或增加物理内存。

3.3 基础配置调优与数据持久化

默认的 Compose 配置是为了最小化资源消耗和快速启动，有几个地方在生产概念验证（PoC）或长期测试时需要调整。

1. 持久化数据到主机目录 如前所述，默认使用匿名卷。为了明确数据位置，修改 docker-compose.yml ，为关键服务添加绑定挂载（bind mount）：

services:
  postgres:
    volumes:
      - ./postgres_data:/var/lib/postgresql/data
  alfresco:
    volumes:
      - ./alfresco_data:/usr/local/tomcat/alfresco_data
  solr6:
    volumes:
      - ./solr_data:/opt/alfresco-search-services/data

这样，所有数据都会保存在当前目录下的子文件夹中，一目了然，也方便备份。

2. 调整 JVM 内存参数 对于 alfresco 和 solr6 服务，默认的 JVM 堆内存可能不够。你可以在 docker-compose.yml 中通过环境变量调整：

services:
  alfresco:
    environment:
      - JAVA_OPTS=-Xms2g -Xmx4g -Djava.awt.headless=true -Dfile.encoding=UTF-8
  solr6:
    environment:
      - SOLR_JAVA_MEM=-Xms1g -Xmx2g

-Xms 指定初始堆大小， -Xmx 指定最大堆大小。根据你的主机资源合理分配，Alfresco Repository 通常需要至少 2GB 的堆空间。

3. 启用更详细的日志 对于调试，你可能需要更详细的日志。可以修改 alfresco 服务的日志级别，通过挂载自定义的 log4j.properties 文件，或者更简单，在 JAVA_OPTS 中添加： -Dlog4j.configuration=file:/usr/local/tomcat/shared/classes/alfresco/extension/custom-log4j.properties 你需要先在本地创建这个配置文件，并将其挂载到容器内的对应路径。

完成这些调优后，执行 docker-compose down 然后 docker-compose up -d 重新启动，一个更健壮、更适合开发的 ACS 环境就准备好了。

4. 基于 Kubernetes Helm 的生产级部署详解

4.1 集群环境准备与 Helm 安装

在生产环境部署 ACS，我们假设你已经拥有一个运行中的 Kubernetes 集群（可以是云托管的如 EKS、AKS、GKE，也可以是自建的如使用 kubeadm 部署的集群）。以下是前置条件：

1. kubectl ：配置好，能正常访问你的集群。
2. Helm 3 ：这是必须的包管理工具。安装方法很简单，从 GitHub 发布页下载二进制文件即可。
3. 存储类 (StorageClass) ：确保集群中有配置好的 StorageClass，用于动态创建持久卷（PV）。在云平台上，这通常是自动配置好的（如 gp2 on AWS, standard on GKE）。你可以通过 kubectl get storageclass 查看。
4. Ingress 控制器 ：为了从集群外部访问 ACS，需要安装 Ingress 控制器，如 Nginx Ingress Controller 或 Traefik。这通常需要额外的部署步骤。
5. 域名与 TLS 证书 ：准备一个域名（或子域名），并规划好 TLS 证书的获取方式（如 Let‘s Encrypt，或使用集群的证书管理器如 cert-manager）。

4.2 Helm Chart 结构与核心价值文件解析

acs-deployment 项目中的 Helm Chart 结构清晰，核心是 values.yaml 文件。部署前，我们必须创建自己的 custom-values.yaml 来覆盖默认配置。

关键配置域解析：

• global ：全局设置，如存储类名、镜像拉取策略、节点选择器/容忍度等。
• alfresco-infrastructure ：基础设施组件配置，包括 PostgreSQL、ActiveMQ、Nginx Ingress（可选）、注册表（Registry）等。
• alfresco-content-services ：ACS 核心服务配置，包括 Repository、Share、Digital Workspace、Search Services、Transform Service 等。
• alfresco-process-services 和 alfresco-sync-service ：如果需要流程引擎和桌面同步功能，在这里配置。

一个最小化的生产级 custom-values.yaml 示例：

# custom-values.yaml
global:
  # 指定存储类，根据你的集群实际情况修改
  storageClass: “gp2”
  # 镜像拉取策略，生产环境建议 Always 或 IfNotPresent
  pullPolicy: “IfNotPresent”

alfresco-content-services:
  # 配置 Alfresco Repository
  repository:
    replicaCount: 2 # 至少2个副本以实现高可用
    environment:
      JAVA_OPTS: “-Xms4g -Xmx8g -Djava.awt.headless=true”
    # 资源请求与限制，至关重要！
    resources:
      requests:
        memory: “6Gi”
        cpu: “1000m”
      limits:
        memory: “10Gi”
        cpu: “2000m”
    # 使用外部数据库，而不是Chart内置的（生产环境推荐）
    externalDatabase: true
    database:
      driver: “org.postgresql.Driver”
      url: “jdbc:postgresql://my-production-postgres:5432/alfresco”
      user: “alfresco”
      existingSecret: “alfresco-db-secret” # 密码存放在K8s Secret中
    # 使用外部对象存储（如S3）作为主内容存储
    filestore:
      s3:
        enabled: true
        bucketName: “my-alfresco-content-bucket”
        endpoint: “s3.amazonaws.com”
        region: “us-east-1”
        existingSecret: “alfresco-s3-secret”

  # 配置 Share
  share:
    replicaCount: 2
    ingress:
      enabled: true
      host: “share.mycompany.com”
      tls: true
      secretName: “share-tls-secret”

  # 配置 Search Services
  alfresco-search:
    replicaCount: 2
    environment:
      SOLR_JAVA_MEM: “-Xms2g -Xmx4g”

# 如果使用Chart内置的PostgreSQL（仅适用于测试或小型生产）
postgresql:
  enabled: false # 因为我们使用了外部数据库

这个配置展示了几个关键生产实践： 多副本部署、资源限制、外部数据库、外部对象存储、Ingress 配置 。

4.3 分步部署与初始化流程

步骤1：创建命名空间和密钥

kubectl create namespace alfresco
# 创建数据库密码Secret（假设密码为‘supersecret’）
kubectl create secret generic alfresco-db-secret \
  --from-literal=postgres-password=supersecret \
  --namespace alfresco
# 创建S3访问密钥Secret
kubectl create secret generic alfresco-s3-secret \
  --from-literal=accessKey=YOUR_ACCESS_KEY \
  --from-literal=secretKey=YOUR_SECRET_KEY \
  --namespace alfresco

步骤2：部署基础设施（如果需要 Chart 内的组件） 如果你决定使用 Chart 内置的 PostgreSQL 和 ActiveMQ（对于中小规模部署是可行的），确保在 custom-values.yaml 中启用它们并配置好资源。

步骤3：使用 Helm 安装 ACS

# 添加 Alfresco Helm 仓库（如果尚未添加）
helm repo add alfresco https://kubernetes-charts.alfresco.com
helm repo update

# 安装/升级发布
helm upgrade --install alfresco-cs alfresco/alfresco-content-services \
  --values custom-values.yaml \
  --namespace alfresco \
  --timeout 10m

--timeout 参数很重要，因为 ACS 部署和初始化可能需要较长时间（10-15分钟）。

步骤4：监控部署状态

# 查看所有Pod的状态
kubectl get pods -n alfresco --watch
# 查看Service和Ingress
kubectl get svc,ingress -n alfresco

等待所有 Pod 都进入 Running 状态，并且就绪探针（READY 列为 2/2 或 1/1）通过。特别是 alfresco-cs-repository-xxx 这个 Pod，它的启动日志可以通过 kubectl logs -f [pod-name] -n alfresco 查看，你会看到 Tomcat 启动和 Alfresco 子系统初始化的过程。

步骤5：访问与验证 根据 Ingress 配置的域名（如 share.mycompany.com ），在浏览器中访问。如果配置了 TLS，确保使用 HTTPS。使用默认凭据 admin/admin 登录。登录后，建议立即在 管理员工具 中修改默认密码。

4.4 生产环境关键配置与优化建议

1. 数据库配置 ：

   • 强烈建议使用外部托管的、高可用的 PostgreSQL 集群 （如 AWS RDS, Azure Database for PostgreSQL）。这提供了自动备份、故障转移、性能监控等托管优势。Chart 内置的 PostgreSQL 仅适用于测试。
   • 根据负载调整数据库参数，如 shared_buffers , work_mem , maintenance_work_mem 。对于 ACS，确保 max_connections 设置足够高（建议 >200）。

2. 存储配置 ：

   • 内容存储 ：对于生产环境，使用对象存储（如 AWS S3, Azure Blob Storage, Google Cloud Storage）替代文件系统存储是 最佳实践 。它提供了无限扩展性、高耐久性和成本效益。 acs-deployment 的 Chart 原生支持 S3 配置。
   • 索引存储 ：Solr 的索引文件对 I/O 性能敏感。建议为 Search Services 的 Pod 使用高性能的 SSD 持久卷。

3. 资源与弹性伸缩 ：

   • 必须为每个容器设置合理的 resources.requests 和 resources.limits 。这能防止单个服务耗尽节点资源，并帮助 Kubernetes 调度器做出正确决策。
   • 配置 Horizontal Pod Autoscaler (HPA)，让 Repository 和 Share 等服务能根据 CPU/内存使用率自动扩缩容。

   # 示例：为Repository配置HPA（需单独创建HPA资源）
   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: alfresco-repository-hpa
     namespace: alfresco
   spec:
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: alfresco-cs-repository
     minReplicas: 2
     maxReplicas: 5
     metrics:
     - type: Resource
       resource:
         name: cpu
         target:
           type: Utilization
           averageUtilization: 70
   

4. 网络与安全 ：

   • 使用 Ingress 控制器并配置 TLS 终止，启用 HSTS。
   • 在集群内部，使用 Network Policies 限制 Pod 之间的网络流量，遵循最小权限原则。
   • 定期轮换存储在 Kubernetes Secret 中的密码和密钥。

5. 备份与灾难恢复 ：

   • 数据库 ：建立定期的、自动化的 PostgreSQL 备份策略（如使用 pg_dump 或云服务的快照功能）。
   • 内容 ：如果你的内容存储在 S3 上，可以利用 S3 的版本控制和跨区域复制功能。
   • 配置 ：将你的 custom-values.yaml 文件和任何自定义的 ConfigMap 纳入版本控制系统（如 Git）。
   • 演练恢复流程 ：定期测试从备份中恢复整个系统或部分组件的能力。

5. 运维实战：监控、日志与故障排查

5.1 监控指标体系搭建

一个健康的 ACS 集群需要全面的监控。你需要关注以下几个层面的指标：

1. 基础设施层（Kubernetes 集群） ：

• 节点资源 ：CPU、内存、磁盘 I/O 和空间使用率。
• Pod 状态 ：重启次数、就绪状态、资源使用率（特别是 Repository 和 Solr 的 JVM 堆内存）。
• 工具：Prometheus + Grafana（通过 Node Exporter, kube-state-metrics）是标准方案。

2. 应用层（ACS 组件） ：

• Alfresco Repository ：
  • JVM 指标 ：堆内存使用率、GC 频率和耗时、线程数。可以通过 JMX Exporter 暴露给 Prometheus。
  • 请求指标 ：HTTP 请求速率、延迟、错误率（5xx）。可以通过在 Tomcat 前放置一个 Sidecar 代理（如 Envoy）或使用应用性能管理（APM）工具来收集。
  • 数据库连接池 ：活跃连接数、等待连接数。
• Alfresco Search Services (Solr) ：
  • 索引指标 ：文档数量、查询速率、查询延迟、索引缓存命中率。
  • JVM 指标 ：同上。
• PostgreSQL ：
  • 数据库连接 ：当前连接数、最大连接数。
  • 查询性能 ：慢查询数量、锁等待情况。
  • 存储 ：表空间使用量。
  • 工具：可以使用 postgres_exporter 。

3. 业务层 ：

• 用户活跃度 ：并发会话数、API 调用频率。
• 内容操作 ：上传/下载速率、搜索请求量。
• 系统健康 ：关键后台进程（如内容转换、索引跟踪）的状态。

在 Kubernetes 中，你可以为 ACS 的 Deployment 添加 Prometheus 注解，使其自动被 Prometheus 服务发现和抓取。同时，在 Grafana 中导入或制作针对 ACS 的监控仪表盘。

5.2 集中化日志收集与分析

当有多个 Pod 时，查看日志变得困难。必须建立集中化日志系统。

方案：EFK Stack (Elasticsearch, Fluentd/Fluent Bit, Kibana)

1. Fluent Bit 作为日志收集器 ：以 DaemonSet 形式运行在每个节点上，轻量级，负责收集容器日志（ /var/log/containers/*.log ），并附加 Kubernetes 元数据（如 Pod 名称、命名空间）。
2. Elasticsearch 作为日志存储和索引引擎 。
3. Kibana 作为日志查询和可视化界面 。

配置 Fluent Bit 过滤和解析 ACS 日志（特别是多行日志，如 Java 异常堆栈跟踪）。在 Kibana 中，你可以轻松地按命名空间（ kubernetes.namespace_name: alfresco ）、Pod 名称或日志级别进行过滤，快速定位问题。

5.3 常见故障场景与排查手册

即使部署完美，在生产中也会遇到问题。以下是一些典型场景及排查思路：

问题1：用户无法上传大文件，或上传超时。

• 排查链 ：
  1. 检查网络 ：Ingress 控制器或负载均衡器是否有文件大小限制？检查 Nginx Ingress 的 proxy-body-size 注解。
  2. 检查 Repository Pod ： kubectl logs 查看 Repository Pod 日志，是否有相关错误。检查 Pod 的内存使用情况，是否因大文件处理导致 GC 频繁或内存溢出。
  3. 检查存储 ：如果使用 S3，检查网络连通性和 S3 桶的权限。查看 S3 的访问日志和 CloudTrail。
  4. 检查 Tomcat 配置 ：ACS 的 Tomcat 有 maxSwallowSize 等配置限制大文件。这些配置可以通过环境变量或 ConfigMap 覆盖。

问题2：搜索功能失效，找不到新上传的文件。

• 经典的数据一致性问题 。排查链：
  1. 检查 ActiveMQ ： kubectl logs 查看 ActiveMQ Pod 是否运行正常。检查 Repository 日志，看它是否在成功发送索引消息。
  2. 检查 Alfresco Search Services Pod ：查看其日志，确认它是否在正常消费 ActiveMQ 中的消息。常见错误是 Solr 核心创建失败或与 Repository 的 SSL 证书验证失败。
  3. 手动触发索引 ：在 Share 管理员工具中，尝试“启动跟踪”或“重建索引”，观察后台日志。
  4. 检查网络策略 ：确保 Repository Pod 和 ActiveMQ Service、Search Services Pod 之间的网络是通的。

问题3：系统运行一段时间后变慢，响应延迟高。

• 性能问题，需要多维度分析 ：
  1. 监控指标 ：首先查看 Grafana 仪表盘。是 CPU 瓶颈、内存瓶颈（频繁 Full GC）还是 I/O 瓶颈？
  2. 数据库 ：检查 PostgreSQL 的 CPU、连接数和慢查询。可能是缺少关键索引或需要 Vacuum。
  3. JVM 堆转储 ：如果怀疑内存泄漏，可以获取 Repository 或 Solr 的 JVM 堆转储文件进行分析（使用 jmap 或通过 JMX）。
  4. 缓存 ：检查 Alfresco 的各级缓存（如 infinispan ）命中率。在集群环境下，确保缓存配置正确（使用分布式缓存而非本地缓存）。

问题4：Pod 频繁重启（CrashLoopBackOff）。

• 快速诊断命令 ：

  # 1. 查看Pod状态和最近事件
  kubectl describe pod <pod-name> -n alfresco
  # 2. 查看Pod内容器的退出码和原因
  kubectl logs <pod-name> -n alfresco --previous # 查看上一次运行的日志
  # 3. 常见原因：
  #    - 启动探针失败：应用启动太慢，调整`initialDelaySeconds`和`periodSeconds`。
  #    - 内存不足（OOMKilled）：`kubectl describe pod` 的 `State` 字段会显示原因。增加 `resources.limits.memory`。
  #    - 配置错误：如数据库连接字符串错误、S3密钥错误。检查环境变量和 ConfigMap。
  #    - 依赖服务未就绪：例如，Repository 在 PostgreSQL 完全准备好之前就启动了。可以使用 `initContainers` 或更好的 readiness probe 来确保依赖。
  

建立一个清晰的排查流程图和运行手册，能极大缩短平均恢复时间（MTTR）。将上述常见问题的检查点固化到你的运维流程中。