寻音捉影·侠客行生产环境：Kubernetes集群部署+HPA自动扩缩容应对峰值检索请求

寻音捉影·侠客行生产环境：Kubernetes集群部署+HPA自动扩缩容应对峰值检索请求

在信息爆炸的时代，音频内容正以前所未有的速度增长。无论是会议录音、播客节目、客服通话还是自媒体素材，如何从海量音频中快速、精准地定位到关键信息，成为许多团队面临的现实挑战。手动查找无异于大海捞针，效率低下且容易遗漏。

「寻音捉影·侠客行」正是为解决这一痛点而生。它是一款基于先进语音识别技术的音频关键词检索工具，能够像一位拥有“顺风耳”的江湖隐士，在瞬息之间为你锁定目标词汇。然而，当这款工具从个人使用走向团队协作，从偶尔调用变为高频服务时，单机部署的局限性便暴露无遗：性能瓶颈、资源浪费、服务不稳定……

本文将带你深入“侠客行”的生产环境部署实战，揭秘如何借助Kubernetes（K8s）这一“容器编排掌门”和HPA（Horizontal Pod Autoscaler）这一“自动伸缩心法”，构建一个弹性、高可用的音频检索服务集群，从容应对江湖中的任何流量风浪。

1. 为何需要生产级部署？

在个人开发或测试环境中，我们可能只需在本地运行一个Docker容器就能体验“侠客行”的全部功能。但生产环境是另一番天地。

想象一下这样的场景：市场部需要在1小时内从1000段产品访谈录音中找出所有提到“用户体验”和“竞品分析”的片段；客服团队希望实时监控通话录音，一旦出现“投诉”或“退款”关键词就立即预警。这些需求意味着我们的服务可能面临瞬间的请求洪峰。

单机部署的“侠客行”就像一位独行侠，武功再高也难敌千军万马。它可能会因为CPU过载而响应缓慢，因为内存不足而意外崩溃，更无法在硬件故障时保持服务不中断。

生产级部署的核心目标有三个：

• 高可用性：确保服务7x24小时稳定运行，即使部分节点故障也不影响整体
• 弹性伸缩：根据实时负载自动调整服务实例数量，既不错过高峰，也不浪费资源
• 易于管理：简化部署、更新、监控和运维的复杂度

这正是Kubernetes和HPA的用武之地。K8s为我们提供了管理容器化应用的完整平台，而HPA则让这个平台具备了“呼吸”的能力——根据需求自动伸缩。

2. 构建“侠客行”的Docker镜像

任何Kubernetes部署的起点都是一个标准的Docker镜像。我们需要将“侠客行”应用及其所有依赖打包成一个可移植、自包含的单元。

2.1 理解应用结构

“侠客行”的核心是一个Web应用，它通常包含以下几个关键部分：

• 前端界面：水墨武侠风格的Web界面
• 后端服务：处理文件上传、关键词检索的核心逻辑
• 语音识别引擎：基于FunASR的识别模块
• 依赖库：Python环境及相关机器学习库

2.2 编写Dockerfile

创建一个高效的Dockerfile是第一步。这里我们采用多阶段构建来减小最终镜像的体积：

# 第一阶段：构建环境 FROM python:3.9-slim as builder WORKDIR /app # 安装系统依赖 RUN apt-get update && apt-get install -y \ gcc \ g++ \ make \ cmake \ && rm -rf /var/lib/apt/lists/* # 复制依赖文件 COPY requirements.txt . # 安装Python依赖 RUN pip install --no-cache-dir --user -r requirements.txt # 第二阶段：运行环境 FROM python:3.9-slim WORKDIR /app # 安装运行时依赖 RUN apt-get update && apt-get install -y \ libgomp1 \ ffmpeg \ && rm -rf /var/lib/apt/lists/* # 从构建阶段复制已安装的Python包 COPY --from=builder /root/.local /root/.local # 确保脚本能找到我们安装的包 ENV PATH=/root/.local/bin:$PATH # 复制应用代码 COPY . . # 暴露端口 EXPOSE 7860 # 设置健康检查 HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD curl -f http://localhost:7860/ || exit 1 # 启动命令 CMD ["python", "app.py"]

