云原生 Serverless：为企业级研效流程和预算模型设计的计算平台原创

呃，今天雨确实特别大，我，我从广州过来的时候，已经被保安的雨吓了一跳，这高速上基本上看不见。嗯，然后一般来讲呢，下午的第一个演讲都非常的困难，因为要负责开场，如果开的不好呢，那我们就只能指望说现场大家没有打呼噜的习惯了。一般会有这种情况的啊，当然还好啊，呃，我还是有多年的演讲经验啊，在各种各种场合也讲过。嗯，当然同时呢，我们今天的主要的内容还是干货比较多，有一些也是第一次来在社区里面跟大家讲，也也是在。默默的在集团里面做了很多年。呃，然后我们也希望说这些内容，就是大家真的能够引起一些思考吧，他不一定是正确的啊，这个这个这个我我我个人的性格认知，就是我会非常欢迎大家来，呃，一起思辨的看这些问题，然后能够提出一些问题，因为今天的演讲应该是每一个环节，每一个主题都有三个问答的准备啊。

所以大家可以准备一点尖锐的问题。来拷问好吧。我也特别希望说今天结束之后，晚上是吧，在什么社交媒体上能够出现一个什么标题说某某某啊。在上，当场质问腾讯云函数的产品经理。该产品经理当场呆住，是吧？半桶水洒了一地啊，大概是这样的东西啊。呃，然后然后每个问答呢，呃，都会有一个奖品的是吧。呃，应该是这样的啊，所以所以大家不光是可以质问，还有奖品的啊，那我的主题呢，其实是围绕着斯less，就是前面也提到了，就是剧透了很多，就是他在面对开发者的时候，其实开发者很多很很喜欢，因为他很好用，也很便宜。呃，然后然后用起来，就是在做小项目的时候很好用啊，但是呢。

在企业在应用它的过程中，其实会遇到很多很多的问题，那今天我我讲的这个事呢，其实就跟这个强相关，就是怎么样去解决他的在企业里面大规模使用的各种各样的问题，因为在座的各位呢，其实我相信很多都是在一些企业里面担任。主要的研发岗位啊。上面的负责人啊，相关这些岗位啊，所以所以其实大家考虑肯定不是说一个技术的开发体验。这只是其中一环，大家可能更多的考虑是它在整个研发流程里边怎么去闭环在整个管理模式上。特别是在涉及到财务啊，采购啊等等这些过程里边，他是怎么来工作的，他不是单独的一环。所以这个问题会更加的复杂，所以今天会深入的去聊一聊这个问题，也欢迎大家提出自己的企业所面临的一些实际问题啊，我们一起来探讨。所以今天呢，我们提出来是云原生S。嗯，其实更重要是底下这种哈，其实我们是在做一个深度融合，Fast和k us这两个概念去做一个深度融合，技术上架构上的一个融合，来带来一个新的用云体验。

那这个体验是怎么来的呢？其实肯定不是我们拍脑袋来的，更多的是我们过去这么多年在内部在做自研，上云。这上去这个词可能大家不熟悉啊，其实就是我们把腾讯云集团自己的业务，我们的游戏业务，我们的社交的应用的业务，我们等等等等这些业务，B端的，C端的，把它从之前以IDC为主搬到云上来，把它从之前可能传统的架构，比如说基于虚拟机，物理机这些哈，把它搬到容器上来，搬到S上来，这个过程我们积累下来的一些宝贵的经验吧，中间不一定是外部。不是很顺利啊，遇到各种各样的问题，就是大家在各自的企业里面遇到的那些问题，在腾讯这边基本上都有啊，因为腾讯里面每一个业务线都是相当于一个小公司。呃，其实问题会更难搞，所以在这过程里面我们积累了很多很多经验，但是我们也同时呢。

也很幸运啊，在过在在集团内部呢，也得到了很多的支持，跨过了四个阶段，从最早的可能就是通过统一的中台去去完成这种各个BG的这种业务的这种应用啊，到后面上来之后呢，我们再去通过大的盘子池子去做这种资源的优化成本的这种降本增效。呃，再到第三个阶段呢，就是我们在这个大基础上再去做这种研发的效能的提升，把更新的这种研发的这种呃模式和开发的体验能够引入进来，帮助业务，呃不仅仅是在资源层面可以去降本，同时呢，在研发效率上能够做到更加的呃，这个这个这个呃。呃，效率更高，以及说他的整体带来的这种，呃，像江哥说的这个免运维这个事哈，其实说起来很简单，就三个字，但是在各个业务线上去做的时候，是是非常不一样的一个情况啊，所以so在整个内部的推广中呢，也是帮助的很多，但同时挑战也非常大。

