跳到主要内容

对Serverless现阶段的看法

1. Serverless有未来吗？​

有，但不多。​

很多云厂商都打着Serverless 巨节省成本的噱头来吸引新用户或者初创企业，但是只要业务量稍微上来那么一点，那么价格就涨的恐怖，比传统vps，ecs的价格都高出不少。 而且使用serverless搭建的那一套服务，没法在其他云服务厂商和本地的Serverless重放，这更是把用户牢牢框在了这个云服务厂商中， 所以整个Serverless云服务厂商的赚钱套路就是使用低价吸引，然后用户搭建自己的Serverless服务，当业务量上来之后开始割韭菜，除非用户再花大精力迁出Serverless

说真的，serverless也只能在云厂商中玩玩，无法自己搭建复制的核心在于各家云厂商没有统一的标准，虽然我知道有 knative 等等，但是实际上各家Serverless实现并不统一，且几乎所有的软件都依赖于一个完整的底层硬件，又或者说是虚拟机环境，而Serverless你怎么挂载数据目录呢？是不是只能依靠云厂商的对象存储呢？好嘛，又能再收你的钱钱。而且Serverless的日志、监控等等都得跟着云服务厂商走，它不提供你也就只能干着急，或者通过接口的方式把Serverless传输出去。除非Serverless先有一个类似docker的runtime在各个电脑都能安装，借助开源生态能够在部分领域有成熟的解决方案，然后再谈serverless降低成本等话题。

更何况Serverless真不便宜。​

云厂商将CPU秒数、内存GB秒等计量单位包装成普惠式按需付费，但是实际函数冷启动的初始化时间单独计费，并发请求触发多个实例时按独立容器重复计费，流量暴增时账单就直接起飞。你无法阻止竞争对手刷你的接口，你也无法阻止真实用户在某天突然暴增，但是你还没有做好收费策略导致入不敷出。

比如下面的案例就屡见不鲜

2. 你以为只有上面说的这些缺点？再说一堆给你听听：​

  • 日志查询、链路追踪等基础运维功能被拆分成附加服务，要么运维失明要么费用起飞之间你二选一
  • 厂商宣传无需关心服务器，但是实际内存-CPU捆绑销售，调整内存配置时CPU配额被强制等比缩放，你要是升级套餐就被迫购买冗余内存
  • 用S3文件上传、DynamoDB流变更等触发器吸引用户，实则将业务逻辑与特定云服务深度耦合
  • IAM权限体系与厂商账户系统无缝焊接，迁移时权限配置需要全盘重构
  • 各厂商对容器预热策略、保活机制都没有明确，只说100ms以内，7-8s之间，那你怎么确定你的下一次函数调用是100ms响应还是10秒冷启动呢？
  • 更何况你的本地环境和生存Serverless环境可不一样，也就注定了可能某些线上故障永远无法在本地复现，那你怎么排查？ok那你说我本地搭建一套knative，那么你都搭建了一套了，维护这套k8s集群是不是也需要专业的运维呢？
  • Serverless要求你把自己的服务变为无状态，然后再用上Redis和DB模拟session会话。哇！真是天才般的发明呢。
  • 15分钟执行上限(没想到吧，还有CPU执行限制时间)，那你就必须将完整逻辑拆解成函数流水线，用分布式事务的复杂度换取基础功能
  • 超过512MB的文件需要连接云存储，把简单文件IO操作变成网络IO，你确定这样的延迟不会更高？

3. 说完了缺点，来说说优点​

PPT融资利器，在BP里写上"全Serverless架构"瞬间科技感拉满，投资人根本看不懂背后的成本黑洞，反正技术债都是下轮接盘侠的事。

4. 后记​

突然翻到自己的以前的笔记就收藏了相关Serverless的内容，可以点击这个链接查看原文：

Serverless Computing: One Step Forward, Two Steps Back

文章的主要内容如下：​

这篇论文《Serverless Computing: One Step Forward, Two Steps Back》由 UC Berkeley 的 Hellerstein 等人发表于 CIDR 2019，系统性地批评了当时主流的 Serverless（主要是 FaaS，如 AWS Lambda）计算平台的局限性。它指出 Serverless 虽然带来了“前进一步”的优势，但也导致了“退后两步”的严重问题。

前进一步：自动扩缩（Autoscaling）​

Serverless（尤其是 FaaS）简化了云端程序部署，开发者只需上传函数代码，平台会在有请求时自动运行。

  • 优点：
    • 按需计费，没有空闲资源浪费。
    • 无需手动管理服务器。
    • 适用于简单的并行任务和事件触发的工作负载。

退后两步：​

    1. 数据处理效率低
    • FaaS 是“搬数据给代码”，不是“把代码发往数据所在地”。
    • 每次函数执行都要从外部拉取数据，严重浪费 I/O 带宽和时间。
    • 网络带宽被分摊，多实例并发时更糟（例如 20 个 Lambda 平均只有 28Mbps 带宽）。
    1. 分布式计算受阻
    • Lambda 之间无法直接通信，只能通过 慢速且昂贵的中介存储系统（如 S3、DynamoDB）传递状态或消息。
    • 无法构建有效的分布式协议（如共识、事务、选主等）——只能做“尴尬并行”。
    • 函数是无状态且短生命周期（如 AWS 15 分钟限制），无法缓存状态或保持连接，严重限制计算模式

作者认为：当前的 Serverless 更像是一种 “锁死开发者的轻量外壳”，更适合调用云厂商自己的服务，而非推动第三方软件创新。

案例分析（Case Studies）​

论文通过三大案例说明问题严重性：

  • 模型训练
    • 使用 Lambda 训练简单神经网络模型比 EC2 慢 21 倍、贵 7 倍。
    • 原因：每次迭代都要从 S3 拉数据，且算力受限
  • 在线推理服务
    • 使用 Lambda + SQS 做文本“脏词”过滤服务。
    • 即便优化过，延迟是 EC2 的 27～127 倍，成本也高得多。
  • 分布式选主协议
    • 使用 Lambda + DynamoDB 实现 Bully Leader Election。
    • 每轮选主要 16.7 秒，支持 1000 节点每小时要 $450，仅用于通信。

这篇论文的核心结论是：​

Serverless（尤其是 FaaS）虽然简化了云上应用开发，但它目前的设计反而 限制了复杂数据处理、分布式系统构建和开源创新，违背了云计算“无限资源、无限创新”的初衷。

如果你希望 Serverless 只是运行少量业务逻辑调用某些云服务，那它是够用的；但如果你想构建一个数据密集、性能敏感或新型计算模型的服务，它远远不够。