编者荐语：
令辉从理论上证明了无服务器更划算，不仅在总体拥有成本上划算，在Infra账单上也直接划算。他的论证基于一个判断：“大部分公司的峰值负载持续时间仅仅是几分钟最多不会超过一小时”， 这个前提是否成立，还请各位读者补充或者反驳。
以下文章来源于ClapDB ，作者李令辉
当今业界无论是 internet 还是 intranet，即使没有任何负载，99.99% 的服务也都以服务的形式跑在服务器上。相比于浪费，带来的体验和稳定性的提升几乎可以忽略不计。
在之前的文章 名为“原生”，实则“排异”——有状态服务请对云原生say no和云是一台新电脑里，我们反复提到云的优势在于弹性，而云的弹性的最佳体现就是 serverless function。我们下面就聊聊为什么用 serverless 技术栈可以大幅度降低浪费，减少复杂度。
1.业务波动的挑战
业务波峰波谷的必然性
几乎所有的业务都有波峰波谷。下图展示了一个互联网业务一天内的 PV 变化情况，从中可以看出，业务的波峰接近波谷的 10 倍。如果按照波峰来做容量规划，将会浪费大量资源。
更精细时间轴上的波动
放大上述图的一部分，只看30分钟的数据，即使将时间段缩小到分钟级，workload也不是平稳的。
唯一不变的就是变化，随着 Page View 的上蹿下跳，业务对资源的实际需求也上天入地，请问为了峰值规划的计算资源有多少时间能派上用场呢？
Serverless 的成本优势
先直观的比较一下两者的成本
AWS Lambda 与 AWS EC2 成本对比
以 AWS Mumbai Region 的价格表为准，下面是 x64 架构的 Lambda 和 EC2 价格：
| 资源 | Lambda | C5.4xlarge EC2 |
| CPU | 2vCPU | 16vCPU |
| 使用目的 | 2G | 32GiB |
| 储存 | 512M | 0 |
| 网络 | 0.6Gbps | 10Gbps |
| 价格 | 0.0000000333 USD/ms | 0.68 USD/h |
我们用内存作为锚点, 用 16 个 Lambda 实例来对标 EC2，在 lambda 的 CPU 数量多一倍的情况下，双方成本比为 2.82 倍（RI 会严重影响云计算的弹性，因此不在本文讨论范围内）。从上面的表格我们可以看出，只要服务活跃时间少于 8.5 小时，使用 Serverless 架构的成本更低。大部分公司的峰值负载持续时间仅仅是几分钟最多不会超过一小时，而对于很多 To B 业务来说，非工作时间甚至只有个位数的访问 QPS。所以如果完全使用 serverless 技术栈，你的账单可能会被脚踝斩。
Serverless 与 Service 的运维成本
Service 的运维成本
过去 20 年，为了维护一套可靠的在线集群，需要做大量工作：
•容量规划
•服务的安装和部署
•服务性能监控
•配置管理
•CI/CD 和 灰度发布管道的维护
•容灾备份和冗余管理
Serverless 的运维成本
只需管理配置，对函数性能日志进行监控即可。Serverless 没有服务，只要启动速度可接受，且能够保证资源池够用即可。CI/CD 就是部署新版本程序，可以在 LB 或 Gateway 层做流量切分，比服务简单。而且 Serverless 函数在物理上完全与其他函数的计算资源隔离，容量规划和性能监控都更容易。
Serverless 天生无状态，减少了状态检查、版本管理和状态一致性的相关负担。对于运维工作来说，只需复制数据，连跨区多活也变成了保证数据多区多备份的工作而已。
Serverless 与 Service 的开发成本
Service 开发的复杂性
基于微服务的开发工作一般会处理以下问题：
•需要 mock 所有依赖的服务
•服务间存在版本依赖，旧接口可能永远无法下线
•服务间的网络通信成本可能会因网络质量下滑而被放大
•因为服务间跨网络，事务难以保证，服务 API 必须实现幂等
•业务问题的跨服务调试缺乏全链路视角，只能在各应用中调试或依赖全局 log 追踪和监控系统
•每个服务即使是 pod 也要服务多个业务请求，日志和监控可能暴露多个用户的敏感信息
Serverless 开发的简化
•无需 mock 服务，只需用生产环境同样的代码，可以直接用线上数据或 mock 一份数据
•Serverless 函数可以同时发布多个版本，旧版本不占用任何运行资源，是否下线只取决于管理目的
•Serverless 受网络性能影响较小，因为函数间互相调用会遭遇 cold start 惩罚，通常将它们编译到一个函数中
•任何跨网络调用都要支持幂等，但通常一个请求跨多个函数没有必要
•大部分调用在一个函数内一次完成，log 中能找到所需信息
•每个函数在一次触发过程中仅服务同一个 query，日志和 metrics 信息都是关于同一个请求，限制调试范围可避免信息泄露
Serverless 没有解决的问题
Serverless 代码与 Service 类似，代码错误、逻辑错误、死循环、循环依赖等问题依然存在。
Serverless 有所改善的问题
Service 遇到资源泄露会影响所有请求，而 Serverless 每次请求仅处理一次 query，隔离于其他 query，缓缓泄露的问题不会快速造成剧烈影响，可通过重启函数容忍。
Serverless 带来的新问题
•冷启动问题
•单个 Serverless 函数资源有限，不适合处理大资源问题，需要重新设计代码将任务分给更多函数运行
•微服务设计准则不适用于 Serverless，状态要外置，跨服务调用不适合，Serverless 希望尽量在一个函数内解决业务需求
•Lambda 按内存占用和运行时间计费，不要占用无用内存，启动慢且占用大量内存的 runtime 不适合 Serverless，但减少运行时间提高用户体验
复杂度的转移
无论用什么技术栈，业务本身的复杂度都不会消失。但是任何技术栈都不可避免的携带着复杂度，服务化技术栈在过去的 20 年里存在大量本身的限制带来的复杂度，而这些复杂度都会随着使用 serverless 而烟消云散，serverless 作为一个技术栈当然会带来新的复杂度，但目前看因为其天生的无状态限制，可以让开发者从主观上避免动用所有关于状态管理和维护的一系列奇技淫巧。从我们的实践来看，复杂度得到了有效控制。
未来展望
Serverless 具有云计算最大优势，最灵活的弹性，但不能直接搬运旧代码使用。但因其天然优势，成为众多厂商持续投入的领域，未来可期。
Serverless 技术栈现状
Serverless 虽是多家云厂商重注押宝的技术方向，但用户代码大量存在于传统架构上，迁移到 Serverless 架构成本较高。前端技术栈已有 vercel、cloudflare 等厂商提供 Serverless 基础设施，其他技术栈每个云厂商都有自己的产品。冷启动最快的产品是 AWS lambda，其他厂商需继续努力。
Serverless 并不是免费午餐
和多核 CPU 的出现类似，不改变架构和编码方式，软件无法直接利用 Serverless 基础设施的好处。如何节省内存、状态外置、缩短执行时间与过去架构不一致，但与在 NUMA 架构服务器上设计软件相似。详情将在本系列后文中陆续说明，敬请期待。
结语
Serverless 技术不止可以做网站，还可以打造复杂的基础软件，我司的核心产品 ClapDB 完全基于 Serverless 技术打造，在没有查询和写入的时候，它不会产生任何除对象存储以外的费用。
References
[1] 名为“原生”，实则“排异”——有状态服务请对云原生say no: https://clapdb.cn/blog/2024-06-03-stateful-service-should-say-no-to-cloud-native/
[2] 云是一台新电脑: https://clapdb.cn/blog/2024-06-27-cloud-is-the-new-cloud/
[3] ClapDB 国内: https://clapdb.cn
[4] ClapDB 全球: https://clapdb.com
[5] ClapDB 上手指南: https://clapdb.com/docs/