那第四个阶段呢，其实就是基于已经积累下来这些从资源到呃研发模式之上，我们会再去推出一个就是直接面向应用本身的这样的一个，呃，一个新的模式吧，能够把它框起来，就是面向应用的这个维度上去，呃，让开发人员真的就聚焦在他的业务开发上了，就不用去管底层的这种资源啊等等这些事啊。然后今天呢，会分三块，一个就是讲一讲斯这个开发范式这么多年发展过来，新的成绩是什么，然后到了什么样的一个阶段，第二个呢，就是我们会聊一聊云原生的这个基础设施，包括云原生这个概念本身啊，其实现在已经是个很泛的概念了，我们也想想一想，就是我个人的一个认知啊，就是它到底代表着什么，应该怎么去呃交付。第三块呢，其实就是今天的核心主题了，就是我们会尝试去提出一种新的理念和新的落地的实践。

然后也欢迎大家一起来探讨啊。那S呢，它其实处在就是刚刚呃辉哥说的就是它处在云原生的第二个阶段，就是他跨越了资源往上中间和开发呃打交道比较深的这一部分了，那再往上一层呢，除了之前我们一直想这样说，第三阶段应该是低代码是吧，但是现在呢，Gpt出来之后啊，其实大家会更加深刻的感感悟到，感觉到就是可能agents。呃，这这个可能会更有落地性啊，我们也非常的拭目以待，也就是这次为什么我们要呃去尝试探索和IDC啊相关这些结合的一个原因啊。那S呢，呃，概念大家应该都很熟悉了，就是他强调的几个点，包括他落地的产品，那目前的进展是什么呢？就是根据the dog de dog，应该有些同学应该有用过啊，就是new dog这些口玩的现场商，他们拿到了很多云上的数据啊，他们就。

得出了一个统计口径，就是什么呢？就是所有在用云服务的企业里边，过半就是超过50%已经在用service了。当然这个不一定代表是函数，也不一定代表是容器会怎么着的，就是在这个理念下的一些技术的落地，呃，这个后面会提到，就是很多企业在里面用，呃，但是有可能是自己自建的，或者怎么着的，各种各种，但是基本上50%以上都有去尝试在内部推行一呃一个或多个的业务，在右S这样的一个基础设施，在在在在在这个演进了。那腾讯云呢也一样，就是我们其实围绕着service这个理念呢，也是构建了一整套的从S资源到中间的这种呃，Pass层，再到上边的这种SS和应用层，工具站层，就构建了一整套的矩阵，它满足于不同的场景，不同的客户，不同的这样的一个业务诉求下的一个应用。所以今天的so呢，不仅仅只是讲fast，讲函数，也也会涉及到像容器啊，涉及到数据库啊啊，中间件啊等等等等这一系列的东西。

那到目前为止呢，呃。腾讯云就是我们自己的这个函数的发展呢，应该来讲呢，呃，战略上还是蛮成功的，我们和小程序的生态做了深度融合，然后目前累计下来也已经服务了200多万的开发者，这个在世界范围内也是最大的一个开发者群体啊。嗯，然后现在呢，我们也是和像国内的信托院也是去推了这种，呃fast这种标准认证，然后近期呢，也是在和这个电标院在推这个国家标准，像这一系列的都是在做整个行业的这种标准规规范化的这些事了，这个已经使得什么，这个也说明什么，就是说呃，Service这个理念，Fast这种模式啊，他已经跨越了，从1213年刚提出来的一种，怎么讲呢，是一种社区的一种理想。然后中间落地了这么多年，各个厂商用自己的做法去呃，落地了不同的产品形态，这么多年到现在终于来到了一个关口，就是说业界的应用已经足够的多了。

但是规范呢，其实还没有太多的这种规范出来啊，所以现在这就是从业界的落地到行业标准规范这样的一个一个阶段了，它是一个趋于成熟的这样的一种一种一种一种形态了。那这里就是大家回顾一下吧，就是呃，So来或者函数，它在技术架构上哈，它跟传统的这种我们用微服务也好，或者是用这个自己做的这种什么，呃呃，库斯龙的这样的一个方式好有什么样的不同啊，它的最大的不同是什么呢？就是它是把整个部署的环节，就是你写完代码之后上线部署的环节，做了一个完全的后置，就是传统的模式下呢，我写完代码，然后我要上线做部署，我一定是做什么的，我一定是找到一些可执行环境什么，不管是容器还是虚拟机，去在那个机器上去把服务起起来。

然后砌起来之后呢，确认它是一个健康的是吧，做了一个health check，然后把这个机器呢，作为back加到了我的LB里面去，然后这个l be加这个多个节点形成一个cos组是吧？通过这种方式，这是一个典型的前置的部署的逻辑，就是我要把。准备好的这个执行环境。加入到一个流量分发的环境里面去啊，这是传统的这个架构，然后呢，他的cos容的逻辑就发生在说我我流量加了，那我这个时候呢，就通过一种呃，叫做被压检测的方式哈，不管是通过CPU的阈值啊，内存的阈值等等这些去决定要往这个组里面加机器还是剪辑器，这是最传统的这种方式啊，而函数呢。它是反过来的，就是当你写完代码，呃，然后建立了一个函数之后，这个时候它其实事实上是没有发生部署的，就这时候他只是把你的代码包你的配置的这种说明师的配置的文件，把它同步到了这个一个地域下的集群里面去。

