你的 Serverless 在扩展性方面正在误导你

Serverless 计算承诺了无限的扩展能力和零运维开销。像 AWS Lambda 或 Google Cloud Run 这样的平台可以瞬间扩展你的计算层。

但你的后端仍然会崩溃。

问题不在于你的计算层，而在于你的数据库。

当你的函数进行扩容时，它们会引发“连接风暴”（connection storm）。每一个新的函数实例都会尝试向你的数据库建立一个新的连接。如果你有 1,000 个函数，就会有 1,000 个连接请求同时涌向你的 Postgres 或 MySQL 实例。

关系型数据库有硬性限制。一旦达到该限制，新的连接就会失败。这会导致高延迟和 5xx 错误。你的计算层已经准备就绪，但你的数据库却不堪重负。

你可以通过以下三种策略来解决这个问题：

  1. 使用连接代理 (Connection Proxy) 不要让函数直接连接到你的数据库。使用像 AWS RDS Proxy 或 Google Cloud SQL Proxy 这样的代理。这一层位于你的函数和数据库之间。它管理着一个较小的持久连接池，并在众多函数之间共享这些连接。

  2. 实现数据代理层 (Data Proxy Layers) 高级代理不仅仅是管理连接。它们还可以：

  • 将读写操作分离到不同的数据库实例中。
  • 缓存频繁查询以减轻数据库负载。
  • 在查询到达数据库之前对其进行优化。
  1. 转向异步写入 (Asynchronous Writes) 停止让每一个用户操作都变成同步的数据库写入。许多任务并不需要即时的一致性。

与其这样做： 用户操作 -> 函数 -> 同步数据库写入 -> 响应

不如这样做： 用户操作 -> 函数 -> 将事件推送到队列 -> 快速响应

随后，一个独立的函数可以获取该事件并在稍后将其写入数据库。这可以保护你的数据库免受突发流量峰值的冲击。

真正的可扩展性不仅仅是扩展计算能力。你必须针对弹性数据访问进行设计。不要再为了理论上的最大值进行资源配置。开始在爆发式增长的函数与你的数据之间建立缓冲。

来源：https://dev.to/prabashanadev/your-serverless-is-lying-to-you-about-scale-4cga