【Serverless实战】云函数打爆RDS连接池？基于 RDS Proxy 与全局复用的工程解法

在云原生架构中，Serverless 的极速弹性是应对秒杀、抢购的利器。但应用层可以无限弹性，底层的关系型数据库（MySQL/PostgreSQL）却极其脆弱。

核心痛点： 当并发请求激增，云平台会在几秒内拉起上千个 Serverless 沙箱容器。如果每个函数的代码都遵循传统思维，在请求到来时执行 DB.Connect()，这成千上万次的 TCP 三次握手与身份校验会瞬间耗尽 RDS 的可用连接数（Too many connections），直接将数据库 CPU 软中断打到 100%。

标准的云原生工程解法是：在基础设施层架设防波堤（数据库代理），并在代码层实现单实例级别的绝对复用。

1. 基础设施层：启用 RDS Proxy（数据库代理）

绝对不要让 Serverless 函数的 VPC IP 直连数据库的物理 IP。必须在云端开启 RDS Proxy 服务。 代理层会在后台与 RDS 始终维持一定数量的常驻长连接（Connection Pooling）。函数端只需要将 DB 地址改为 Proxy 的终端节点（Endpoint）。当海量短连接涌入代理层时，Proxy 会进行请求排队与连接复用（Multiplexing），彻底屏蔽了底层的握手风暴。

2. 代码层：剥离 DB 初始化至全局作用域

即便有了 Proxy，函数代码自身的写法也必须重构。绝对不能在入口函数（Handler）内部初始化数据库连接。必须利用 Serverless 的“实例复用（热启动）”特性，将连接对象挂载到全局作用域：

// Go 语言 Serverless 数据库连接最佳实践
var dbPool *sql.DB // 💡 核心：声明为全局变量

// 初始化函数（仅在冷启动时触发一次）
func init() {
    var err error
    // 连接到 RDS Proxy 端点，而非 RDS 真实地址
    dbPool, err = sql.Open("mysql", "user:pwd@tcp(proxy-endpoint:3306)/dbname")
    // 强制限制单个函数沙箱的最大持有连接数，防止过度占用
    dbPool.SetMaxOpenConns(1)
    dbPool.SetMaxIdleConns(1)
}

// 每次请求的实际处理逻辑
func Handler(request events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
    // 💡 热启动时，直接复用全局 dbPool，不再经历握手开销
    row := dbPool.QueryRow("SELECT status FROM orders WHERE id = ?", request.Body)
    // ...处理逻辑
}

总结： Serverless 赋予了计算层“无服务器”的自由，但下游存储资源依然是“有状态”的物理极限。通过 RDS Proxy 实施流量漏斗，配合全局变量消除冷启动时的 I/O 损耗，我们填平了无状态计算与有状态存储之间的架构鸿沟，保障了数据库在极高并发下的绝对平顺。