然后当什么时候才会做部署呢？只有当你配置的触发器，比如说你配置了一个呃，Cost的触发器，或者卡夫卡的触发器，或者一个定时触发器，都可以当这个触发器产生了真实的调用。就是比如说你的time，你的定时发器到时间了是吧，他发起了一个请求，那这个时候呢，才会产生真实的部署，就是这个时候他才会跟呃经过这个函数的平台层，平台层根据这个请求动态的去在一个呃可用区里边去拉起一个机器，这个机器上再去把函数整体跑起来，跑完之后把你的请求路路由进去，让他执行完，执行完之后呢。把结果返回到调用端，然后他再去决定说提起来的一个实例要释放掉还是怎么着啊，通过这种环节，它是一个完全的后置的做法，就是这样的一个区别，就使得他就可以做到按量计费，可以做到啊这样的一个超级。

高的这种并发的支持，因为他是个完全动态的这样的一个过程，它不是前置的。所以。那所以它就使得什么呢？它有一个很好的一个特性啊，这个特性可能大家如果在普通就是简单用函数的时候，可能体会不到，就是它是天生的，天生的一种这个高可溶的。就是你的任何一个请求函数请求，它都是自带高可用特性的，就是你的一个请求进来，他都是会去根据后后边当前地域下的一个后边的可用区的可用情况，去把你的请求路由到一个可用区里面去的。呃，这个和和大家的就是，虽然说大家用函数很简单对吧，反正写完一个函数，创建一个函数，然后就发展这用就好了，但事实上你的请求都是会被安排在多可用区里面去跨可用区可用的这个是他的一个一个一个架构上的一个呃特点吧。

这个也使得说他在呃重计算场景，特别是现在AIGC这个场景，大家都知道，说你做一个AI推理的时候啊，每一个推理其实基本上都要占一张卡，对吧，占一张GPU卡，或者办卡四分一卡，你好，反正都是单占一个计算单元。那这个就使得说，呃，传统的那个模型呢，要么你就一开始就把这个卡准备好，然后把服务布置上去，对吧，然后就在那待着，等着你的请求多与寡的进来，但是在这个模式下呢，就使得你只有请求真的过来的时候，他才会。帮你去找一张卡给你跑起来，所以它是可以实现很好的这种集约性和这种呃这种这种呃响应的这种及时性，这是它架构上的一个优越性。那围绕这一点呢，因为之前函数这条路啊，或者so这条路呢，其实大家所有的厂商哈，都会把它的产品的重点放在怎么去满足开发者的这样的一个工具站上，就是怎么去满足开发者去，呃，怎么讲呢，就是成为全站工程师是吧，不管是我们做的云开发和小程序去联动，还是说语函数这种和这种后端工程师去联动，就是做了很多很多这样的工作，就是我们会关输说你怎么去写你的代码，对吧，从一行代码到镜像，从你用自己的IDE，然后或者是用云上我们给你准备好的web ID啊这些事。

然后到你怎么去部署，呃，通过什么样的一个呃制品库，或者说什么样的一个存储的方式去做部署，然后以及说你部署完之后怎么去做这种版本支持版本的切换啊，流量灰度啊等等这些事。这都是一站式的，就是他工具站的这种打磨，会花很多很多时间去做啊，也取得了一些效果吧，就是大家确实用函数可以呃非常简单的去去用，用用它的这种工具去满足，说你从一行代码到最终这个服务上线，去控制治理这个服务都是闭环掉的。但是呢，在这这些年里面我发现啊，就是说前面说的那么多啊，就是开发者会用的很爽，就是基本上你你做一个个人开发者啊，你基本上用它就够了，对吧，你快速上线一个业务，但是一旦我们把视角挪回到企业里面去，我们发现这个情况就不大一样。

企业会发生什么样的一个变化呢？一个是说现在啊，就是云原生，云原生其实如果落地端产品啊，其实就是容器和K8S啊，基本上就这两个，以这两个为基础，上面会衍生出很多这种生态，那目前呢。呃，根据呃，State of flow去年底的一个报告也也显示呢，就是目前来说哈，Docker和K8S呢，也是目前最流行最热门的技术。不管是已经采用的这种呃企业的数量，还是说准备把它纳入学习计划的开发者的数量，都是在技术圈里面是是领先的TOP1和TOP2。那另外呢，我们也会，我我们也会发现啊，就是他已经就是K8容器已经是企业的事实上的标准，基本上没有企业没有在用容器，或者在呃，没有一用K8S的基本上都用了，我相信在座的各位应该有这个感触的话，只是说用的多和少的问题。