2.3 关键优化点

这个Dockerfile有几个值得注意的优化：

1. 多阶段构建：第一阶段安装编译依赖和构建Python包，第二阶段只复制必要的运行文件，大幅减小了最终镜像体积
2. 清理缓存：每步安装后都清理apt缓存，避免无用文件增加镜像大小
3. 健康检查：添加HEALTHCHECK指令，让Kubernetes能够监控容器健康状态
4. 非root用户：在实际生产环境中，建议以非root用户运行容器，增强安全性

2.4 构建和测试镜像

构建镜像并推送到镜像仓库：

# 构建镜像 docker build -t xunying-xiakexing:latest . # 测试运行 docker run -p 7860:7860 xunying-xiakexing:latest # 推送到镜像仓库（以阿里云容器镜像服务为例） docker tag xunying-xiakexing:latest registry.cn-hangzhou.aliyuncs.com/your-namespace/xunying-xiakexing:latest docker push registry.cn-hangzhou.aliyuncs.com/your-namespace/xunying-xiakexing:latest

3. Kubernetes部署实战

有了Docker镜像，我们就可以开始在Kubernetes集群中部署“侠客行”了。K8s通过一系列资源对象来管理应用，我们需要理解每个对象的作用。

3.1 部署架构设计

在生产环境中，我们通常采用以下架构：

用户请求 → Ingress/Nginx → Service → Pod（多个副本） → 持久化存储（可选）

这种架构确保了：

• 负载均衡：Service自动将请求分发到健康的Pod
• 服务发现：Pod可以动态变化，但Service提供稳定访问端点
• 外部访问：Ingress处理外部HTTP/HTTPS流量

3.2 创建命名空间

首先为我们的应用创建一个独立的命名空间，实现资源隔离：

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

应用配置：

kubectl apply -f namespace.yaml

3.3 配置ConfigMap和Secret

将配置信息与镜像分离是云原生应用的最佳实践。对于“侠客行”，我们可能需要配置：

# configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: xiakexing-config namespace: xiakexing-prod data: # 应用配置 LOG_LEVEL: "INFO" MAX_FILE_SIZE: "100MB" SUPPORTED_FORMATS: "mp3,wav,flac,aac" # 模型配置 ASR_MODEL_PATH: "/app/models/speech_paraformer-large-vad-punc_asr_nat-zh-cn" VAD_MODEL_PATH: "/app/models/speech_fsmn_vad_zh-cn-16k-common-pytorch" PUNC_MODEL_PATH: "/app/models/punc_ct-transformer_zh-cn-common-vad_realtime-vocab272727" # 性能配置 BATCH_SIZE: "1" DEVICE: "cpu"

敏感信息如API密钥等应使用Secret：

# secret.yaml apiVersion: v1 kind: Secret metadata: name: xiakexing-secret namespace: xiakexing-prod type: Opaque data: # 使用base64编码的值 # echo -n "your-secret-value" | base64 api-key: eW91ci1zZWNyZXQtdmFsdWU=

3.4 创建Deployment

Deployment是K8s中管理应用副本的核心对象。它确保始终有指定数量的Pod在运行：

# deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: xiakexing-deployment namespace: xiakexing-prod labels: app: xiakexing component: web spec: # 初始副本数，HPA会根据需要调整 replicas: 2 selector: matchLabels: app: xiakexing component: web template: metadata: labels: app: xiakexing component: web spec: # 设置亲和性，避免所有Pod调度到同一节点 affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - xiakexing topologyKey: kubernetes.io/hostname containers: - name: xiakexing-web image: registry.cn-hangzhou.aliyuncs.com/your-namespace/xunying-xiakexing:latest imagePullPolicy: IfNotPresent # 资源请求和限制 - 这是HPA自动扩缩容的依据 resources: requests: cpu: "500m" # 0.5个CPU核心 memory: "1Gi" # 1GB内存 limits: cpu: "2000m" # 最多2个CPU核心 memory: "4Gi" # 最多4GB内存 # 端口配置 ports: - containerPort: 7860 name: http protocol: TCP # 环境变量配置 env: - name: LOG_LEVEL valueFrom: configMapKeyRef: name: xiakexing-config key: LOG_LEVEL - name: MAX_FILE_SIZE valueFrom: configMapKeyRef: name: xiakexing-config key: MAX_FILE_SIZE # 从Secret读取敏感信息 - name: API_KEY valueFrom: secretKeyRef: name: xiakexing-secret key: api-key # 健康检查 livenessProbe: httpGet: path: /health port: 7860 initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 3 failureThreshold: 3 readinessProbe: httpGet: path: /ready port: 7860 initialDelaySeconds: 5 periodSeconds: 5 timeoutSeconds: 2 # 挂载点配置（如果需要持久化存储） volumeMounts: - name: model-storage mountPath: /app/models readOnly: true - name: cache-volume mountPath: /tmp # 卷定义 volumes: - name: model-storage persistentVolumeClaim: claimName: xiakexing-model-pvc - name: cache-volume emptyDir: {}

这个Deployment配置有几个关键点：

1. 资源请求和限制：为容器设置了CPU和内存的请求值（保证资源）和限制值（防止过度使用）
2. 健康检查：通过livenessProbe和readinessProbe确保只有健康的Pod接收流量
3. 反亲和性：通过podAntiAffinity尽量将Pod分散到不同节点，提高可用性
4. 配置分离：通过ConfigMap和Secret管理配置，而不是硬编码在镜像中

3.5 创建Service

Service为Pod提供稳定的网络端点，并实现负载均衡：

# service.yaml apiVersion: v1 kind: Service metadata: name: xiakexing-service namespace: xiakexing-prod labels: app: xiakexing component: web spec: selector: app: xiakexing component: web ports: - port: 80 targetPort: 7860 protocol: TCP name: http type: ClusterIP # 内部访问，外部通过Ingress访问

3.6 创建Ingress（如果需要外部访问）

如果要从集群外部访问服务，需要创建Ingress资源：

# ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: xiakexing-ingress namespace: xiakexing-prod annotations: # 使用Nginx Ingress Controller nginx.ingress.kubernetes.io/proxy-body-size: "100m" nginx.ingress.kubernetes.io/proxy-read-timeout: "300" nginx.ingress.kubernetes.io/proxy-send-timeout: "300" spec: ingressClassName: nginx rules: - host: xiakexing.yourdomain.com http: paths: - path: / pathType: Prefix backend: service: name: xiakexing-service port: number: 80

3.7 应用所有配置

一次性应用所有配置文件：

kubectl apply -f namespace.yaml kubectl apply -f configmap.yaml kubectl apply -f secret.yaml kubectl apply -f deployment.yaml kubectl apply -f service.yaml kubectl apply -f ingress.yaml

检查部署状态：

# 查看Pod状态 kubectl get pods -n xiakexing-prod # 查看Deployment状态 kubectl get deployment -n xiakexing-prod # 查看Service kubectl get service -n xiakexing-prod # 查看Pod日志 kubectl logs -f deployment/xiakexing-deployment -n xiakexing-prod

至此，“侠客行”已经成功部署到Kubernetes集群中，但还缺少应对流量波动的关键能力——自动扩缩容。

4. 配置HPA实现自动扩缩容

HPA（Horizontal Pod Autoscaler）是Kubernetes的自动扩缩容控制器，它可以根据监控指标自动调整Pod副本数量。对于“侠客行”这种CPU密集型的音频处理应用，CPU使用率是最合适的扩缩容指标。

4.1 HPA工作原理

HPA的工作流程可以概括为：

