本地DynamoDB配置Kinesis数据流目标报UnknownOperationException排查

项目需通过Kinesis Data Streams捕获DynamoDB表变更事件，本地环境按以下流程操作时触发报错，且因LocalStack内置DynamoDB性能较差，需寻找非LocalStack的替代本地方案：

1. 启动aws-dynamodb-local容器，服务监听8000端口
2. 启动aws-kinesis-local容器，服务监听8001端口
3. 执行命令创建带复合主键的Music表，预置读写容量各5单位，命令指定DynamoDB本地端点
4. 执行命令创建3分片的samplestream Kinesis数据流，指定Kinesis本地端点
5. 执行enable-kinesis-streaming-destination命令尝试将Music表的变更流绑定到本地Kinesis流时，返回如下错误：

An error occurred (UnknownOperationException) when calling the EnableKinesisStreamingDestination operation:

• 官方发布的原生DynamoDB Local仅实现了核心的表CRUD、本地DynamoDB Streams能力，完全没有实现DynamoDB绑定Kinesis流目标的相关管控API，调用不存在的接口时就会直接返回UnknownOperationException。
• 第三方aws-kinesis-local是独立运行的Kinesis协议模拟服务，和本地DynamoDB Local是两个完全隔离的进程，二者没有内置的事件投递联动逻辑，即使接口调通也无法自动完成DynamoDB变更到Kinesis的投递。

方案1：基于DynamoDB Streams做轻量中转（性能最优，推荐） #

完全保留原生DynamoDB Local的高性能，无额外性能损耗，不需要引入重型模拟框架：

1. 为本地DynamoDB表开启原生DynamoDB Streams，配置捕获新旧镜像：

aws dynamodb update-table \
    --table-name Music \
    --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
    --endpoint-url=http://localhost:8000

2. 编写极简的本地消费者程序，监听DynamoDB Streams的分片，拉取到表变更记录后，按照官方DynamoDB发往Kinesis的事件格式做简单转换，主动投递到本地启动的Kinesis流中即可。这段中转逻辑代码量通常不超过100行，无多余依赖，性能和原生集成几乎无差异。

方案2：定制化启动LocalStack兼顾功能和性能 #

如果不想自行编写中转逻辑，可以通过配置让LocalStack复用本地启动的原生DynamoDB Local作为后端，绕开LocalStack内置DynamoDB性能差的问题：

1. 保持原有8000端口的DynamoDB Local、8001端口的Kinesis Local正常运行
2. 启动LocalStack时添加环境变量，关闭无关服务，指定DynamoDB后端指向本地的原生DynamoDB实例，仅加载Kinesis集成相关的管控逻辑即可，此时调用EnableKinesisStreamingDestination接口可正常生效，同时DynamoDB的读写性能和原生Local版本完全一致。

方案3：替换为支持该集成API的轻量AWS模拟工具 #

部分轻量级AWS服务模拟实现单独支持DynamoDB-Kinesis流绑定API，不需要全量启动LocalStack，可自行筛选符合要求的轻量工具，核心校验标准就是确认工具实现了EnableKinesisStreamingDestination相关接口、且DynamoDB模块基于官方DynamoDB Local封装即可。

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