而一旦开始用容器或者用K8S呢，其实很多工具，包括大家的使用的流程，包括一些编译工具，一些牌照等等这些哈，都会基于他们再去做一个适配和上线，所以他基本上就变成了一个底子，就是你的容器，你的KS成了你的整个公司的研发的一个底。一个基础设施。而这个时候我们就发现S他之前强调的，就大家回顾一下S它是一个什么样的一个形态，它是一个完完全全的公有人形态。对吧，就是不管你在用哪一家的函数啊，你在用腾讯的函数，还是在用自己的函数，阿里的函数还是亚马逊的函数。都是选择了一个厂商，然后选择了他的公有云设施是吧，这个时候你基本上没不可能想说，诶我要去做跨云，我要去做什么，嗯，这个自己机房里面的这种建设了，是吧，肯定是就是一个选择的问题了，那。

但是这个是他原本的一个形态决定的，就是只有公有云的这个形态，他才能去给你这解决什么问题呢？就是这种超级弹性，超级按量计费和超高的并发的支持，因为他要靠公有的大的这种资源池去解决这个问题。但是企业不一样，就是企业正常的生产就是一开始他可能是个小团队啊，就是一两个人对吧，一个想法，一个小想法，马上做一个APP出来，然后上线，然后发现发展的很不错，就是刚刚辉哥说到那个那个跨境电商的那个case啊，他真的是一开始就是几个人，然后做跨境电商的ERP萨，然后不小心做成了。然后招人招到100多号这个研发团队，然后开始去引入更多的技术站，然后发现，诶，这个事没有那么简单了，原本的那个，呃，Service提供的这个就是。给他们的就是一开始几个人的这个研发团队，开发者用的很爽，数据区啊，基本上就是我只管写代码就好了，到后边发现100多号人。需要做管理了，然后加上呢，呃，一旦说你规模变大之后啊，你发现企业自然而然的就会产生什么一些需求呢，就是他需要做更强的这种观测性和定制，就是他可能要去引入一些更强的啊这些什么调呃，排账啊，调试啊，然后一些这种业务指标，以及说维运维的指标等等，这些就是有更强的这种。

呃，这种这种这种诉求，以及说他可能要去做跨云了，因为他可能业务覆盖到了海外，呃多个地域等等这些这些都使得他必须要去关注基础实施层的事情，他必须要去，呃考虑数据合规，安全合规等等，这些就是这些都是自然而然在一个企业发展路径中会出现的。那这个时候，如果你是一个完全的公有形态的一个技术产品的话，你必然就和企业出现了一个脱钩。这个是我们之前一直以来啊，就是没有去深入思考的，我们一直觉得说，诶我们就把开发者体验做的很好，是不是就成功了呢。

后来发现不是啊，因为开发者。这个世界上没有没有完全的独立开发者是吧，很少。大多数的开发者都是在一个企业内工作的，他和他的呃同事们对吧，一起在这个企业的管理要求下。呃，采购要求下等等这些之下去完成一个项目的上线，这个才是真实的情况，所以我们如果把视角还停留在一个呃，个人开发者，全站工程师的这样的一个角度的话，发现这个其实是没有思考到位的啊。但是我们会看到就是在这样的一个基础上哈，虽然我们发现企业在用service会遇到很多问题，比如说他的财务预算的这种这种模式啊，你的按量计费是不是适合，这个是第一个问题，第二个问题是说你的这种全托管的这种黑盒的这样的一个一个计算的，一个一个一个一个环境的提供，那企业要做更进一步的调整，排排账怎么办呢？这是第二个问题，第三个问题就是我一旦有一个百人的这个研发团队了，我肯定要去做统一管理了，是吧？这个时候你你函数提供的这一整套的这种工具站和我本身的那个模式之间匹配是不是？

一定能匹配呢，这是第三个问题，第四个问题就是一旦我要做跨云了。那做不了了是吧。那但是我们又把视角挪回来，我们发现企业遇到这些问题。那函数或者这个产品形态在满足他的诉求上确实会出现一些出入，会会出现一些出入，但是企业是不是自己就能找到好的办法解决呢？我们发现。呃，有路径，但是其实还比较难啊，那路径在哪里呢？路径就是整个现在行业里面也在推这个干的，去年，呃，去年。去年的秋天吧，11月份左右的时候，开始推了一个新的技术的这个趋势叫平台工程，大家应该相信，最近也听的比较多，就是engineering，翻译成国内的话呢，其实就是技术中台。就是怎么在企业内部搭建一个面向于业务开发者，就是不同的业务线的这样的一个内部的开发者平台，然后他们基于你这个平台去完成CCD，完成你的开发，上线，治理等等这些过程啊。

呃，这个基本上在国内，其实我相信各自的企业里面应该多少都会有是吧，只是说做的可能有点，呃，各各家企业做的不大一样，然后呢，我认识的一个朋友啊，呃，比较有代表性吧，就是他们大概是八九百人的这种整体的研发团队，然后有七八十号人是做这种基础基础设施的，就是做那个运维，呃，工具工具站，然后去。呃，然然后做那个观测性情况这些事，然后他们就投入了。70号人左右吧，去做这样的一个内部的开发者平台。因为他觉得很大，所以他肯投入这些事。呃，然后坐下来之后发现。呃，确实能够满足内部的这种研效的要求哈，但是我们发现啊，仔细去看这个事。首先投入了很多人是吧，然后出来的东西呢，我们发现好像和我们斯提供出来那个工具量也类似了，就是相当于他们在内部搞了一套，搞了一整套这东西，所以我和那个朋友也聊，他们就说。

