用 AWS 事件驱动架构编排大规模本地基础设施

2026-09-01 42 预计阅读时间: 1 分钟
来源: aws.amazon.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：13 分钟

当企业拥有数百个门店、工厂或分支机构时，本地服务器和 Kubernetes 集群的生命周期管理很容易变成一组分散的人工流程：设备上线靠工单，集群升级靠远程登录，失败重试靠值班人员。混合云编排的关键，不是把所有工作负载搬到公有云，而是建立一个运行在 AWS 上的统一控制面，用事件驱动的方式管理分布在各站点的基础设施。

一种可行的实现方式是组合使用 AWS 无服务器服务与 Amazon EKS Anywhere：AWS 负责接收请求、保存期望状态、调度任务和记录结果；站点侧负责执行具体的服务器操作与集群变更。这样可以把控制逻辑集中起来，同时保留本地环境对低延迟、数据驻留和断网运行的支持。

从期望状态开始设计

大规模编排最重要的抽象是期望状态，而不是一次性的远程命令。控制面可以保存类似下面的对象：

{
  "siteId": "store-042",
  "clusterName": "edge-prod",
  "desiredVersion": "1.29.3",
  "action": "upgrade-cluster",
  "requestId": "req-20250308-001",
  "submittedAt": "2025-03-08T10:00:00Z"
}

站点代理或管理服务持续把实际状态上报到 AWS。编排系统比较期望状态和实际状态，只有在两者不一致时才投递任务。这个模型带来几个直接收益：

  • 幂等性：重复收到同一个事件不会重复执行危险操作。
  • 可恢复性：任务失败后可以基于状态重试，而不是依赖操作者记住执行到哪一步。
  • 审计性：每次服务器替换、集群升级和配置变更都有请求 ID 与结果记录。
  • 扩展性：新增站点主要是注册资源和部署站点侧组件，不需要在控制面增加一套专用流程。

DynamoDB 可以保存站点、集群和任务状态；Amazon EventBridge 负责分发领域事件；AWS Step Functions 适合编排有明确步骤和超时边界的流程；Lambda 则执行轻量的状态转换、校验和任务投递。对于持续时间较长的操作，不应让 Lambda 一直等待，可以将任务放入 Amazon SQS，由站点代理异步领取并回报结果。

一次服务器或集群变更的事件流

以集群升级为例，流程可以拆成以下事件：

  1. 运维系统通过 API Gateway 提交升级请求。
  2. Lambda 校验站点是否已注册、目标版本是否在允许范围内，并写入 DynamoDB。
  3. Lambda 向 EventBridge 发布 ClusterUpgradeRequested 事件。
  4. Step Functions 为任务生成状态机执行，检查站点连接状态和当前集群版本。
  5. 任务被发送到对应站点的 SQS 队列，站点代理领取后调用 EKS Anywhere 的本地管理流程。
  6. 代理发布 ClusterUpgradeProgress 或 ClusterUpgradeFailed 事件。
  7. 控制面更新任务状态；失败时根据错误类型决定重试、暂停或转人工处理。

EventBridge 事件可以按站点、环境和动作类型路由。例如，下面的规则只匹配生产环境的集群升级请求：

{
  "source": ["edge.orchestrator"],
  "detail-type": ["ClusterUpgradeRequested"],
  "detail": {
    "environment": ["production"],
    "action": ["upgrade-cluster"]
  }
}

这里的事件只描述业务事实，不携带大量执行细节。大型配置和敏感数据应存放在 S3、DynamoDB 或 AWS Secrets Manager 中，事件中只保留资源 ID、版本和请求 ID。这样能降低事件大小，也避免把凭据传播到多个消费者。

让站点侧成为可靠执行器

AWS 控制面不应该假设每个站点始终在线。门店网络可能暂时中断，工厂环境可能有严格的维护窗口，服务器也可能在升级过程中重启。因此，站点代理需要具备以下行为：

  • 使用短轮询或长轮询从站点专属队列领取任务。
  • 为每个任务保存本地执行记录，避免代理重启后重复执行不可重入步骤。
  • 对请求设置过期时间和目标版本检查。
  • 先回报 started，再按阶段回报进度，完成后回报 succeeded 或 failed。
  • 断网期间保留本地状态，网络恢复后补发结果。
  • 只允许执行白名单动作，例如开机、关机、替换节点、升级集群，不接受任意 shell 字符串。

Amazon EKS Anywhere 负责在客户管理的硬件或虚拟化环境中运行 Kubernetes。编排系统可以把它当作站点侧集群生命周期的一部分：控制面下达目标版本和变更意图，站点侧执行具体的集群操作，并把结果作为事件返回。具体的供应商硬件、网络拓扑和 EKS Anywhere 配置需要根据现场环境适配，不能简单假设所有站点都拥有相同的节点规格。

一个可改造的最小事件入口