1. 监控指标：定期从Metrics Server获取Pod的资源使用情况
2. 计算期望副本数：根据当前指标值和目标值计算需要多少个Pod
3. 调整副本数：更新Deployment的replicas字段
4. Deployment响应：创建或删除Pod以达到期望状态

4.2 创建HPA配置

为“侠客行”创建HPA配置，基于CPU使用率进行自动扩缩容：

# hpa.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: xiakexing-hpa namespace: xiakexing-prod spec: # 关联的Deployment scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: xiakexing-deployment # Pod数量的最小值和最大值 minReplicas: 2 maxReplicas: 10 # 监控指标 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # 目标CPU使用率70% # 扩缩容行为配置 behavior: # 扩容行为（增加Pod） scaleUp: policies: - type: Pods value: 2 # 每次最多增加2个Pod periodSeconds: 60 # 每60秒评估一次 - type: Percent value: 100 # 或按百分比扩容 periodSeconds: 60 selectPolicy: Max # 选择更激进的那个策略 stabilizationWindowSeconds: 0 # 无稳定窗口，立即扩容 # 缩容行为（减少Pod） scaleDown: policies: - type: Pods value: 1 # 每次最多减少1个Pod periodSeconds: 300 # 每5分钟评估一次缩容 - type: Percent value: 10 # 或按百分比缩容 periodSeconds: 300 selectPolicy: Max stabilizationWindowSeconds: 300 # 缩容前等待5分钟，避免频繁波动

4.3 HPA配置详解

这个HPA配置有几个关键参数需要理解：

1. 目标CPU使用率：averageUtilization: 70

   • 这是HPA试图维持的平均CPU使用率
   • 当实际使用率高于70%时，HPA会增加Pod数量
   • 当实际使用率低于70%时，HPA会减少Pod数量
   • 70%是一个平衡点，既留有一定缓冲应对突发流量，又不至于过度浪费资源

2. 副本数范围：minReplicas: 2,maxReplicas: 10

   • 最少保持2个Pod，确保高可用性
   • 最多扩展到10个Pod，应对峰值流量
   • 根据业务需求调整，如果预计流量很大，可以设置更高的maxReplicas

3. 扩缩容行为：

   • 扩容更积极：没有稳定窗口，检测到需要扩容时立即执行
   • 缩容更保守：等待5分钟稳定窗口，避免因短暂波动而频繁缩容
   • 策略组合：同时使用Pods和Percent策略，选择更激进的那个

4.4 应用HPA配置

# 应用HPA配置 kubectl apply -f hpa.yaml # 查看HPA状态 kubectl get hpa -n xiakexing-prod # 查看详细HPA信息 kubectl describe hpa xiakexing-hpa -n xiakexing-prod

4.5 验证HPA效果

为了验证HPA是否正常工作，我们可以模拟负载测试：

# 使用kubectl查看实时状态 watch kubectl get hpa,pods -n xiakexing-prod # 使用压力测试工具模拟流量（需要先暴露服务） # 这里假设我们已经通过Ingress或NodePort暴露了服务 # 可以使用hey、ab、wrk等工具进行压力测试 # 示例：使用hey进行简单压力测试 # hey -z 5m -c 50 http://xiakexing.yourdomain.com/process-audio

在压力测试期间，你应该能看到：

1. Pod的CPU使用率上升
2. HPA检测到高CPU使用率
3. Deployment的副本数逐渐增加
4. 压力停止后，CPU使用率下降
5. 经过稳定窗口后，副本数逐渐减少

4.6 基于自定义指标的HPA

除了CPU使用率，我们还可以基于自定义指标进行扩缩容。例如，基于请求队列长度或处理延迟：

# hpa-custom-metrics.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: xiakexing-hpa-custom namespace: xiakexing-prod spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: xiakexing-deployment minReplicas: 2 maxReplicas: 10 metrics: # 基于CPU使用率 - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # 基于内存使用率 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80 # 基于自定义指标（需要先部署Prometheus和Custom Metrics API） # - type: Pods # pods: # metric: # name: requests_per_second # target: # type: AverageValue # averageValue: 100

