自主机器上行数据报文管理分发架构方案及相关问题咨询

1. 架构长期可持续性判断 #

这个架构在你当前的设备规模下（1000台设备、每5秒1KB报文）完全可以稳定运行，长期可持续性取决于你未来的业务扩张节奏：

• 若未来3年设备规模不会超过5万台、对接的业务服务数量不超过10个，该架构可以长期使用，无需做大的改动
• 需提前规避两个长期风险点：
  • 若下游消费DynamoDB采用自行轮询扫表的逻辑，设备规模上涨到万台级别时容易出现漏读、重复读问题，建议后续替换为DynamoDB Stream触发消费逻辑会更稳定
  • PostgreSQL单表的service_N_forwarded字段会随业务服务增加持续膨胀，后续可以考虑拆分独立的转发状态元数据表，或者引入轻量消息队列承接路由分发逻辑

2. DynamoDB PK/SK优化方案 #

你当前的PK设为machine-sn、SK设为priority-timestamp-packetid的设计已经能满足按设备维度、优先级顺序拉取报文的核心需求，可根据实际业务场景选择性优化：

• 若存在全局拉取所有设备高优先级报文的需求，可以新增一个GSI（全局二级索引），GSI的PK设为priority、SK设为timestamp-packetid，拉取0级高优报文时可直接查询GSI，无需遍历所有设备的PK
• 若设备重试会发送重复报文，可以将packet-id提到SK的更靠前位置，或者新增unique(packet-id, machine-sn)的写入约束，避免重复数据写入

3. 初期自行实现逻辑而不使用AWS IoT服务的合理性判断 #

完全合理。AWS IoT Core虽提供完整的IoT能力，但初期学习成本高，还需要适配设备侧的鉴权、协议逻辑，很多功能你现阶段并不需要。自行实现的逻辑链路短，出问题排查成本低，初期落地速度更快。等后续设备规模上涨、产生明确的IoT专属功能需求（比如设备影子、规则引擎、原生MQTT协议支持）时再迁移也完全来得及，不会产生过多的改造成本。

4. Lambda限制仅VPN内请求准入的实现方式 #

可以实现。操作路径如下：

• 将Lambda部署到VPC的私有子网内，打通VPN接入网段和VPC的网络连通
• 配置Lambda的资源访问策略，仅允许VPN所属的CIDR段的请求触发Lambda
• 若你用API网关承接设备请求的话，额外给API网关配置VPC端点，限制仅VPC内请求可访问，彻底关闭公网访问入口，即可保证只有VPN内的设备可调用相关接口。

内容的提问来源于stack exchange，提问作者Jogrey