这个确实是落地下来也挺开心，但是发现呢，确实投入产出比会其实不是太。好啊，如果从公司的角度来看哈，就是你花出去这么多的成本去做这个平台。然后出来之后呢，其实产生的收益呢，没有没有想象中那么好，因为就是就是整体的这样的一个收益问题，他也期望说，如果说社区里面，或者说业界有一个这种成熟的脚手家，其实就不需要每个企业去搭建了，这还是个比较极端的例子，因为他有很多人他肯投入这个事，但是对一般的企业来讲。这个事好像不是不是那么值得自己去做啊，但是又回到那个问题，就是企业确实有这个诉求啊，他就是要。在内部要有更好的开发体验，去满足业务的业务开发，去去高效的去交付项目去推进，对吧。

但是公有云的那个service呢，好像在这块会有一些出入，所以他要解决这个匹匹配的问题。但这个时候怎么做呢？啊，那这个我们一想，那当然是我们来做是吧，所以我们就推出了这样的一个新的产品理念啊，就是有没有一种办法，把我们已经服务了200万开发者的这样的一个service的产品体验，把它能够原封不动的搬到企业内部里面去呢？我们满足企业的诉求是吧，他的基础设施掌控，他的这种管理模式的要求，他的财务预算等等这些我们都满足他。同时。我们不改变这套工具站原本在光源上的那个形态，就是做一个无损的搬迁，能不能做呢？那当然是可以做的。那我们在这里面其实在架构上做了一个很重要的一个改变。就是这个改变说起来非常简单，就是它里面其实流程上会比较复杂，我把它抽象一点说，我们做了一个改变，大家只要记住我们做了其实就一件事，这件事就是我们把原本service的内容，呃，完全的公有云的资源池这个形态。

把他给呃做了一个解耦，就是说。Sola，我们可以看到它其实是两个价值，第一个价值就是开发体验工具站，第二个价值是弹性的云资源是吧，弹性的那个计算资源，所以我们把这两个价值给结有掉，就是我们尝试向企业交付什么呢？交付工具站，交付开发体验，同时不强不呃不强制要求说企业必须停留在公有云上，其实就做了这个事，那架构上呢，其实我们就是把函数的资源池这一块呢做了一个。开关，这个开关就是企业可以根据自己的需要哈，把这个开关打开，让它可以对接到企业自己的K8集群中。这个集群不一定是在公园上，可以是比如说t ke啊，托管的这个集群，也可以是自己在云上搭出来的一个自己的K8集群，甚至是自己跑在一个自己机房里面的一个私有化部署的K8群都可以，只要网络是通的等等这些就就可以把这个呃，把它给建立起来，就是你的函数。

的资源池和你自己的一个一个一个集群去去拉通，那一旦拉通之后呢，函数就跑在了你的基础设施上。可以跟着你的这种管理诉求啊，安全合规要求啊，财务的要求去走，这个就是他架构上做了一个重要的一个改变，然后在这个配置完成之后呢。那。函数的原本的那一套逻辑，就是它完全的后置的这样的一个动态响应的，这样的一个流转的这个逻辑呢，都是做了一个完整的交付，到到到这个发自集成中的，就相当于是企业通过这种方式啊，就可以把函数全套能力搬到自己的设置上，然后跟着自己的那个。那个资源，呃，这个基础设施就走了。同时呢？呃，我们也去推出，就是因为企业一旦在用KS或者用容器哈，他多少都会，他基本上都会用KRAPI呀，RBAC权限体系这些去构建它的中台，或者构建自己的内部的这种流转的这种体系哈。

那在这块呢，我们也去做了一个强制的兼容，就是把函数原本的一些云API的这种管理模，管理的方式呢，把它给改成ks c d apic，这种兼容体系，就是你可以原封不动的用你原本的中台的那套对接的方式来对接函数的这种整整套的能力。那在产品形态上呢，我们也去做了一些，呃，做了一些补充，就是原本的函数，因为它是直接面向开发者团队嘛，所以我们做了很多这种开发的开发需要去用的，比如说呃，函数模板啊，应用市场。然后他的这套呃开发工具IDE的这些支持，那在新的这个模式下呢，我们面向呃开发运维团队，技术终装团队去做了很多这种运维管理上的这样的一个能力支持啊，我们首先就是刚刚说的API啊，权限这些，我们提供了原生的K8的这种生态支持的。然后对于技术设施这一块呢，我们提供了他的这种可观测性啊，可管控的这种，呃，这种这种服务服务治理一个对接，然后以及说他的资源水位，我们也开放给了这种运维团队，他可以去根据自己的。

