Amazon RDS SQL Server表触发器调用外部Endpoint，求更优雅替代方案

我之前在处理RDS SQL Server的类似需求时，也踩过sp_OAxx不能用的坑，你现在用S3中转的方式确实能解决问题，但确实不够优雅。这里分享几个更直接的方案，你可以根据自己的场景选择：

方案1：利用CLR集成调用HTTP端点 #

Amazon RDS SQL Server支持启用CLR集成，你可以写一个自定义的CLR存储过程来调用外部HTTP端点，然后在触发器里调用这个存储过程。步骤大概是：

1. 先在RDS参数组里开启CLR支持，然后执行SQL启用CLR：

   sp_configure 'show advanced options', 1;
   RECONFIGURE;
   sp_configure 'clr enabled', 1;
   RECONFIGURE;
   

   注意：默认RDS不允许EXTERNAL_ACCESS或UNSAFE权限的程序集，你需要通过AWS Support申请权限，因为SAFE权限下无法调用外部HTTP服务。
2. 用C#写一个简单的类，包含调用HTTP端点的方法，比如：

   using System.Net;
   using System.Data.SqlTypes;
   using Microsoft.SqlServer.Server;
   
   public class HttpCaller
   {
       [SqlFunction(DataAccess = DataAccessKind.None)]
       public static SqlString CallEndpoint(SqlString url)
       {
           using (WebClient client = new WebClient())
           {
               return client.DownloadString(url.Value);
           }
       }
   }
   

3. 编译成DLL，部署到RDS的SQL Server中，创建对应的存储过程或函数，最后在触发器里调用这个函数即可。

这个方案的好处是触发器直接触发调用，流程最短，但需要处理CLR的权限配置，后续维护DLL也需要注意版本管理。

方案2：CDC + Kinesis Data Streams + Lambda（推荐） #

这是更现代化的事件驱动方案，完全解耦数据库和外部服务：

1. 启用RDS SQL Server的Change Data Capture（CDC）功能，捕获目标表的所有变更（插入、更新、删除）。
2. 使用AWS DMS或者自定义作业，把CDC捕获的变更数据同步到Kinesis Data Streams中。
3. 创建Lambda函数，订阅这个Kinesis流，每当有新的变更记录流入，Lambda就调用你的指定Endpoint。
4. 可以在Lambda里配置重试机制、错误处理，比如调用失败时自动重试，或者把失败消息放到死信队列里。

这个方案的优势非常明显：

• 完全解耦，数据库触发器不需要关心外部服务的调用逻辑，只负责生成变更事件。
• 容错性强，Lambda的重试和死信队列机制可以处理Endpoint调用失败的情况。
• 扩展性好，如果后续需要处理更多业务逻辑，只需要修改Lambda函数即可，不需要改动数据库。

方案3：SNS主题中转 #

如果你的需求比较简单，只是需要在数据变更时通知外部Endpoint，可以用SNS作为中转：

1. 先创建一个SNS主题，把你的Endpoint作为HTTP/S订阅者添加到主题中（SNS会自动处理Endpoint的订阅确认和重试）。
2. 同样通过CLR存储过程，在触发器里调用SNS的API，把变更消息发送到SNS主题。
3. SNS会自动把消息推送到你的Endpoint。

这个方案的好处是利用SNS成熟的通知机制，不需要自己处理重试和Endpoint管理，适合简单的通知场景。

对比你现在的S3方案：S3中转的方式虽然可行，但每次变更都要写文件到S3，会产生额外的存储和API调用开销，而且延迟可能比上述方案高。如果追求优雅和高效，方案2是最佳选择。

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