5. 监控与告警配置

自动扩缩容离不开完善的监控。我们需要知道服务何时扩容、为何扩容，以及当前的健康状态。

5.1 部署监控组件

典型的Kubernetes监控栈包括：

• Prometheus：指标收集和存储
• Grafana：指标可视化
• Alertmanager：告警管理

5.2 配置ServiceMonitor

如果使用Prometheus Operator，可以为“侠客行”创建ServiceMonitor：

# servicemonitor.yaml apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: xiakexing-monitor namespace: xiakexing-prod labels: app: xiakexing release: prometheus spec: selector: matchLabels: app: xiakexing component: web endpoints: - port: http interval: 30s path: /metrics # 假设应用暴露了Prometheus格式的指标

5.3 创建Grafana仪表板

在Grafana中创建监控仪表板，关键指标包括：

• Pod CPU/内存使用率
• 请求处理速率
• 错误率
• Pod副本数变化
• HPA状态

5.4 配置告警规则

在Prometheus中配置告警规则：

# prometheus-rules.yaml apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: xiakexing-alerts namespace: xiakexing-prod spec: groups: - name: xiakexing rules: - alert: HighCPUUsage expr: sum(rate(container_cpu_usage_seconds_total{namespace="xiakexing-prod",container="xiakexing-web"}[5m])) by (pod) > 0.8 for: 5m labels: severity: warning annotations: summary: "高CPU使用率" description: "Pod {{ $labels.pod }}的CPU使用率超过80%持续5分钟" - alert: HPAAtMaxReplicas expr: kube_horizontalpodautoscaler_status_current_replicas{namespace="xiakexing-prod"} == kube_horizontalpodautoscaler_spec_max_replicas{namespace="xiakexing-prod"} for: 10m labels: severity: critical annotations: summary: "HPA达到最大副本数" description: "HPA已达到最大副本数限制，可能需要调整maxReplicas" - alert: PodCrashing expr: rate(kube_pod_container_status_restarts_total{namespace="xiakexing-prod",container="xiakexing-web"}[15m]) > 0 for: 2m labels: severity: critical annotations: summary: "Pod频繁重启" description: "Pod {{ $labels.pod }}在15分钟内重启了{{ $value }}次"

6. 高级优化策略

基本的Kubernetes部署和HPA配置已经能够应对大多数场景，但对于生产环境，我们还可以进行更多优化。

6.1 资源配额管理

为命名空间设置资源配额，防止单个应用占用过多集群资源：

# resourcequota.yaml apiVersion: v1 kind: ResourceQuota metadata: name: xiakexing-quota namespace: xiakexing-prod spec: hard: requests.cpu: "4" requests.memory: 8Gi limits.cpu: "16" limits.memory: 32Gi pods: "20"

6.2 Pod Disruption Budget

配置PDB确保在维护期间至少有一定数量的Pod可用：

# pdb.yaml apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: xiakexing-pdb namespace: xiakexing-prod spec: minAvailable: 1 # 至少保持1个Pod可用 selector: matchLabels: app: xiakexing component: web

6.3 使用Vertical Pod Autoscaler

除了水平扩缩容（增加Pod数量），还可以考虑垂直扩缩容（调整单个Pod的资源限制）：

# vpa.yaml apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: xiakexing-vpa namespace: xiakexing-prod spec: targetRef: apiVersion: "apps/v1" kind: Deployment name: xiakexing-deployment updatePolicy: updateMode: "Auto"

6.4 多集群部署

对于更高可用性要求，可以考虑多集群部署：

# 使用Karmada或Cluster API进行多集群管理 apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: xiakexing-propagation spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: xiakexing-deployment placement: clusterAffinity: clusterNames: - cluster-1 - cluster-2 replicaScheduling: replicaSchedulingType: Divided replicaDivisionPreference: Weighted weightPreference: staticWeightList: - targetCluster: clusterNames: - cluster-1 weight: 60 - targetCluster: clusterNames: - cluster-2 weight: 40