呃，这种管理需要吧，去解决里边计算资源的一种运维的问题。那对于中大存队来讲呢，如果他要在内部的中台上去集成这种呃这种能力的话呢，其实对他来讲非常简单，我们提供两种方式，一种呢，就是呃呃K8C生态，K8C生态的这种完全兼容的，就是它可以通过CD去完成一个函数的创建和和这种管理。就可以把自己的那种权限体系呃纳入上去，然后基本上你的内部的开发者其实是在用你的中台来走所有的流程，他可能甚至都不知道说底下是用函数来提供的，这是一种方式，还有一种方式呢，就是我们提供整套的前端组件加后端接口，一整套这种方式去供你去做一个集成。

这个呢，像我们在去年的时候也和有赞落地了一个case啊，就是有赞在他的pass云，有赞大家可能知道就是做电商SaaS啊，然后他们也提供给他的SV一个pass云平台，供他的SV去做这种，呃呃小程序。那个那个商店的那个什么运营活动啊，相关那些的一些组件的一个交付哈，那他就引入了函数在里边，作为一种，呃，这种这种开发能力去提供给他的SV去用，也是整套集成的函数的这种能力啊，在他的动态里面，在在他的那个pass云平台里面。而这一切呢，他改变的其实更多的是企业怎么去把函数纳入进去，供业务团队去用，而业务团队用到的呢，其实还是完整的so的这种公有云的那一套的开发体验，呃，这个业务开发其实他只需要做一件事，就就是还是之前的三步走的方式啊，写代码。然后就完成一个声音式的一个配置上传，然后然后这个这个应用自然就跑起来了，呃，平台来负责他的弹性的执行，他的运维，它的扩这些。

而这时候我们也会在思考，就说企业里边哈，呃，毕竟他基本上上规模的企业，可能是Java用的非常多对吧，微服务用的也非常多，有一些可能就是基于这个微服务的框架去搞起来的。啊，有很因因为因为微服务本质上来说是耦合了管理方式的哈，就是一个企业他选择了微服务，不一定是因为微服务的架构本身有多先进啊，更多的是它结合了他整个的管理模式和研效的这种体系。因为他更好的更新力度的，可以去管到对应的这种团队哈，所以这个时候我引入S，那怎么去和原有的这一套已经跑了多年，很稳定的这样的一个微服体系去结合起来呢？但这时候其实我们会推荐啊，一开始你在内部去用的时候呢，可以去根据场景去做选择。就是微服务的可能更多的是在做什么呢？做这种核心的这种系统管理，要求比较复杂的，然后稳定的这样业务，那对于一些这个灵活，比如说一些数据处理啊，重计算的离线任务啊，相关这些其实可以优先去用service函数来解决，这样一搭配起来呢，就可以起到。

呃，就是一个一个平衡吧，就是你可以用到很用到service来来提高很好的效率，同时加速一些呃这种整体的可靠性，同时微服务那块呢，也可以保持它的原本的那个那个那个推进啊，所以这两者是本身是一个很好的结合。然后呃，因为前面说到就是我们把资源层做了解耦，使得说S可以跑在你的一个基础设施，跑到你的自己的集群上去，那在这个基础上呢，我们发现它其实可以在企业的这种用云的体验上会有一个很好的一个实践。呃，这个时间里面分两层，第一个事件是什么呢？就是说S啊，它原本的那个按量计费，其实是在一些波动比较大的情况下，是吧，大家做一个活动或者怎么着的，一天可能来一个很高的高峰，然后晚上没有量，可能这样的模式下他会比较省钱。

但是它毕竟是一个按量模式是吧，按量模式我就是大家可能之前一直听的是什么呢？就是这种配go这个模式在呃。呃，项目上会有很好的这种节约是吧，但是大家，但是但是厂商，所有厂商都没有告诉你的是什么呢？就是一旦你用的很多的时候，这个按量模式不一定很省钱。我们可能是第一家对外这么说的啊，当然这是事实啊，就是大家可以仔细想一下这个事，就是按量模式实际上是什么模式。就是散买模式嘛，对吧。就是我买糖的时候是按斤称还是去搞一个集装箱买一卡车过来，这是两模式啊，在现实生活中买糖的时候，你按颗去买还是按斤去买，价格体系是不一样的，按斤称和这个呃，大家在超市买它应该有这个经验哈。这个就是当你购买规模不同的时候，你的那个采购模式会很明显的决定你的成本支出。

这个是按量模式，它必然的一个一个一个劣势。No。怎么解决呢？那他的解决方式其实就是说，呃，因为现在是两个大前提，第一个模式，第第一个前提是说我上线的业务，它必然会有一些波峰，波谷对吧，这个是这个自然情况，我也我也希望说他要非常野蛮的增长是吧，最好那个波峰能够更大一点才好，老板很喜欢，但是同时呢，这个这个。这种波峰呢，也会带来更大的这种资源的诉求。然后同时呢，我们又发现它的整体规模也上涨了哈，每天可能都有一些这个存这有一些固定的流量在跑了，那这个时候我应该怎么去用好，我们应该怎么去更好的去去做这个购这个这个云的计算资源的一个购买的，所以这个时候我们提出来就是你可以去做这样的一个自有集群。去做一个这种流量的打底，就说你对接你的K8集群是吧，这个集群里面的资源可能恰好是满足你日常的这种流量的需求的。

