作者 |何世友
出品 | 腾讯云
(资料图片)
自2013年提出以来，Serverless（无服务器）作为屏蔽服务器、按调用计费、事件驱动、弹性自动伸缩的计算服务，深受开发者喜爱，被称为云原生未来发展的方向。
最新的调查报告显示：在核心业务中使用Serverless的用户达到18.11%；已经开始和计划使用Serverless技术的用户超过了70%。根据Datadog数据，有超过50%的使用云服务的企业或组织使用了Serverless技术。
但是，当开发者从创业阶段过度到大型企业阶段，原来的Serverless模式逐渐给企业的管理、运维以及财务等带来一系列的挑战，这也是当期Serverless很难在大型企业全面应用的根本原因，为了破解这样的难题，腾讯云工程师从深度分析症结，推出了顺应企业发展需求的技术，打造真正服务于企业的 serverless 平台。
Serverless 的从 1 到 100：企业又爱又恨
Serverless为一个新业务提供了理想的从 0 到 1 孵化体验——开发者只需要关注业务逻辑开发，业务所需的底层资源规划运维由云平台处理，轻松应对上线后的流量增长，同时，业务的成本支出由业务的真实请求调用量决定。可以说Serverless给开发者真正带来了上线足够快，服务足够稳，花费足够少的完美“创业”体验。
然后，当这个业务在 Serverless 的帮助下成功跨越 0 到 1，开发者成长为企业，来到从 1 到 100 的精益经营阶段，Serverless 技术的应用开始出现问题：
▶ 按调用计费模式从“蜜糖”变成“毒药”；
▶ 全托管的计算服务无法满足企业更进一步的管控、观测、定制需求；
▶ 自成一体的发布流程、资源 quota、权限体系，企业内部的研发中台团队不好统一管理，出了问题还得背锅；
▶ 完全的公有云形态制约了企业在跨云、混合云等特殊环境上的可选择性。
这些问题让企业对 Serverless 又爱又恨。以金融行业为例，不少大行等均尝试在内部自建 faas 服务。k8s 社区近年来也一直涌现各类 FaaS 框架，例如 Keda、Knative、OpenFaaS 等。当然企业自建目前问题也不少，投入大、维护难、效果不佳，也导致自建的 faas 在内部往往承接业务上量不多。
面向开发者设计的 Serverless，需要为企业重新思考。只有服务好企业，才能真正意义上将 Serverless 发展为云原生开发模型，实现 Serverless 自己的 1 到 100。
企业真正需要的是“云原生Serverless”
2017 年，腾讯云云函数 SCF （Serverless Cloud Function，下文简称 SCF）发布后不久迎来了第一批种子用户，每个月 100 万次调用量免费额度，帮助用户零成本发展业务，其中不少用户发展良好，最终拿到更大的投资，业务越做越大。
其中，有一家做跨境电商业务的 A 公司就是典型代表，2018 年成立到 2021 年拿到上亿融资，他们的用云体验也发生了显著变化。
2018年 ~ 2020年，作为创业公司需要快速响应市场需求，18 年 ～ 20 年，A 公司的技术栈完全基于函数 FaaS 架构搭建：
▶ 用事件函数 + 消息队列触发器实现商品信息的采集分析入库；
▶ 用事件函数 + 定时触发器实现离线的数据批量处理；
▶ 用 Web 函数 + API 网关实现 API 服务；
▶ ……
2020 年前后，一直不温不火的国内跨境电商业务，突然爆发，A公司属于该赛道的 Top 选手，业务也随之迅速起量，从年初每月几百上千块用云成本，到了年底增长到每个月过百万，研发团队也从几个人，快速扩张到了几百人。A公司的全量业务一直以腾讯云云函数 SCF 作为业务的计算平台，终于在 2021 年拿到了新一轮融资。
然而接下来， A 公司却开始考虑把部分业务从云函数往容器迁移了，这让我们倍受困扰，通过与客户研发负责人深度沟通，以下几个非常现实而又不得不承认的核心问题摆在了我们面前：
业务复杂度与管理需求升级，Serverless 对企业的管理团队造成冲击
业务发展壮大，不可避免要引入行业主流人才，对业务线进行拆分，对研发工序进行分层。这个过程融合了管理流程升级和技术栈转移。
拆分业务线后，各业务线开发自己的模块，保持业务线的快速迭代效率，但完全的业务线自治在企业内部自然会导致资源配置冗余和浪费，于是中台开始搭建，统一的服务发现、治理机制开始上线。这些都和 Serverless 从开发到发布一竿子插到底的全栈自助模式有冲突。
快速扩张的团队，引入的行业人才都是带着多年工作经验进来的，他们或熟悉某些开发框架，或熟悉某些架构模式，为了快速上线业务，这些框架和架构模式也会被开绿灯，在内部生长开花。Serverless 需要一些改造或对接在这个过程就会被嫌弃，更灵活自由的容器平台受到青睐。
基础设施的掌控度升级，Serverless 对企业的运维团队造成冲击
拔地而起的中台团队承接了运维、研效治理的工作职责，他们有多年的机器运维经验、内核指标观测经验。Serverless 完全托管免运维的黑盒模式在这时也逐渐带来一些问题，业务团队想用拦不住，出了问题（比如说代码写的不好 OOM）还得背锅。
业务线的扩充也引入了更多的系统，如大数据的 Spark、Flink，中间件的 Kafka、Redis，数据库等等，随着云原生的大发展，基于 K8s 底座的统一资源管理和运维工具链也更加成熟。在这个底座上，每个业务线都可以用资源 quota 进行管理，Serverless 独立的并发配额弹性资源让平台运维对资源不再可控。
同时，随着业务的扩张，企业也在筹备着进军不同国家地区的计划。不同国家地区有更多的安全合规要求，这也要求系统服务能响应这些要求上云或下云。Serverless 只能跑在公有云就成为阻碍计划的绊脚石。
预算和采购需求升级，Serverless 对企业的财务团队造成冲击
Serverless 的按量计费模式替代了传统的包年包月，让财务规划异常困难。
按量计费是典型的线性计费模型，按照业务的实际用量，成本线性增长，这对于孵化期的业务是减少早期投入降低成本的好机制，但对于稳定增长的业务来说，则是越来越重的成本负担，业务规模越大，成本越高，完全没有收敛的意思，成本不再可控。
让Serverless函数跑在云原生K8s上
企业拥抱云原生，企业内的开发者拥抱 Serverless，融合带来完美平衡
Serverless 对一个上规模的企业，引入的是管理、财务、基础设施掌控等方面的问题。而我们回过头来看，Serverless 对企业内的开发者依然是最优解。企业里的业务开发者也是开发者，他们专注在需求转化为代码这一过程中，不喜欢和机器、节点打交道。一个类似 Serverless 的资助开发平台可以最大程度上帮助业务开发实现最高效率。
另一方面，随着云原生的大发展，企业的用云体验逐渐统一，k8s 成为事实上的标准，每一个上规模的企业都在基于 k8s 底座实现着自己的管理、财务预算、基础设施掌控等需求。这是云原生概念之于企业的最核心价值。
现在，我们思考的是，在当下如何找到 Serverless 和企业的云原生诉求的结合点，让企业在基础设施掌控度和业务高效开发之间找到一个平衡。因此腾讯云提出“云原生 Serverless ”理念，构造了全新的 Serverless 产品形态腾讯云Serverless云函数 SCF on K8s。
SCF on K8s实现Serverless能力
同时跑公有云和私有云
SCF on K8s 将 SCF 的开发工具栈和公有云资源池进行解耦，让 SCF 的整套能力可运行在企业自己的 K8s 集群中，可完整复用企业已有资源。同时，SCF 完整兼容 k8s API 和 RBAC 权限体系，方便中台团队快速集成 SCF 能力，无需重复对接。有了 SCF 能力，中台团队也无需从头构建开发工具栈。
如下描绘了 SCF on K8s 在企业研效流程中的结合：
SCF on K8s 不仅让企业内的业务开发者拥有公有云 SCF 一样的开发体验，也让中台运维团队可以从研发流程到资源管控到可观测上管理 SCF，同时，跑在企业统一的 k8s 资源池中，让财务预算工作也更好展开。
SCF on K8s可无缝集成到企业已有技术中台
满足企业多云跨云需求
SCF on K8s可以满足企业多样的用云需求：从 0 到1阶段的公有云弹性资源模式，让企业快速试错；从 1 到 100 阶段的混合资源池模式，让企业选择最经济的方案，无需被公有云绑定，在自己的基础设施上使用 Serverless。
SCF on K8s 完全兼容 K8s API 和权限体系，并提供了 CRD，中台团队可像管理 Workload 一样管理 SCF。
▶ 统一的研效流程管理：业务开发者遵循研发审批流开发、测试、发布，全程都在中台团队管控之下；
▶ 可控的资源 quota：业务开发者根据需要申请资源 quota，中台团队通过 k8s 集群资源管控来进行资源供给；
▶ 可观测的 SCF：SCF 跑在 k8s 集群中，兼容 k8s 本身的PVC、服务发现、监控日志机制
SCF on K8s 和公有云 SCF 的能力保持完全一致，业务开发者只需选择自己熟悉的编程语言、IDE 完成代码编写，通过 SCF 命令行工具或中台团队提供的发布流程完成代码的发布，最后配置触发器和 算力（CPU 或 GPU）即可。真正专注于业务需求实现。
在大型企业的研发模式中，微服务是占据主流的存在。不同业务开发各自的服务模块，同时又能由服务发现、服务治理等中央服务实现统一管理。非常符合企业的统一纳管，分而治之的理念。而微服务也存在过于复杂的问题，快速迭代的业务使用微服务体系，研发效率会偏低，一次发布需要半天对于敏捷研效是个巨大的挑战。
SCF on K8s 可以和微服务体系实现补位，对于快速迭代的项目，可先采用 SCF 实现高效开发，快速发布；待项目成熟后，再转为微服务体系。微服务在在线场景上生态丰富，表现卓越，而对于近离线场景的数据处理、视频转码等事件触发型服务，则可使用 SCF 实现，不管是开发效率还是资源利用率都能更高。
业界首创在离线
混合资源池模式
有效提升 K8s 集群资源利用率
SCF on K8s 支持配置资源配比，将 K8s 集群资源和公有云弹性资源搭配使用。在该模式下，函数请求优先调度到 K8s 集群，函数调度层感知到 K8s 集群资源不足时调度回函数公有云资源池。如此以来，企业可根据业务实际请求量，配置一个打底的 K8s 集群满足日常资源所需。同时，利用函数公有云资源池，响应高峰期的溢出资源所需。在实现业务高可用的同时，实现最经济的云资源采购。
k8s 集群基于 Virtual Kubelet 抽取闲置资源，成为离线算力，将一部份低优的任务调度过来，这些任务会在有资源供给时执行。该方案不仅在业务调度层较为复杂，也存在挑业务的情况，需要业务能接受较长的等待时间，同时，低优任务如果不及时释放资源，又会反过来影响在线业务的资源供给。
K8s 而将 K8s 离线算力作为虚拟的 K8s 集群绑定到函数服务，再开启混合资源池，这些问题将迎刃而解——
▶ 不挑业务：函数的主动调度机制在 k8s 离线资源有供给时立即调度任务执行，没有时及时调度回公有云资源池，保障任务始终可以执行；
▶ 不影响在线业务：函数的超时配置限制任务的最长执行时间，执行完或到了超时时间会立即释放资源，最大程度保障在线业务的资源供给；
▶ 业务调度层简单易用：只需要将任务发布为事件函数，配置消息队列、定时任务等触发器，并打开混合资源池配置即可。
腾讯内部的实践
TKE容器服务在腾讯集团内部作为统一的应用研发管理平台，在标准的 k8s 能力之上，提供了跨集群、跨 zone 的容器资源调度管理能力和应用维度的运维治理能力，也是技术中台的一种实现，在过去的三年里很好的支撑了腾讯集团业务全面上云。
腾讯云云函数 SCF 作为 Serverless 的落地实现，函数 SCF 作为 Serverless 的落地实现，在集团内部同样深受业务开发同学的喜爱，例如大家熟悉的腾讯文档、腾讯会议、腾讯地图、企业微信等都有大量的服务是基于函数开发上线。
在具体的研发模式上，核心业务逻辑和重点的在线服务主要是用微服务架构实现，服务管理、流量管理、故障容错和配置管理用北极星做了统一治理。函数主要用在以下几个场景：
▶ 前端的 SSR 和 BFF 场景，例如腾讯文档的表格、演示文档的 SSR 用函数实现；
▶ 近线数据处理场景，例如腾讯地图的导航数据计算、地图瓦片数据的计算等用函数实现；
▶ 离线任务场景，例如运维团队的定时巡检任务和定时拨测任务、计费团队的定时账单汇算任务等用函数实现。
这些场景中，函数以其灵活高效且免运维的开发体验很好的支撑了业务发展。但独立的按量计费模型也给业务团队的财务预算带来了挑战：不好预估项目的成本支出，业务增长带来使用量上涨后，按量计费的总费用相比采买一批机器不够划算等，在集团降本增效的大环境下，成为业务团队的一块心病。
22 年 11 月，SCF on K8s 通过“任务中心”的产品形态集成到 TKE，拉通账户权限体系，兼容统一的发布审批流程和预算 quota 申领机制。
上线后，目前已经有大量的 K8s job、cronjob 迁移到云函数 SCF 任务平台，不仅开发简单，且在任务的响应延迟等技术指标上存在量级上的提升。
不少之前使用公有云函数实现的业务也迁移过来，兼容了 TKE 的 quota 申领机制，业务团队可以在传统的函数按量计费模式和批量采买容器作为函数的运行资源池之间选择。对于量级较大的业务来说，后者是控制成本的最佳措施，降本增效环境下的心病解除。
Serverless 终将跑在每一个基础设施之上
无可否认，Serverless 仍然是企业用云的终极理想形态，只需关注核心业务逻辑，其它的一切交给算力供给方搞定，是精益经营的经济体决胜于市场的基本逻辑。然而，这是一个漫长的进化过程，参与其中的每一方都要发展，例如，Serverless 的函数粒度的开发模式，需要更优秀的人才梯队能够将业务需求拆解的更细，而更细更多的模块则又需要更强大的服务治理机制…… 类比到传统制造业，就是从工厂里的生产工序、流水线到上下游供应链都要整体升级，最终才能达成工业革命。这需要一些时间，也许是 5 年，也许是 10 年或更久。
在我们抬头仰望星空的同时，也要踏实走好脚下的每一步——如何让企业用足够小的代价换取最大的收益，是每个云厂商都要积极思考并探索解决的课题。从公有云 Serverless 到云原生 Serverless，也许部分厂商会认为是一种退步，而也许恰恰相反，只要改变本身能解决多数企业的痛点，为企业带来真正的价值，它就是进步的。
可以预计，随着Serverless范式的逐渐完善，Serverless 终将跑在每一个基础设施之上！