下面是一个可以直接放入 Lambda 的 Python 示例。它演示如何校验升级请求、写入 DynamoDB，并发布 EventBridge 事件。运行前需要把环境变量 TABLE_NAME 和 EVENT_BUS_NAME 配置为实际资源名，同时为 Lambda 授予 DynamoDB 写入和 EventBridge PutEvents 权限。

import os
import uuid
from datetime import datetime, timezone

import boto3


dynamodb = boto3.resource("dynamodb")
events = boto3.client("events")
table = dynamodb.Table(os.environ["TABLE_NAME"])
event_bus_name = os.environ.get("EVENT_BUS_NAME", "default")


def handler(event, context):
    detail = event.get("detail", event)
    site_id = detail.get("siteId")
    cluster_name = detail.get("clusterName")
    desired_version = detail.get("desiredVersion")

    if not all([site_id, cluster_name, desired_version]):
        return {"statusCode": 400, "body": "siteId, clusterName and desiredVersion are required"}

    request_id = detail.get("requestId", str(uuid.uuid4()))
    now = datetime.now(timezone.utc).isoformat()

    # 生产环境还应校验站点注册状态、版本白名单和维护窗口。
    table.put_item(
        Item={
            "pk": f"SITE#{site_id}",
            "sk": f"TASK#{request_id}",
            "requestId": request_id,
            "clusterName": cluster_name,
            "desiredVersion": desired_version,
            "status": "REQUESTED",
            "createdAt": now,
        },
        ConditionExpression="attribute_not_exists(pk)",
    )

    events.put_events(
        Entries=[
            {
                "EventBusName": event_bus_name,
                "Source": "edge.orchestrator",
                "DetailType": "ClusterUpgradeRequested",
                "Detail": (
                    '{"siteId":"%s","clusterName":"%s",'
                    '"desiredVersion":"%s","requestId":"%s",'
                    '"environment":"production"}'
                    % (site_id, cluster_name, desired_version, request_id)
                ),
            }
        ]
    )

    return {"statusCode": 202, "body": request_id}

这个示例刻意保持简单。正式实现应使用安全的 JSON 序列化方式，而不是字符串格式化；还应增加版本格式校验、站点授权、事件失败处理和结构化日志。DynamoDB 的条件写入用于阻止相同任务 ID 被重复创建，但它不能替代整个工作流的幂等设计。站点代理、队列消费者和状态回报接口都需要分别处理重复消息。

可以用 AWS CLI 构造一条测试事件：

aws events put-events --entries '[
  {
    "Source": "edge.orchestrator",
    "DetailType": "ClusterUpgradeRequested",
    "Detail": "{\"siteId\":\"store-042\",\"clusterName\":\"edge-prod\",\"desiredVersion\":\"1.29.3\",\"environment\":\"production\",\"requestId\":\"demo-001\"}",
    "EventBusName": "default"
  }
]'

面向数百站点的工程边界

事件驱动并不等于自动解决所有规模问题。部署前需要明确几个边界：

  • 并发控制：同一站点通常只能同时进行一个节点级变更；可以在 DynamoDB 中维护租约，或为站点配置独立队列。
  • 重试策略：网络超时适合指数退避，版本不兼容则应立即暂停，不应无限重试。
  • 死信处理：SQS 和 EventBridge 消费失败都应有死信队列、告警和人工重放机制。
  • 权限隔离：不同站点使用不同的身份和最小权限策略，避免一个站点凭据影响其他站点。
  • 维护窗口：升级、重启和节点替换必须支持站点级维护窗口，不能只依赖全局计划任务。
  • 观测能力：至少记录 request ID、site ID、cluster name、当前阶段、重试次数和最终错误原因。
  • 断网策略：定义任务在本地缓存多久、哪些任务允许离线执行，以及过期任务如何取消。

一个实用的落地顺序是：先选择少量非关键站点，打通站点注册、状态上报、单一变更动作和失败重试；再增加 Step Functions 的多阶段编排与批量发布。不要一开始就把服务器置换、操作系统升级和 Kubernetes 版本升级塞进同一个不可观测的脚本。

采用前的检查清单

混合云编排系统是否可靠，取决于它能否在异常环境下保持可解释和可恢复。上线前至少确认：

  • 每个变更都有唯一请求 ID 和明确的期望状态。
  • 重复事件不会导致重复的破坏性操作。
  • 站点离线、代理重启和任务超时都有处理路径。
  • 生产变更支持暂停、审批、回滚或人工接管。
  • AWS 控制面和站点执行器之间只交换必要信息。
  • EKS Anywhere 的版本、硬件、网络和维护窗口已按站点验证。

把 AWS 无服务器服务用于控制面，把 EKS Anywhere 和站点代理用于执行面，可以形成清晰的职责边界。控制面负责规模化调度和状态管理，站点侧负责面对真实硬件与网络条件。这个边界越明确，系统越容易从几十个站点扩展到数百个站点，也越容易在故障发生时找到真正需要修复的位置。

# AWS # 云平台 # 后端 # 架构设计

相关推荐