然后呢？当你的流量，呃，今天做活动突然暴增的时候。那在这个模式下哈，我们提供了一种能力，叫做混合资源池的能力，就是你可以你可以把这个模式打开之后，你的溢出的流量会被自动调度回公有云上去。就相当于，呃，在这个模式下呢，你的函数请求会优先调度到你自己的K8集群，就对接好的那个集群上去，而一旦发现你的流量超出了这个集群所能承受的上限，这个很好理解是吧，因为你的集群不可能很多节点嘛。那这个时候调度层就会自动的把你的请求路由和公有云上去用公有云的弹性资源，那溢出这部分呢，公有云上会按照那个按量计费，就相当于是一种呃存就是一种常量资源去用一个更更经济的一个采购，对吧，我买一些机器，买一些这个TP的容器，呃，一些节点在里边去，可能是一个很好的这种这种啊包月的价格啊在里边，然后满足日常需求，溢出的时候呢，按照函数的按量计费，这个时候就是很好的一种结合，就是就是批发加散买啊，一结合起来发现整体的这种呃。

采购模式就很很清晰，也很也很划算了，那第二个模式呢，会更加的。呃，高级一点就是它会涉及到一些，就是如果你的集群，你的K8集群已经很大了，可能已经上万上10万上上百万盒的这样的一个一个规模集群了，那这个时候呢，所有的技术生态团队都领到一个任务，可能就是他的OKR了，就是我怎么去把已有的这么大的一个规模的集群的利用率提高到一个老板满意的一个一个水位呢？那这个时候可能就会在内部考虑一些，比如在一些混部啊，一些这个，呃，这这些方方式手手段了，但是在这些混部呢，我们发现哈，他他现在来看呢，会有一些实施上的难度，就是不管是哪一种方式哈，你会发现他会跳业务。

就是所谓的在内物，无非就是说，诶，我把我的TK集群的在线里边在线集群，因为它有波风波谷嘛，对吧，我把它动态的一些闲置资源抽出来，通过通过这种watch watch的这相关的一些技术吧，把它抽出来形成一个动态的暂时是没有资源呃在用的，呃没有业务在用的这样的一个动态的资源池。然后呢，把一些job，把一些k job标记成一个Du job，然后它就会被调度到这个不稳定的动态资源池上。但是这里面会有个问题，就是它会很挑业务，就说什么样的job才能够被调度到这个Du的资源上去呢？因为调度到Du资源资源上去后导致一个问题，就是他很有可能这个教务会会被饿死的。就是因为有可能他马上会被回收掉嘛，就是资源会被回收掉，他就没法没有资源用了，那他就一直在那等。而在这个模式下呢，其实可以解决这个问题。因为函数的调度层是有主动感知的，就是你的一个函数请求过来，一旦说你对接了这个，呃，TK里面抽出来的这种动态的闲置资源的话呢，他会优先去看你可不可以用，如果发现你不可以用的话。

他会马上调度回供有人的弹性资源池去满足这个业务的需求，马上去去执行一，然后如果你有这个资源可以用呢，它就会调度到那个Du的资源上去啊，这样就可以使得它是一个不挑业务的，就是你只要是一个普通的进线的任务就可以就可以完全的去用这个模式来来来提高这种TK的，呃，这个集群的利用率，同时呢，也能满足业务的诉求。所以总结过来看呢，呃，整体的这一套模式哈，它满足了三个主要角色的一个价值，第一个对于企业来讲，企业其实可以更灵活的去安排自己的这一个成长的路线，安排自己用云的这一套规划，因为他会发现就是斯这样一个改造呢，就使得他没有厂商绑定了，因为他可以他他交付的是一个能力啊，他可以跟着自己的这个技术设施的要求去走，这是第一个，第二个对于企业内部的技术中台团队来讲呢。

他对S这套体系从之前的黑盒的状态变成现在这个白盒的状态，他可以在上面叠加自己的这种观可观测定定制啊，这些呃，这些呃，这些需求都可以做到，然后以及说他的权限管理啊，他的这种呃资源的采购等这些都可以在这么做一个实施。第三个对于企业里边的业务团队来讲呢。那之前可能他自己项目用函数用的很爽，但是企业里边发现诶要求不给用是吧，现在来说呢，就是他拉通了这种工业云和和内部的这样的一个，呃，产品的一个对齐，就是他不管是在企业内部还是在自己的项目上都可以很好的用搜这样的开发体验了，所以。呃，相当于说我们通过一种改造吧啊。呃，这三个大的角色啊，就是实际生活中发生的这个三个角色，能够把他的需求做一个平衡和统一。那我们内部呢，其实是有个落地的，就是因为前面也提到嘛，我们最天上云中第三个阶段，我们也就在内部的推，那这个也是去年我们上线的，在内部的这个可以理解为是我们内部的这个研发中台。

