随着阿里云、腾讯云 2019 年收入状况相继披露，中国云计算双寡头的格局基本确立。
但这种格局只是建立在当前的技术背景之上，新的云计算架构理念—— Serverless 正在全球范围内铺开，行业在迎来新的竞争变局。
Serverless 直译为 " 无服务器 "，是一套架构体系，包括网络层、计算层和数据存储层等，国际范围内最先由 AWS 2014 年推出的 Lambda 开始。
它并不是指不需要服务器，而是计算资源作为 " 服务 " 而不是 " 服务器 " 的概念出现，可以近似理解为，云计算的计算资源变成一个池子，开发者们从中索取一份一份的 " 服务 "，其结果，是开发人员不需要过多考虑服务器维护等问题。
2017 年，全球云计算厂商争相推出 Serverless 服务框架，近两年由于 IoT、边缘计算、混合云、5G 等概念的兴起，Serverless 成了云计算架构里的 " 当红炸子鸡 "，全新的架构理念直接影响了开发者的选择。
在这种情况下，云计算巨头在特定层面的 " 抢跑 " 就不意外了。
例如，腾讯云最近在线发布了 Serverless 数据库 PostgreSQL for Serverless，这是国内第一次出现 Serverless 数据库（DB）。而腾讯云这个动作，不仅是数据层的 Serverless 抢跑，也给云计算行业的 Serverless 迭代加了一把火，一场架构层面的 " 代差优势 " 争抢已经开始。
01
揭开传统云数据库的隐藏痛点，就看懂了 Serverless 浪潮的直接动因
腾讯云官宣为自家的 PostgreSQL for Serverless 设定了很多优势，而其实这些优势说到底都来源于行业层面 Serverless DB 对传统云服务架构下数据库的优势。
理解了传统云数据库的 " 隐藏痛点 "，就理解了为什么 Serverless 浪潮在全球云计算领域兴起，为什么腾讯云此时要抢跑 Serverless DB 推出独立的产品。
1、" 按需分配 " 是再合理不过的诉求，但技术却长期不能支撑
在非专业人士的直觉里，云计算的数据库最好是能够是实现 " 按需分配 "，在享受云服务的时候，要多少就分配给多少，用户峰值来了就增加（" 扩容 "），峰值过去就减少（" 缩容 "），这样，" 租用 " 就不会浪费。
而现实是残酷的，由于服务 " 颗粒度 " 等原因，供给与需求的贴合往往很难，很多云数据库的服务只能是阶梯式的手动扩容或缩容，而且开发者为了保证用户体验，不管什么 " 档位 " 的服务都必须以最高预测的负载为准申请服务。
而 Serverless DB 的扩缩容过程如同海绵，在请求增长时自动扩容，在请求降低时自动缩容，如图：（来源：腾讯云发布）
可以看到，Serverless DB 已经无限接近 " 按需分配 "，云计算平台的服务资源闲置，开发者的资源浪费问题都得到最大可能的解决，由于可以实现自动平滑配置而不需要人工操作，扩缩容的效率也得到很大提升。
2、成本 " 不应有的浪费 " 却被行业长期默认
接上文，在传统云数据库架构下，粗糙的阶梯式扩 / 缩容造成浪费，其后果还直接体现在成本上——那些被闲置但在旧有条件下为了用户体验避免不了的数据库空间，开发者都是要掏钱的，这情况被长期默认。
腾讯云说自己的 Serverless DB 产品 PostgreSQL for Serverless 能帮助开发者降低 70% 成本，操作方式是 " 按量付费 " ——用户不需要为数据库的闲时进行付费，而是按照数据库资源响应单元来进行计费。
这一数据是否准确暂且不论，Serverless DB 的省成本能力确实可观。
从实例来看，这是一个游戏应用 2019 年三种数据库扩 / 缩容方案所占用的资源情况：
三种颜色线条中间区域的面积，基本可以看作成本的差别状况，很明显，Serverless DB 能节约大量的成本，腾讯云说自己的产品节约最高 70% 并非吹嘘。
3、所谓 " 弹性方案 "，其高门槛将很多开发者拒之门外
如果打开很多云计算的数据库功能介绍，往往会发现诸如 " 弹性扩展 " 等字眼，表示自己的服务可以较为自由地收缩，作为产品亮点进行宣传。
事实上，这类 " 弹性方案 " 本质上是一种策略上的弹性而非技术上的弹性，即开发者需要实现预估自己的产品的负载量，例如一款游戏什么阶段玩家特别多，什么时候人潮回落，设定好数据库需求的方案，对应进行手动的容量调整。
预估得越精细，这种 " 弹性 " 就越接近 " 按需分配 "，显然，这是一件门槛很高的事，多数开发者都很难准确预览负载，手动的调控也很难把握。
腾讯云说 PostgreSQL for Serverless 的用户在购买之后只需要通过组件一键创建数据库实例，" 最快 1 秒钟就可以完成部署 "，这种傻瓜式的部署同样来源于 Serverless DB 的智能化 " 膨胀 " 和 " 缩小 " 能力，开发者能藉此有更灵活的业务开发模式和更快捷的上云体验。
也即，Serverless DB 可看作天然的、精确的、不需要人为干预的 " 弹性方案 "。
02
巨头抢跑 Serverless DB，要的不只是 " 解决痛点 "？
由于无可比拟的架构优势，通过 Serverless DB 产品解决痛点会给云计算巨头带来直接的用户增量，但腾讯云抢跑，应该还有更多深度价值考虑。
1、界面清晰化，回归 To B 服务的底层价值
Serverless 技术给云计算带来的改变是革命性的。
由于封装了几乎全部的底层资源和系统运维工作，等于给开发人员搞了一个 " 云基础设施 " 包拿来就用，云服务的编程被极大简化，业内普遍认为 Serverless 是继虚拟化、容器技术之后的第三代通用计算平台。
回到腾讯云业务上，作为腾讯 To B 战略的主要承载平台，腾讯云选择 Serverless 技术既是云计算竞争的需求，也是 To B 服务回归底层价值的必要——把所有基础服务一揽子完成，开发者只需要专注于业务本身进行创新探索。
或者说，这只是腾讯在 To B 过程中一贯放低姿态做纯粹的赋能的一种延续。
2、" 全栈化 " 下，提供 Serverless 闭环服务
在疫情期间，很多腾讯云服务的企业都 " 从零起步 " 相继推出自己的抗疫 APP，包括国内疫情概览、公司员工健康状况实时显示、外来人员进出登记等功能，建立全过程都在腾讯云上完成。
行话叫 " 全栈解决方案 " ——云计算平台什么都有，开发者可以只在单一平台上完成产品的搭建，而腾讯云的全栈架构目标恰恰也是 Serverless。
在过去，腾讯云已经完成了网络层、计算层的 Serverless 化服务（原理类似，网关的弹性、计算的高可用高并发等），此次 PostgreSQL for Serverless 补足了 Serverless DB 最后一个环节，意味着腾讯云完成 Serverless 生态布局，在这之后，用户能够基于全栈 Serverless 解决方案构筑云原生应用。
如此，腾讯云不但抢跑 Serverless DB，也通过 Serverless 闭环服务来占据竞争优势。
3、解救 " 小众 " 开发需求，渗透 " 厚尾市场 "
有一类 " 低流量用户 " 的开发者在数据库方面的需求很尴尬，由于用户数量低且稳定，在传统数据库模式下，它可能连最低配置的单元都没办法 " 用满 "（涉及传统数据库架构的颗粒度问题），会有浪费，但还是要为多余的性能进行付费。
Serverless DB 满足了这种 " 尴尬但广泛存在 " 的低流量产品需求，腾讯云的 PostgreSQL for Serverless 理论上可以接受接近于零的费用支出。
事实上，除了低流量，还有很多数据需求方面奇葩的产品，例如不可预测的工作负载、不常用的应用程序以及开发和测试数据库（断崖式上升、下跌，或者不连续跳跃）等，它们共同构成了开发者生态长期没有被照顾到的 " 厚尾市场 "，由于特异性的需求，几乎都会倾向于选择 PostgreSQL for Serverless 这样的 Serverless DB 产品。
4、以价换量打响另类 " 价格战 "
无法否认，云计算在激烈的圈地过程中，少不了价格战的存在，只不过不像消费品那么惹人关注。
价格战的本质是 " 以价换量 "，同样的服务通过降价竞争，从长期来看是对行业的损害。
而 Serverless DB 通过节约用户成本的方式吸引更多客户 " 以价换量 "，客观上也开启了新的 " 价格战 "，只不过它不再是以牺牲平台营收、扼杀创新积极性为代价，技术的换代的结果是平台与开发者的双赢，价格的大幅度降低来源于浪费的减少。
可以想见的是，通过较低的价格，腾讯云 PostgreSQL for Serverless 能够锁住老客户，而吸引更多因为成本因素而入驻的开发者，带来类似价格战一样的市场竞争效果，但是，这在根本上是抢跑 Serverless DB 的 " 代差优势 " 所带来，是一种升维打击的竞争结果。
03
" 代差优势 " 旗帜下，Serverless 下一步会怎么走？
从单个案例看，PostgreSQL for Serverless 后，腾讯云完成了 Serverless 的全栈闭环，但这种闭环，实际仍然不够完善。
PostgreSQL 只是数据库的一种形式，按照腾讯云在线发布会上的说法，未来还将部署 MySQL 等数据形态。
不难看出，在 " 推盘节奏 " 上，腾讯云是有小算盘的，其他相对优缺点暂且不论，由于 PostgreSQL 代码相对于 MySQL 更加容易开发，做 PostgreSQL 版本的 Serverless DB，能够在低成本、易扩容等优点基础上，兼顾高可用、高性能、高安全等特性，更容易 " 一炮打红 "。
对腾讯云来说，不同类型的数据库的补齐和完善将是下一步的动作。
另一方面，从落地节奏来看，按内部人士的说法，腾讯云 Serverless 原本服务于腾讯内部的众多核心应用，随着开发者生态以及开源生态的不断完善，这些 Serverless 能力开始对用户开放。
这意味着，在 Serverless 架构这件事上，腾讯云基本遵循先内后外的节奏，一站式的开发、部署、运维服务的不断完善将首先以自家业务进行试水。
当然，既然能给开发者节省成本、提高效率，Serverless 也就同样能帮助体量庞大的腾讯系产品进行云服务优化。
而跳出腾讯云这个抢跑的个案，在行业内部，更多云计算也在布局 Serverless，只不过还没完成独立的 Serverless DB 产品，未能形成闭环。
可以肯定的是，国内其他云计算厂商也会迅速跟进，但最终，多数云计算都会完成 Serverless 架构，只是看谁抢先一步。
尽管从 Serverless 最开始提出到现在首个 Serverless DB 在中国出现已经过去 6 年，但这场云计算 Serverless 的竞逐，才刚刚开始。
来源：科技向令说 曾响铃
