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