然后呢，在里面呃，产品化了我们的函数的能力啊，作为呃任务平台去用啊，大家也是取得了很好的一个成绩吧，这里就就不吹牛了哇。我时间也快到了，然后在这个月啊，六月初的时候呢，我们也拿到了今年23年度的新能源的云原生技术创新领航奖。也是这个模式，呃。嗯。就是就是就是这个就是一个怎么讲呢，就是这是个很难的事情，就是他其实在某种程度上是在把原本的斯一种纯理想的一种。啊，不管是计费模式，还是使用模式，还是呃开发等等这些啊，都是一个非常非常理想极简的一种模式，把它从某种程度好像把它复杂化了。对吧，就是它好像没有那么的简单，没有那么的纯粹了。

所以这是它难的点，就是一旦你在做把一个原本简单极简的模型，把它拆成一个稍微复杂的一种落地的时候呢，可能就会有很多反对或者说很多质疑的声音，就是你为什么要这么去做？但是我们还是坚信这一点。就是。呃，未来肯定有一天我们会达成。一种非常非常理想的S式的这样的一个用云体验，大家可以不用去思考那么多，反正就自己的根据自己的业务需要去开发，去上线，去不用运维，然后去按照某一种合理的方式去给钱就好了，这个是我相信某一天一定会达到这样的一个状态的。但是现在。现在不是啊，现在我们会发现很多企业他有安全合规的要求，他有跨人的需求，他有自己的。这种基础设施上的这种，呃，定制和观测的需求，这些都是自然而然存在的啊，大家企业里面一定有这样的一个需求，所以我们会想的是一个美好的技术哈，我们一定会朝着他的那个方向，他的理想方向去走，但是中间这个过程我们思考的更多的应该是怎么帮助企业。

在这个过渡阶段，在这个发展阶段里边，能够用好云，用好这个技术，去帮助到自己的业务快速的增长，快速的去走，然后最终和我们一起达到那个终点，这是我们要去思考的。然后最后啊，就是我想说一句，呃，发自内心的话吧，就是因为我来腾讯之前是在一个小公司里面做CPU啊，做那个一个小的后端云平台的，也是这个方向的，也是国内第一个做那个小程序后端云的，叫直销云，可能大家没听过，那后来加入腾讯云之后呢，也是沿着这一条路一直在走，也也算是做了八年的时间了。呃，对于sola这个事呢，我是一直很坚信。然后我相信今天讲完这个，可能会有一些同学会有疑问说，呃，你们是不是不那么关注开发者，是不是开始看重企业，开始看重企业的收入或怎么着了？不关注开发者，但是恰恰相反啊。

就是我们思考的问题空间或者思考的维度会更大一点。原因在什么地方，就是。我们之前思考的所有一切都是我们怎么去通过一种技术站，通过一种技术服务的交付，去把一个开发者武装成全站开发者。这个是之前的一直的一个思考的框架，但是这个框架对还是不对呢？结果发现他对了一半。就是如果你是个独立开发者，如果你一个人搞一个团队的活，对吧，快速做一些APP上线，然后赚钱，这个是一个是他要解决的，他解决的问题，而且他已经解决的很好，对吧，他帮助了很多小程序开发者去做完他的事了，但是一旦你不是独立开发者，你是在一些公司里面去工作的。那这个是就完全不同的故事了，那你要面临的问题就是，哎，你用这个service的东西是用的非常爽，用函数用的很好，不管是用阿里的还是用腾讯的，用的很爽，但是一旦到了一个公司里面发现不给用，你必须用这个公司给你准备好的那个开发者平台，对吧，不管他是什么样的一个流程，什么样的一个模式，你都要去被呃安排去用那个东西，不管他好不好用，反正这些这公司里面是这么要求的，他已经在那里了，是吧。

这个才是现状。所以怎么解决这个问题啊。就是今天这个就是我们尝试把S通过云原生化的一个改造，让它变成一种行业里面的最佳的一种方法论，最佳的一种产品的形态，让他真正能够走进每一个企业里边。替代那个企业里边自己攒出来那个开发者平台，让他成为一种业界最优的一种一种实现方式。这一天来到了，那大家就不用说去到A公司被用A公司的这个这个工具站去到B公司用B公司的对吧，那那你不管是在哪一家公司工作，你都会用到统一的这种思维的开发体验，这个才是我们我个人认为是。呃，真正意义上关注开发者。关注康的意思是什么呢？其实我们会关注我们做的这个技术服务，这个工具站，是不是能够伴随你整个职业生涯的。

可以被你带着走的去的任何一家公司，甚至是你自己开的公司，对吧，能够帮助到你业务快速的增长的。呃，这样的一种。呃，这样的一种思考吧，好吧，谢谢大家。