7. 实战演练：应对突发流量

让我们通过一个完整的场景来理解整个系统如何工作。

7.1 正常状态

在正常流量下：

• HPA维持2个Pod副本
• 每个Pod的CPU使用率在30-50%之间
• 服务响应时间在200ms以内

7.2 流量高峰到来

某天上午10点，市场部需要紧急处理1000段音频文件：

1. 大量请求涌入服务
2. Pod的CPU使用率开始上升，达到75%
3. HPA检测到CPU使用率超过目标值（70%）
4. HPA计算需要增加副本数：当前2个Pod，使用率75%，目标70%，需要大约 2 * (75/70) ≈ 2.14 → 向上取整为3个Pod
5. HPA将Deployment的replicas从2改为3
6. Kubernetes调度器创建第3个Pod

7.3 流量持续增长

如果流量继续增长：

1. 3个Pod的CPU使用率仍超过70%
2. HPA继续计算：3 * (80/70) ≈ 3.43 → 4个Pod
3. 增加到4个Pod，使用率下降到65%
4. 系统达到平衡状态

7.4 流量下降

下午3点，处理任务完成：

1. 请求量减少
2. Pod的CPU使用率下降到40%
3. HPA计算：4 * (40/70) ≈ 2.29 → 2个Pod
4. 但是，由于我们设置了300秒的缩容稳定窗口，HPA不会立即缩容
5. 5分钟后，如果使用率仍然低于目标值，HPA将副本数从4减少到3
6. 再过5分钟，如果仍然低于目标值，减少到2个Pod

7.5 系统恢复

最终系统恢复到：

• 2个Pod副本
• CPU使用率稳定在50%左右
• 资源使用效率最大化

8. 总结

通过Kubernetes和HPA的配合，我们为“寻音捉影·侠客行”构建了一个真正具备生产级弹性的部署架构。这个架构的核心优势体现在：

高可用性保障：通过多副本部署和反亲和性调度，即使单个节点或Pod故障，服务也不会中断。健康检查机制确保只有健康的Pod才会接收流量，自动替换故障实例。

智能弹性伸缩：HPA让服务具备了“呼吸”的能力。它像一位经验丰富的武林高手，能够感知到内力的消耗（CPU使用率），并自动调整分身数量（Pod副本）。在流量高峰时召唤更多分身应对挑战，在平静时期则减少分身以节省内力（资源）。

资源利用优化：告别了传统部署中“按峰值配置”的浪费模式。现在我们可以按需使用资源，平时只运行少量实例，遇到高峰时自动扩容。这种模式通常可以节省30-50%的云资源成本。

运维自动化：从部署、更新到扩缩容，整个流程高度自动化。结合CI/CD流水线，我们可以实现从代码提交到生产部署的全自动流程，大大减少了人工干预和出错概率。

监控可视化：通过Prometheus和Grafana，我们能够实时掌握服务的每一个状态指标。无论是CPU使用率、内存消耗、请求延迟还是错误率，都一目了然。当出现异常时，告警系统会第一时间通知运维人员。

部署实践建议：对于刚刚开始Kubernetes之旅的团队，建议从小规模开始，逐步完善。可以先从单节点集群开始，熟悉基本概念和操作。然后逐步引入HPA、监控、日志等组件。最重要的是，一定要在测试环境中充分验证扩缩容策略，确保在真实流量到来时系统能够按预期工作。

“寻音捉影·侠客行”的生产环境部署之旅到此告一段落，但技术的江湖永远在演进。随着业务的发展，我们可能还需要考虑更多高级特性：多集群部署实现跨地域高可用、基于自定义指标的更智能扩缩容、服务网格集成实现更精细的流量管理……

技术的本质是解决问题，而云原生技术栈为我们提供了解决现代应用部署难题的完整工具箱。掌握这些工具，就像武侠世界中修炼内功心法，让你在技术的江湖中游刃有余，从容应对各种挑战。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。