Serverless Days原创

2023-06-192023-06-19 18:45:12播放1.4K

点赞0 收藏 0

Serverless Days【深圳站】活动回顾

视频文本

温馨提示：文本由机器自动转译，部分词句存在误差，以视频为准

00:00
建体系，对企业的财务预算、基础设施的掌控、研发管理都提出了更高的一些挑战，那我们要怎么样来适配当前企业高速发展的需求呢？那接下来让我们有请腾讯云云函数负责人何世友为我们带来云原生service为企业及研效流程和预算模型设计的计算平台主题分享。好，今天雨确实特别大，我从广州过来的时候，已经被保安的雨吓了一跳。高速上基本上看不见。嗯，然后一般来讲呢，下午的第一个演讲都非常的困难，因为要负责开场，如果开的不好呢，那我们就只能指望说现场大家没有打呼噜的习惯了。一般会有这种情况的啊，当然还好啊，呃，我还是有多年的演讲经验啊，在各种各种场合也讲过。
01:08
呃，当然同时呢，我们今天的主要的内容还是干货比较多，有一些也是第一次来在社区里面跟大家讲也。也是在默默的在集团里面做了很多年。呃，然后我们也希望说这些内容，就是大家真的能够引起一些思考吧，他不一定是正确的啊，这个这个这个我我我个人的性格认知，就是我会非常欢迎大家来，呃，一起思辨的看这些问题，然后能够提出一些问题，因为今天的演讲应该是每一个环节，每一个主题都有三个问答的准备啊。所以大家可以准备一点尖锐的问题。来拷问好吧。我也特别希望说今天结束之后，晚上是吧，在什么社交媒体上能够出现一个什么。标题说某某某，呃。在上，当场质问腾讯云函数的产品经理。
02:00
该产品经理当场呆住，是吧？半桶水洒了一地啊，大概是这样的东西啊。呃，然后然后每个问答呢，呃，都会有一个奖品的是吧。呃，应该是这样的啊，所以所以大家不光是可以质问，还有奖品的啊，那我的主题呢，其实是围绕着斯less，就是前面也提到了，就是剧透了很多，就是他在面对开发者的时候，其实开发者很多很很喜欢，因为他很好用，也很便宜。呃，然后然后用起来，就是在做小项目的时候很好用啊，但是呢。在企业在应用它的过程中，其实会遇到很多很多的问题，那今天我我讲的这个事呢，其实就跟这个强相关，就是怎么样去解决他的在企业里面大规模使用的各种各样的问题，因为在座的各位呢，其实我相信很多都是在一些企业里面担任。主要的研发岗位啊。上面的负责人啊，相关这些岗位啊，所以所以其实大家考虑肯定不是说一个技术的开发体验。这只是其中一环，大家可能更多的考虑是它在整个研发流程里边怎么去闭环在整个管理模式上。
03:06
特别是在涉及到财务啊，采购啊等等这些过程里边，他是怎么来工作的，他不是单独的一环。所以这个问题会更加的复杂，所以今天会深入的去聊一聊这个问题，也欢迎大家提出自己的企业所面临的一些实际问题啊，我们一起来探讨。所以今天呢，我们提出来是云原生S。嗯，其实更重要是底下这种哈，其实我们是在做一个深度融合，Fast和k us这两个概念去做一个深度融合，技术上架构上的一个融合，来带来一个新的用云体验。那这个体验是怎么来的呢？其实肯定不是我们拍脑袋来的，更多的是我们过去这么多年在内部在做自研，上云。这上去这个词可能大家不熟悉啊，其实就是我们把腾讯云集团自己的业务，我们的游戏业务，我们的社交的应用的业务们等等等等这些业务，B端的，C端的，把它从之前以IDC为主搬到云上来，把它从之前可能传统的架构，比如说基于虚拟机，物理机这些哈，把它搬到容器上来，搬到service上来，这个过程我们积累下来的一些宝贵的经验吧，中间不一定是外部。
04:15
不是很顺利啊，遇到各种各样的问题，就是大家在各自的企业里面遇到的那些问题，在腾讯这边基本上都有啊，因为腾讯里面每一个业务线都是相当于一个小公司。呃，其实问题会更难搞，所以在这过程里面我们积累了很多很多经验，但是我们也同时呢。也很幸运啊，在过在在集团内部呢，也得到了很多的支持，跨过了四个阶段，从最早的可能就是通过统一的中台去去完成这种各个BG的这种业务的这种应用啊，到后面上来之后呢，我们再去通过大的盘子池子去做这种资源的优化成本的这种降本增效。呃，再到第三个阶段呢，就是我们在这个大基础上再去做这种研发的效能的提升，把更新的这种研发的这种呃模式和开发的体验能够引入进来，帮助业务，呃不仅仅是在资源层面可以去降本，同时呢，在研发效率上能够做到更加的呃，这个这个这个呃。
05:12
呃，效率更高，以及说他的整体带来的这种，呃，像江哥说的这个免运维这个事啊，其实说起来很简单，就三个字，但是在各个业务线上去做的时候，是是非常不一样的一个情况啊，所以service在整个内部的推广中呢，也是帮助的很多，但同时挑战也非常大。那第四个阶段呢，其实就是基于已经积累下来这些从资源到呃研发模式之上，我们会再去推出一个，就是直接面向应用本身的这样的一个，呃，一个新的模式吧，能够把它框起来，就是面向应用的这个维度上去。呃，让开发人员真的就聚焦在他的业务开发上了，就不用去管底层的这种资源啊等等这些事啊。然后今天呢，会分三块，一个就是讲一讲斯这个开发范式这么多年发展过来，新的成绩是什么，然后到了什么样的一个阶段，第二个呢，就是我们会聊一聊云原生的这个基础设施，包括云原生这个概念本身啊，其实现在已经是个很泛的概念了，我们也想想一想，就是我个人的一个认知啊，就是它到底代表着什么，应该怎么去呃交付。第三块呢，其实就是今天的核心主题了，就是我们会尝试去提出一种新的理念和新的落地的实践。
06:28
然后也欢迎大家一起来探讨啊。那S呢，它其实处在就是刚刚呃辉哥说的就是它处在云原生的第二个阶段，就是他跨越了资源往上中间和开发呃打交道比较深的这一部分了，那再往上一层呢，除了之前我们一直想这样说，第三阶段应该是低代码是吧，但是现在呢，Gpt出来之后啊，其实大家会更加深刻的感感悟到，感觉到就是可能agents。呃，这这个可能会更有落地性啊，我们也非常的拭目以待，也就是这次为什么我们要呃去尝试探索和IDC啊相关这些结合的一个原因啊。
07:09
那S呢，呃，概念大家应该都很熟悉了，就是他强调的几个点，包括他落地的产品，那目前的进展是什么呢？就是根据de dog de dog应该有些同学应该有用过啊，就是new dog这些口玩的现厂商，他们拿到了很多云上的数据啊，他们就。得出了一个统计口径，就是什么呢？就是所有在用云服务的企业里边，过半就是超过50%已经在用service了。当然这个不一定代表是函数，也不一定代表是容器会怎么着的，就是在这个理念下的一些技术的落地，呃，这个后面会提到，就是很多企业在里面用，呃，但是有可能是自己自建的，或者怎么着的，各种各种，但是基本上50%以上都有去尝试在内部推行一呃一个或多个的业务，在右S这样的一个基础设施，在在在在在这个演进了。
08:05
那腾讯云呢也一样，就是我们其实围绕着service这个理念呢，也是构建了一整套的从S资源，到中间的这种呃，Pass层，再到上边的这种SAS和应用层、工具站层，就构建了一整套的矩阵，它满足于不同的场景，不同的客户，不同的这样的一个业务诉求下的一个应用。所以今天的so呢，不仅仅只是讲fast，讲函数，也也会涉及到像容器啊，涉及到数据库啊啊，中间件啊等等等等这一系列的东西。那到目前为止呢，呃。腾讯云就是我们自己的这个函数的发展呢，应该来讲呢，呃，战略上还是蛮成功的，我们和小程序的生态做了深度融合，然后目前累计下来呢，也已经服务了200多万的开发者，这个在世界范围内也是最大的一个开发者群体啊。嗯，然后现在呢，我们也是和像国内的信托院也是去推了这种，呃fast这种标准认证，然后近期呢，也是在和这个电标院在推这个国家标准，像这一系列的都是在做整个行业的这种标准规规范化的这些事了，这个已经使得什么，这个也说明什么，就是说呃，Service这个理念，Fast这种模式啊，他已经跨越了，从1213年刚提出来的一种，怎么讲呢，是一种社区的一种理想。
09:26
然后中间落地了这么多年，各个厂商用自己的做法去呃，落地了不同的产品形态，这么多年到现在终于来到了一个关口，就是说业界的应用已经足够的多了。但是规范呢，其实还没有太多的这种规范出来啊，所以现在这就是从业界的落地到行业标准规范这样的一个一个阶段了，它是一个趋于成熟的这样的一种一种一种一种形态了。那这里就是大家回顾一下吧，就是呃，So来或者函数，它在技术架构上哈，它跟传统的这种我们用微服务也好，或者是用这个自己做的这种什么，呃呃库龙的这样的一个方式好有什么样的不同啊，它的最大的不同是什么呢？就是它是把整个部署的环节，就是你写完代码之后上线部署的环节做了一个完全的后置，就是传统的模式下呢，我写完代码，然后我要上线做部署，我一定是做什么的，我一定是找到一些可执行环境时，不管是容器还是虚拟机去在那个机器上去把服务提起来。
10:37
然后砌起来之后呢，确认它是一个健康的是吧，做了一个health check，然后把这个机器呢，作为back加到了我的LB里面去，然后这个l be加这个多个节点形成一个库组是吧，通过这种方式，这是一个典型的前置的部署的逻辑，就是我要把。准备好的这个执行环境。加入到一个流量分发的环境里面去啊，这是传统的这个架构，然后呢，他的cos容的逻辑就发生在说我我流量家了，那我这个时候呢，就通过一种呃，叫做被压检测的方式哈，不管是通过CPU的阈值啊，内存的阈值等等这些就决定要往这个组里面加机器还是剪辑器，这是最传统的这种方式啊，而函数呢。
11:21
它是反过来的，就是当你写完代码，呃，然后建立了一个函数之后，这个时候它其实事实上是没有发生部署的，就这时候他只是把你的代码包你的配置的这种说明师的配置的文件，把它同步到了这个一个地域下的集群里面去。然后当什么时候才会做部署呢？只有当你配置的触发器，比如说你配置了一个呃，Cost的触发器，或者卡夫卡的触发器，或者一个定时触发器，都可以当这个触发器产生了真实的调用。就是比如说你的time，你的定时发器到时间了是吧，他发起了一个请求，那这个时候呢，才会产生真实的部署，就是这个时候他才会跟呃经过这个函数的平台层，平台层根据这个请求动态的去在一个呃可用区里边去拉起一个机器，这个机器上再去把函数整体跑起来，跑完之后把你的请求路路由进去，让他执行完，执行完之后呢。
12:16
把结果返回到调用端，然后他再去决定说提起来的一个实例要释放掉还是怎么着啊，通过这种环节，它是一个完全的后置的做法，就是这样的一个区别，就使得他就可以做到按量计费，可以做到啊这样的一个超级。高的这种并发的支持，因为他是个完全动态的这样的一个过程，它不是前置的。所以。那所以它就使得什么呢？它有一个很好的一个特性啊，这个特性可能大家如果在普通就是简单用函数的时候，可能体会不到，就是它是天生的，天生的一种这个高可溶的。就是你的任何一个请求函数请求，它都是自带高可用特性的，就是你的一个请求进来，他都是会去根据后后边当前地域下的一个后边的可用区的可用情况，去把你的请求路由到一个可用区里面去的。
13:12
呃，这个和和大家的就是，虽然说大家用函数很简单对吧，反正写完一个函数，创建个函数，然后就发展这用就好了，但事实上你的请求都是会被安排在多可用区里面去跨可用区可用的这个是他的一个一个一个架构上的一个呃特点吧。这个也使得说他在呃重计算场景，特别是现在哈AIGC这个场景，大家都知道，说你做一个AI推理的时候啊，每一个推理其实基本上都在占一张卡对吧，占一张GPU卡，或者办卡四分一卡，你好，反正都是单占一个计算单元。那这个就使得说，呃，传统的那个模型呢，要不你就一开始就把这个卡准备好，然后把服务布置上去，对吧，然后就在那待着，等着你的请求多与寡的进来，但是在这个模式下呢，就使得你只有请求真的过来的时候，他才会。
14:00
帮你去找一张卡给你跑起来，所以它是可以实现很好的这种集约性和这种呃这种这种嗯响应的这种及时性，这是它架构上的一个优越性。那围绕这一点呢，因为之前函数这条路啊，或者so这条路呢，其实大家所有的厂商哈，都会把它的产品的重点放在怎么去满足开发者的这样的一个工具站上，就是怎么去满足开发者去，呃，怎么讲呢，就是成为全站工程师是吧，不管是我们做的云开发和小程序去联动，还是说语函数这种和这种后端工程师去联动，就是做了很多很多这样的工作，就是我们会关输说你怎么去写你的代码，对吧，从一行代码到镜像，从你用自己的IDE，然后或者是用云上我们给你准备好的web ID啊这些事。然后到你怎么去部署，呃，通过什么样的一个呃制品库，或者说什么样的一个存储的方式去做部署，然后以及说你部署完之后怎么去做这种版本支持版本的切换啊，流量灰度啊等等这些事。
15:01
这都是一站式的，就是他工具站的这种打磨，会花很多很多时间去做啊，也取得了一些效果吧，就是大家确实用函数可以呃非常简单的去去用，用用它的这种工具去满足，说你从一行代码到最终这个服务上线，去控制治理这个服务都是闭环掉的。但是呢，在这这些年里面我发现啊，就是说前面说的那么多啊，就是开发者会用的很爽，就是基本上你你做一个个人开发者啊，你基本上用它就够了，对吧，你快速上线一个业务，但是一旦我们把视角挪回到企业里面去，我们发现这个情况就不大一样。企业会发生什么样的一个变化呢？一个是说现在啊，就是云原生，云原生其实如果落地端产品啊，其实就是容器和K8S啊，基本上就这两个，以这两个为基础，上面会衍生出很多这种生态，那目前呢。呃，根据呃，State of flow去年底的一个报告也也显示呢，就是目前来说哈，Docker和K8S呢，也是目前最流行最热门的技术。
16:04
不管是已经采用的这种呃企业的数量，还是说准备把它纳入学习计划的开发者的数量，都是在技术圈里面是是领先的TOP1和TOP2。那另外呢，我们也我我们也会发现啊，就是他已经就是K8容器已经是企业的事实上的标准，基本上没有企业没有在用容器，或者在呃，没有一用K8S的基本上都用了，我相信在座的各位应该有这个感触的话，只是说用的多和少的问题。而一旦开始用容器或者用K8S呢，其实很多工具，包括大家的使用的流程，包括一些编译工具，一些牌照等等这些哈，都会基于他们再去做一个适配和上线，所以他基本上就变成了一个底子，就是你的容器，你的KS成了你的整个公司的研发的一个底。一个基础设施。而这个时候我们就发现S他之前强调的，就大家回顾一下S它是一个什么样的一个形态，它是一个完完全全的公有人形态。
17:05
对吧，就是不管你在用哪一家的函数啊，你在用腾讯的函数，还是在用自己的函数，阿里的函数还是亚马逊的函数。都是选择了一个厂商，然后选择了他的公有云设施是吧，这个时候你基本上没不可能想说，诶我要去做跨云，我要去做什么，嗯，这个自己机房里面的这种建设了，是吧，肯定是就是一个选择的问题了，那。但是这个是他原本的一个形态决定的，就是只有公有云的这个形态，他才能去给你这解决什么问题呢？就是这种超级弹性，超级按量计费和超高的并发的支持，因为他要靠公有的大的这种资源池去解决这个问题。但是企业不一样，就是企业正常的生产就是一开始他可能是个小团队啊，就是一两个人对吧，一个想法，一个小想法，马上做一个APP出来，然后上线，然后发现发展的很不错，就是刚刚辉哥说到那个那个跨境电商的那个case啊，他真的是一开始就是几个人，然后做跨境电商的ERP萨，然后不小心做成了。
18:07
然后招人招到100多号这个研发团队，然后开始去引入更多的技术站，然后发现，诶，这个事没有那么简单了，原本的那个，呃，Service提供的这个就是。给他们的就是一开始几个人的这个研发团队，开发者用的很爽，数据区啊，基本上就是我只管写代码就好了，到后边发现100多号人。需要做管理了，然后加上呢，呃，一旦说你规模变大之后啊，你发现企业自然而然的就会产生什么一些需求呢，就是他需要做更强的这种观测性和定制，就是他可能要去引入一些更强的，呃，这些什么调呃，排账啊，调试啊，然后一些这种业务指标，以及说维运维的指标等等，这些就是有更强的这种。呃，这种这种这种诉求，以及说他可能要去做跨云了，因为他可能业务覆盖到了海外，呃，多个地域等等这些这些都使得他必须要去关注基础设施层的事情，他必须要去，呃考虑数据合规，安全合规等等，这些就是这些都是自然而然在一个企业发展路径中会出现的。
19:11
那这个时候，如果你是一个完全的公有形态的一个技术产品的话，你必然就和企业出现了一个脱钩。这个是我们之前一直以来啊，就是没有去深入思考的，我们一直觉得说，诶我们就把开发者体验做的很好，是不是就成功了呢。后来发现不是啊，因为开发者。这个世界上没有没有完全的独立开发者是吧，很少。大多数的开发者都是在一个企业内工作的，他和他的呃同事们对吧，一起在这个企业的管理要求下。呃，采购要求下等等这些之下去完成一个项目的上线，这个才是真实的情况，所以我们如果把视角还停留在一个呃，个人开发者，全站工程师的这样的一个角度的话，发现这个其实是没有思考到位的啊。
20:00
但是我们会看到就是在这样的一个基础上哈，虽然我们发现企业在用service会遇到很多问题，比如说他的财务预算的这种这种模式啊，你的按量计费是不是适合，这个是第一个问题，第二个问题是说你的这种全托管的这种黑核的这样的一个一个计算的，一个一个一个一个环境的提供，那企业要做更进一步的调整，排排账怎么办呢？这是第二个问题，第三个问题就是我一旦有一个百人的这个研发团队了，我肯定要去做统一管理了，是吧？这个时候你你函数提供的这一整套的这种攻具站和我本身的那个模式之间匹配是不是？一定能匹配呢，这是第三个问题，第四个问题就是一旦我要做跨云了。那做不了了是吧。那但是我们又把视角挪回来，我们发现企业遇到这些问题。那函数或者S这个产品形态在满足他的诉求上确实会出现一些出入，会出现一些出入，但是企业是不是自己就能找到好的办法解决呢？我们发现。
21:01
呃，有路径，但是其实还比较难啊，那路径在哪里呢？路径就是整个现在行业里面也在推这个干的，去年，呃，去年。去年的秋天吧，11月份左右的时候，开始推了一个新的技术的这个趋势叫平台工程，大家应该相信，最近也听的比较多，就是engineering，翻译成国内的话呢，其实就是技术中台。就是怎么在企业内部搭建一个面向于业务开发者，就是不同的业务线的这样的一个内部的开发者平台，然后他们基于你这个平台去完成CCD，完成你的开发，上线，治理等等这些过程啊。呃，这个基本上在国内，其实我相信各自的企业里面应该多少都会有，是吧，只是说做的可能有点，呃，各家企业做的不大一样，然后呢，我认识的一个朋友啊，呃，也比较有代表性吧，就是他们大概是八九百人的这种整体的研发团队，然后有七八十号人是做这种基础基础设施的，就是做那个运维，呃，工具工具站，然后去。
22:06
呃，然然后做那个观测性情关这些事，然后他们就投入了。70号人左右吧，去做这样的一个内部的开发者平台。因为他集团很大，所以他肯投入这些事。呃，然后坐下来之后发现。呃，确实能够满足内部的这种研效的要求哈，但是我们发现啊，仔细去看这个事。首先投入了很多人是吧，然后出来的东西呢，我们发现好像和我们斯提供出来那个工具量也类似了啊，就是相当于他们在内部搞了一套，搞了一整套这个东西，所以我和那个朋友也聊，他们就说。这个确实是落地下来也挺开心，但是发现呢，确实投入产出比会其实不是太。好啊，如果从公司的角度来看哈，就是你花出去这么多的成本去做这个平台。然后出来之后呢，其实产生的收益呢，没有没有想象中那么好，因为就是就是整体的这样的一个收益问题，他也期望说，如果说社区里面，或者说业界有一个这种成熟的脚手家，其实就不需要每个企业去搭建了，这还是个比较极端的例子，因为他有很多人他肯投入这个事，但是对一般的企业来讲。
23:14
这个事好像不是不是那么值得自己去做啊，但是又回到那个问题，就是企业确实有这个诉求啊，他就是要。在内部要有更好的开发体验，去满足业务的业务开发，去去高效的去交付项目去推进，对吧。但是公有云的那个service呢，好像在这块会有一些出入，所以他要解决这个匹匹配的问题。但这个事怎么做呢？啊，那这个我们一想，那当然是我们来做是吧，所以我们就推出了这样的一个新的产品理念啊，就是有没有一种办法，把我们已经服务了200万开发者的这样的一个S的产品体验，把它能够原封不动的搬到企业内部里面去呢？我们满足企业的诉求是吧，他的基础设施掌控，他的这种管理模式的要求，他的财务预算等等这些我们都满足他。同时。
24:07
我们不改变这一套工具站原本在光源上的那个形态，就是做一个无损的搬迁，能不能做呢？那当然是可以做的。那我们在这里面其实在架构上做了一个很重要的一个改变。就是这个改变说起来非常简单，就是它里面其实流程上会比较复杂，我把它抽象一点说，我们做了一个改变，大家只要记住我们做了其实就一件事，这件事就是我们把原本service的内容，呃，完全的公有云的资源池这个形态。把他给呃做了一个解耦，就是说。Sola，我们可以看到它其实是两个价值，第一个价值就是开发体验工具站，第二个价值是弹性的云资源是吧，弹性的那个计算资源，所以我们把这两个价值给结有掉，就是我们尝试向企业交付什么呢？交付工具站，交付开发体验，同时不强不呃不强制要求说企业必须停留在公有云上，其实就做了这个事，那架构上呢，其实我们就是把函数的资源池这一块呢做了一个。
25:11
开关，这个开关就是企业可以根据自己的需要哈，把这个开关打开，让它可以对接到企业自己的K8集群中。这个集群不一定是在公园上，可以是比如说t ke啊，托管的这个集群，也可以是自己在云上搭出来的一个自己的K8集群，甚至是自己跑在一个自己机房里面的一个私有化部署的K8群都可以，只要网络是通的，等这些就就可以把这个呃，把它给建立起来，就是你的函数。的资源池和你自己的一个一个一个集群去去拉通，那一旦拉通之后呢，函数就跑在了你的基础设施上。可以跟着你的这种管理诉求啊，安全合规要求啊，财务的要求去走。这个就是它架构上做了一个重要的一个改变，然后在这个配置完成之后呢。那。
26:01
函数的原本的那一套逻辑，就是它完全的后置的这样的一个动态响应的，这样的一个流转的这个逻辑呢，都是做了一个完整的交付，到到到这个发自集成中的，就相当于是企业通过这种方式啊，就可以把函数全套能力搬到自己的设置上，然后跟着自己的那个。那个资源，呃，这个基础设施就走了。同时呢？呃，我们也去推出，就是因为企业一旦在用KS或者用容器哈，他多少都会，他基本上都会用KRAPI呀，RBAC权限体系这些去构建它的中台，或者构建自己的内部的这种流转的这种体系哈。那在这块呢，我们也去做了一个强制的兼容，就是把函数原本的一些云API的这种管理模，管理的方式呢，把它给改成ks c d apic，这种兼容体系，就是你可以原封不动的用你原本的中台的那套对接的方式来对接函数的这种整整套的能力。那在产品形态上呢，我们也去做了一些，呃，做了一些补充，就是原本的函数，因为它是直接面向开发者团队嘛，所以我们做了很多这种开发的开发需要去用的，比如说呃，函数模板啊，应用市场。
27:09
然后他的这套呃开发工具ID的这些支持，那在新的这个模式下呢，我们面向呃开发运维团队，技术中装团队去做了很多这种运维管理上的这样的一个能力支持啊，我们首先就是刚刚说的API啊，权限这些，我们提供了原生的K8的这种生态支持的。然后对于技术设施这一块呢，我们提供了他的这种可观测性啊，可管控的这种，呃，这种这种服务服务治理一个对接，然后以及说他的资源水位，我们也开放给了这种运维团队，他可以去根据自己的。呃，这种管理需要吧，去解决里边计算资源的一种运维的问题。那对于中大存队来讲呢，如果他要在内部的中台上去集成C这种呃这种能力的话呢，其实对他来讲非常简单，我们提供两种方式，一种呢，就是呃呃呃，K8生态，K8C生态的这种完全兼容的，就是他们可以通过CD去完成一个函数的创建和和这种管理。
28:08
就可以把自己的那种权限体系呃纳入上去，然后基本上你的内部的开发者其实是在用你的中台来走所有的流程，他可能甚至都不知道说底下是用函数来提供的，这是一种方式，还有一种方式呢，就是我们提供整套的前端组件加后端接口，一整套这种方式去供你去做一个集成。这个呢，像我们在去年的时候也和有赞落地了一个case啊，就是有赞在他的pass云，有赞大家可能知道就是做电商SARS啊，然后他们也提供给他的SV一个pass云平台，供他的SV去做这种，呃呃，小程序那个那个商店的那个什么运营活动啊，相关那些的一些组件的一个交付哈，那他就引入了函数在里边作为一种。啊，这种这种开发能力去提供给他的SV去用，也是整套集成的函数的这种能力啊，在他的动态里面，在在他的那个pass云平台里面。
29:03
而这一切呢，他改变的其实更多的是企业怎么去把函数纳入进去，供业务团队去用，而业务团队用到的呢，其实还是完整的so的这种公有云的那一套的开发体验，呃，这个业务开发其实他只需要做一件事，就就是还是之前的三步走的方式啊，写代码。然后就完成一个声音式的一个配置上传，然后然后这个这个应用自然就跑下来了，呃，平台来负责他的弹性的执行，他的运维，它的扩这些。而这时候我们也会在思考，就说企业里边哈，呃，毕竟他基本上上规模的企业，可能是Java用的非常多对吧，微服务用的也非常多，有一些可能就是基于这个微服务的框架去搞起来的。啊，有很因因为因为微服务本质上来说是耦合了管理方式的哈，就是一个企业他选择了微服务，不一定是因为微服务的架构本身有多先进啊，更多的是它结合了他整个的管理模式和研效的这种体系。因为它更好的更新力度的，可以去管到对应的这种团队哈，所以这个时候我引入S，那怎么去和原有的这一套已经跑了多年，很稳定的这样的一个微服体系去结合起来呢？那这时候其实我们会推荐啊，一开始你在内部去用的时候呢，可以去根据场景去做选择。
30:18
就是微服务的可能更多的是在做什么呢？做这种核心的这种系统管理，要求比较复杂的，然后稳定的这样业务，那对于一些这个灵活，比如说一些数据处理啊，重计算的离线任务啊，相关这些其实可以优先去用service函数来解决，这样一搭配起来呢，就可以起到。呃，就是一个一个平衡吧，就是你可以用到很用到service来来提高很好的效率，同时加速一些呃这种整体的可靠性，同时微服务那块呢，也可以保持它的原本的那个那个那个推进啊，所以这两者是本身是一个很好的结合。然后呃，因为前面说到就是我们把资源层做了解耦，使得说S可以跑在你的一个基础设施，跑到你的自己的集群上去，那在这个基础上呢，我们发现它其实可以在企业的这种用云的体验上会有一个很好的一个实践。
31:14
呃，这个时间里面分两层，第一个事件是什么呢？就是说S啊，它原本的那个按量计费，其实是在一些波动比较大的情况下，是吧，大家做一个活动或者怎么着的，一天可能来一个很高的高峰，然后晚上没有量，可能这样的模式下他会比较省钱。但是他毕竟是一个暗量模式是吧，按量模式我就是大家可能之前一直听的是什么呢？就是这种配go这个模式在呃。呃，项目上会有很好的这种节约是吧，但是大家，但是但是厂商，所有厂商都没有告诉你的是是什么呢？就是一旦你用的很多的时候，这个按量模式不一定很省钱。我们可能是第一家对外这么说的，但这是事实啊，就是大家可以仔细想一下这个事，就是按量模式实际上是什么模式。
32:02
就是散买模式嘛，对吧。就是我买糖的时候是按斤称还是去搞一个集装箱买一卡车过来，这是两模式啊，在现实生活中买糖的时候，你按颗去买还是按斤去买，价格体系是不一样的，按斤称和这个呃，大家在超市买它应该有这个经验哈。这个就是当你购买规模不同的时候，你的那个采购模式会很明显的决定你的成本支出。这个是按量模式，它必然的一个一个一个劣势。No。怎么解决呢？那他的解决方式其实就是说，呃，因为现在是两个大前提，第一个模式，第第一个前提是说我上线的业务，它必然会有一些波峰，波谷对吧，这个是这个自然情况，我也我也希望说他要非常野蛮的增长是吧，最好那个波峰能够更大一点才好，老板很喜欢，但是同时呢，这个这个。这种波峰呢，也会带来更大的这种资源的诉求。
33:01
然后同时呢，我们又发现它的整体规模也上涨了哈，每天可能都有一些这个存这有些固定的流量在跑了，那这个时候我应该怎么去用好，我们应该怎么去更好的去去做这个购，呃，这个这个云的计算资源的一个购买的，所以这个时候我们提出来就是你可以去做这样的一个自有集群。去做一个这种流量的打底，就说你对接你的K8集群是吧，这个集群里面的资源可能恰好是满足你日常的这种流量的需求的。然后呢？当你的流量，呃，今天做活动突然暴增的时候。那在这个模式下哈，我们提供了一种能力，叫做混合资源池的能力，就是你可以你可以把这个模式打开之后，你的溢出的流量会被自动调度回公有云上去。就相当于，呃，在这个模式下呢，你的函数请求会优先调度到你自己的K8集群，就对接好的那个集群上去，而一旦发现你的流量超出了这个集群所能承受的上限，这个很好理解是吧，因为你的集群不可能很多节点，那这个时候调度层就会。
34:09
自动的把你的请求路由回公有云上去，用公有云的弹性资源，那溢出这部分呢，公有云上会按照那个按量计费，就相当于是一种呃存，就是一种常量资源去用一个更更经济的一个采购，对吧，我买一些机器，买一些这个TP的容器，呃，一些节点在里边去，可能是一个很好的这种这种包月的价格啊在里边，然后满足日常需求，一出的时候呢，按照函数的按量计费，这个时候就是很好的一种结合，就是就是批发加散买啊，一结合起来发现整体的这种，呃。采购模式就很很清晰，也很也很划算了。那第二个模式呢，会更加的。呃，高级一点就是它会涉及到一些，就是如果你的集群，你的K8集群已经很大了，可能已经上万上10万上上百万盒的这样的一个一个规模集群了，那这个时候呢，所有的技术重大团队啊，都领到一个任务，可能就是他的OKR了，就是我怎么去把已有的这么大的一个规模的集群的利用率提高到一个老板满意的一个一个水位呢？
35:13
那这个时候可能就会在内部考虑一些，比如在一些混部啊，一些这个，呃，这这些方方式手手段了，但是在这些混部呢，我们发现哈，他他现在来看呢，会有一些实施上的难度，就是不管是哪一种方式哈，你会发现他会跳业务。就是所谓的在内文物，无非就是说，诶，我把我的TK集群的在线里边在线集群，因为它有波风波谷嘛，对吧，我把它动态的一些闲置资源抽出来，通过通过这种watch watch的这相关的一些技术吧，把它抽出来形成一个动态的暂时是没有资源呃在用的，呃没有业务在用的这样的一个动态的资源池。然后呢，把一些job，把一些k job标记成一个Du job，然后它就会被调度到这个不稳定的动态资源池上。
36:00
但是这里面会有个问题，就是它会很挑业务，就说什么样的job才能够被调度到这个Du的资源上去呢？因为调度到Du资源资源上去后导致一个问题，就是他很有可能这个教务会会被饿死的。就是因为有可能他马上会被回收掉嘛，就是资源会被回收掉，他就没法没有资源用了，那他就一直在那等。而在这个模式下呢，其实可以解决这个问题。因为函数的调度层是有主动感知的，就是你的一个函数请求过来，一旦说你对接了这个TK里面抽出来的这种动态的闲置资源的话呢，他会优先去看你可不可以用，如果发现你不可以用的话。他会马上调度回供有人的弹性资源池去满足这个业务的需求，马上去去执行一，然后如果你有这个资源可以用呢，它就会调度到那个Du的资源上去啊，这样就可以使得它是一个不挑业务的，就是你只要是一个普通的进线的任务就可以就可以完全的去用这个模式来来来提高这种TK的，呃，这个集群的利用率，同时呢，也能满足业务的诉求。
37:04
所以总结过来看呢，呃，整体的这一套模式哈，它满足了三个主要角色的一个价值，第一个对于企业来讲，企业其实可以更灵活的去安排自己的这一个成长的路线，安排自己用云的这一套规划，因为他会发现就是斯这样一个改造呢，就使得他没有厂商绑定了，因为他可以他他交付的是一个能力啊，他可以跟着自己的这个技术设施的要求去走，这是第一个，第二个对于企业内部的技术中台团队来讲呢。他对S这套体系从之前的黑盒的状态变成现在这个白盒的状态，他可以在上面叠加自己的这种观可观测定定制啊，这些呃，这些呃，这些需求都可以做到，然后以及说他的权限管理啊，他的这种呃资源的采购等这些都可以在这么做一个实施。第三个对于企业里边的业务团队来讲呢。那之前可能他自己项目用函数用的很爽，但是企业里边发现诶要求不给用是吧，现在来说呢，就是他拉通了这种工业云和和内部的这样的一个，呃，产品的一个对齐，就是他不管是在企业内部还是在自己的项目上都可以很好的用搜这样的开发体验了，所以。
38:14
呃，相当于说我们通过一种改造吧啊。呃，这三个大的角色哈，就是实际生活中发生的这个三个角色，能够把他的需求做一个平衡和统一。那我们内部呢，其实是有个落地的，就是因为前面也提到嘛，我们之前上云中啊，第三个阶段我们也就在内部的推，那这个也是去年我们上线的，在内部的这个可以理解为是我们内部的这个研发中台。然后呢，在里面呃，产品化了我们的函数的能力啊，作为任务平台去用啊，大家也是取得了很好的一个成绩吧。这里就就不吹牛了。我时间也快到了，然后在这个月啊，六月初的时候呢，我们也拿到了今年23年度的新能源的云原生技术创新领航奖。也是这个模式，呃。
39:01
嗯。就是就是就是这个就是一个怎么讲呢，就是这是个很难的事情，就是他其实在某种程度上是在把原本的斯一种纯理想的一种。啊，不管是计费模式，还是使用模式，还是呃开发等等这些啊，都是一个非常非常理想极简的一种模式，把它从某种程度好像把它复杂化了。对吧，就是它好像没有那么的简单，没有那么的纯粹了。所以这是它难的点，就是一旦你在做把一个原本简单极简的模型，把它拆成一个稍微复杂的一种落地的时候呢，可能就会有很多反对或者说很多质疑的声音，就是你为什么要这么去做？但是我们还是坚信这一点。就是。呃，未来肯定有一天我们会达成。一种非常非常理想的S式的这样的一个用云体验，大家可以不用去思考那么多，反正就自己的根据自己的业务需要去开发，去上线，去不用运维，然后去按照某一种合理的方式去给钱就好了，这个是我相信某一天一定会达到这样的一个状态的。但是现在。
40:07
现在不是啊，现在我们会发现很多企业他有安全合规的要求，他有跨人的需求，他有自己的。这种基础设施上的这种，呃，定制和观测的需求，这些都是自然而然存在的啊，大家企业里面一定有这样的一个需求，所以我们会想的是一个美好的技术哈，我们一定会朝着他的那个方向，他的理想方向去走，但是中间这个过程我们思考的更多的应该是怎么帮助企业。在这个过渡阶段，在这个发展阶段里边，能够用好云，用好这个技术，去帮助到自己的业务快速的增长，快速的去走，然后最终和我们一起达到那个终点，这是我们要去思考的。然后最后啊，就是我想说一句，呃，发自内心的话吧，就是因为我来腾讯之前是在一个小公司里面做CPU啊，做那个一个小的后端云平台的，也是这个方向的，也是国内第一个做那个小程序后端云的，叫直销云，可能大家没听过，那后来加入腾讯云之后呢，也是沿着这一条路一直在走，也也算是做了八年的时间了。
41:09
呃，对于sola这个事呢，我是一直很坚信。然后我相信今天讲完这个，可能会有一些同学会有疑问说，呃，你们是不是不那么关注开发者，是不是开始看重企业，开始看重企业的收入或怎么着了？不关注开发者，但是恰恰相反啊。就是我们思考的问题空间或者思考的维度会更大一点。原因在什么地方，就是。我们之前思考的所有一切都是我们怎么去通过一种技术站，通过一种技术服务的交付，去把一个开发者武装成全站开发者。这个是之前的一直的一个思考的框架，但是这个框架对还是不对呢？结果发现他对了一半。就是如果你是个独立开发者，如果你一个人搞一个团队的活，对吧，快速做一些APP上线，然后赚钱，这个是一个是他要解决的，他解决的问题，而且他已经解决的很好，对吧，他帮助了很多小程序开发者去做完他的事了，但是一旦你不是独立开发者，你是在一些公司里面去工作的。
42:11
那这个是就完全不同的故事了，那你要面临的问题就是，哎，你用这个service的东西是用的非常爽，用函数用的很好，不管是用阿里的还是用腾讯的，用的很爽，但是一旦到了一个公司里面发现不给用，你必须用这个公司给你准备好的那个开发者平台，对吧，不管他是什么样的一个流程，什么样的一个模式，你都要去被呃安排去用那个东西，不管它好不好用，反正这些这公司里面是这么要求的，他已经在那里了，是吧。这个才是现状。所以怎么解决这个问题啊。就是今天这个就是我们尝试把S通过云原生化的一个改造，让它变成一种行业里面的最佳的一种方法论，最佳的一种产品的形态，让他真正能够走进每一个企业里边。替代那个企业里边自己攒出来那个开发者平台，让他成为一种业界最优的一种一种实现方式。
43:01
这一天来到了，那大家就不用说去到A公司被用A公司的这个这个工具站去到B公司用B公司的对吧，那那你不管是在哪一家公司工作，你都会用到统一的这种思维的开发体验，这个才是我们我个人认为是。呃，真正意义上关注开发者。关注康的意思是什么呢？其实我们会关注我们做的这个技术服务，这个工具站，是不是能够伴随你整个职业生涯的。可以被你带着走的去的任何一家公司，甚至是你自己开的公司，对吧，能够帮助到你业务快速的增长的。呃，这样的一种。我是的室有刚刚分享的，其实我觉得后面他应该是蛮激动啊，因为他是从乙方到甲方，不对，从甲方到乙方，从甲方到乙，从乙方到乙方，应该是更更深有深有感触啊，就是尤其是他是真正的从用户的角度去做这这样的一个产品，包括他刚刚也介绍了，就是我们今年推出了这个service云原生的新型的计算平台，它。
44:18
真正能够帮助企业把service落地的几个优点啊，是怎么样的，他都讲的非常透彻了，就没有讲很多后台的东西，就解决了几个大问题吧，第一个就是让企业这种资源更可控可观测，对吧？第二个就是大家去申请预算的时候更有底气了，第三个从我们原先纯公有云的形态，可以到现在就是厂商中立的，不被绑定的这种就是跨云多云的都可以实现了。呃，刚刚其实我相信大家现在也有很多问题要问啊，刚刚群里面也有人已经在接龙了，包括这种时间案例啊，包括一些技术上的一些问题，那我们现在就进入到问答环节吧，呃，三个有奖问答，因为时间有限啊，所以我们要留给后面的那个讲师，那是由你来抽现场的问答吧你。
45:06
对第一位是吧。呃，感谢主持，主持人，还有这个嘉宾室友的这个坦诚交流，确实呃，你提到的问题我们都面对过，就是首先用这个service，刚开始是很快的启动，那业务稍微到了一点的，到了一个点的以后，就会发现这个并发是个大问题，然后成本是个问题，所以现在我们考虑的就是进行这个混合云。混合云，呃，考虑到我们这个也是To B的，我们客户主要是那种涉及到边缘计算的，比如说那个辉总讲的说这个零售行业，零售行业是，呃，比如说每一个像71，每一个店的话，它必须有一个边缘节点，这个低延迟它是受不了的啊，假如都放在云的话，所有的数据都趋匀的话，那假如说这个云，云这个这个光线被挖断的话，他业务就没法走了，所以他一定是呃这个边缘加云的，OK，所以你你后面提的这个方案我觉得非常呃有趣，就是进行混合组云，但是我确实没听懂，呃，现在我们主要考虑的其实方案是那个，呃叫KKESD这样一个方案，就是亚马逊的云进行解绑，然后他2020年开始开放出来的，那我听了半天，其实没听懂，说你这个，呃，讲了一个前景，那怎么怎么，就比如说我们就落地到71这样的一个连锁平台，它中间有一个，呃，整体的这。
46:34
一个物流的控制中心，It中心，然后每个零售节点，它有它的边缘计算，在你这个新的技术技术框架下，它怎么运行呢？请问。谢谢。嗯，这是一个很好的问题啊，但这个其实是两个维度的问题啊，就是一个呢，就是边缘组云或者怎么着呢，这个其实是网络加这种，呃，机器的那管等这一系列的问题嘛，对吧，那这一套呢，其实是说怎么在这个基础上，就是你已经完成了组网，你已经完成了这种机器的纳管了，就是拉成一张网的时候，怎么去把原本只跑在公云上的一套函数的这套，呃。
47:16
这种支撑的服务啊，那的就是那那那整的能力吧，从公园上把它可以跑在呃，你这个边缘上纳管进来的这样的一个基础设施上。但这里面其实有很多细节，包括里边的，呃，这种网络互通啊，权限啊等等一些其实会有，就是就是就是咱们这个问题其实要来到说把搜这种能力拿上去，其实还是有很多很多的坑要去坑的啊，没那么简单这但是这确实是个比比较有有意思的一个case。这后面其实。也可以在继续聊啊，深度聊一件事。对，那个送上我们的礼品，下下下一位还有两个机会。
48:02
你好，呃，我是仔细看了我们的系统架构，我想问一下，就是service的平台云季度架构嘛，嗯，他有没有一些安全性的产品，因为这些方式呢，都是跑在云上，然后企业对那个网络的接口的安全啊，还有那个呃，系统安全，数据的安全是有没有相应的产品去做保障的，谢谢。嗯。这个确实是一个好的问题啊，但是这里面呢，我们会说到两个点吧，第一个就是刚刚的架构呢，其实是他第一个形态，就是说他还是从公有云作为一个中枢，呃，就是你的调度是先走的公有云，然后公有云再把它路由分发到你自己的那个K8S集群中去哈，那这个时候呢，它的安全措施目前呃，最简单的方式其实就是拉那个专线内网了，就是直接把他VP封闭起来就好了，然后还有一种模式呢，其实我们也在后边会尝试去推，呃，但是这个时间表呢，还没有那么快，就是把它作为一个整体能力交付给咱们的K8中。
49:05
就直接闭环到咱们的集群中去了，这个时候其实就不用太去考虑说这种网络互通的这种安全问题了。那个其实。呃，也会在后续吧，就是我们会在跟一些大的大的这种企业客户会去联合去做这样的一个落地啊，到时候呃，有一些case之后我们再拿出来跟大家分享。还可以，还有一个问答机会。中间那个。好，谢谢那个何总，我就问一个问题，刚前面有这个伙伴小伙伴已经问到了安全相关的问题，比如我们原来的一个物联网行业。呃，他关注两个问题，第一个是。呃，安全的认证。对吧，关于各类比如类似担保这种安全认证，在咱们这个方案呢上面，他怎么合规性的通过这些认证，这是第一个问题，第二个问题。
50:06
比如说物联网在走别人计算这个趋势非常明显，咱们用混合云或者叫云雾或算的模式下，有没有可能从我们的service逐步的走向attitude这种这种这种模式，对，这是我的问题，谢谢。呃呃呃，不好意思，那个第一个问题能能重复一下吗？就是你说的那个安全认证是是指哪一个方面的安全认证，等保类的这种安全认证，一些合规性的强制性的认证，行业上对呃呃能能稍微描述的具体一点吧，就是他的这个合规安全是发生在什么样的，就是是一整个的这种落地的，对他的整个落地的方案的解决方案的一个综合性的认证方案，他可能会考虑各种细节，以及从网络到我们部署，到我们的服务的构成，甚至到我们的底层的支撑的基础设施，软件基础设施，它都会有一些要求。
51:05
对啊，明白明白，第一个问题其实其实和刚刚回到第二个问题有点类似哈，就是对于等保这的这种强要求哈，其实估计也只有闭环交付的这一个解是会比较满足的了。就是一旦涉及到那种公业员和私人之间跨网之类的，这些其实都有点难啊，但也不是说，也不是说不一定，也不也不是说不能落地吧，但是如果说为了做这种等不好交付话，一般来说也是正确的要求嘛，对吧。估计是第二个模式会好一点，就是我们做整体变化交付，就直接把它整个能力呢私有化，交付到你的那个集群中就好了。然后这块应该是比较好去完成那个那个登保要求的，嗯，第二个问题是我物联网那个，呃，就是那个h function相关的这些事是吧。啊，明白就是边缘的。嗯，其实边缘计算我们也一直在关注，但这个事我也坦诚跟大家聊一下，就是边缘计算呢，目前我们发现啊，国内的这一块的应用会需求吧，没有国际上那么多，因为国内其实整体的网络好像比国外要优秀一点，因为整个中国加起来，比如说从北京到广州这样的一个华北到华南之间的一个延迟，其实也是在百毫秒以内嘛，对吧。
52:22
所以他的这样的一个跨跨地域哈，就是南北东西的这样跨地域的网络比国外要简单很多，像国外可能你很很快就会发现，比如说从这个呃新加坡到到到比如说这个欧洲一点的地方，你就发现跨境了之类的这些。所以国内好像。就是边缘计算这个事，就是我们一直在尝试在内部是不是找到一些什么方式，呃，一些需求能够快速去落地一些，因为比如说比如有时候那种h function啊，啊相关这些其实也落地了好多年嘛，对吧，亚马逊的我们也一直在筹备，但是确实目前的需求量还不是那么多，这个是一个现状啊，这个也是很坦率跟大家去聊这个事。第二个呢，就是呃，技术上其实没有什么太多的卡点，因为变量计算的一个整体架构的方式，和咱们聊刚刚聊的这个还是不一样的东西的，他可能更多的强调的是说怎么去把云边，呃，就是边缘的这个算力能够去做一个，呃调度上的一个纳管嘛，能够去联动起来，对吧，我中央的这种那个，呃，请求一些任务能够下发到那个边缘上去是吧，这块其实架构上来说没有太多的难点，而且我们也已经和像我们的CDN团队啊，我们的BM团队其实有一些深度的联动嘛，其实就是在等一些机会，等一些具体的这种客户能够去把这个方案能够落。
53:42
下去吧。好，谢谢室友，那我们第一个议题的互动问答就先到这里，请邱总，好，嗯，那今天我们的议题是service啊，那其实刚刚也说到云原生的一直是主流，那接下来下一个议题的话呢，我们会聊一聊service个容器的。
54:06
这一个趋势的发展下，怎么样更好的去契合用户的诉求，呃，我们自己腾讯云的service容器服务呢，在内部的资研场景中已经有很大规模的落地跟应用了，包括也获得了很好的一些降本增效的一些成效，呃，我们现在呢，就是也希望把内部的一些经验向对外去更多的推广，然后那我们其实在过程中也发现了，就是客户很认可这样的一个价值，但实际落地很难，落地的效果也远不如预期，所以呢，今天我们邀请了我们service容器产品经理冰心陈冰心同学来给我们进行分享，怎么样用新形态助力service容器快速落地，有请冰心。呃，首先感谢一下室友的分享啊，室友开了一个好头。
55:00
至于那个分享的精不精彩，我们就看今天有没有人睡着嘛，我在第一排，反正是没有听见呼噜声，所以应该还可以，所以我感觉我现在的压力也小了一点，然后希望大家也可以再接再厉保持一下，因为现在已经过了那个睡觉的那个时间了哈。呃。大家好啊，我是那个腾讯云TK service容器服务的产品负责人，我是陈明星，呃，很高兴今天有一个这样好的机会，能够在大在这里跟大家探讨那个service容器相关的内容，因为我今天分享的主题是新形态怎么助力service容器快速落地，我们之所以想要做这样一个选题啊，是因为其实我们呃辉总也讲到了，是因为我们在实际服务客户的过程中，我们我们意识到service的价值传递其实已经做的很好了，包括在座的各位可能都已经听过或者是上手用过servicers的服务了，但是实际上呢，Service在企业的落地仍然非常的困难，我们其实也深入的思考了我们这样一个原因啊，但是呃，并且我们在后续的产品设计里面也把我们思考的结论，然后融到了我们的产品设计里面，我今天呢会想要通过分享一款，呃。
56:23
呃，就是融合了我们思考的产品的，呃，Service容器服务的一个产品叫超级节点，来将我们做产品的思考分享给大家，其实今天的那个分享啊，我是希望大家有一些呃相关的service相关的一些经验，我不知道在座的有没有，呃有多少人维护过标准的K8S的集群啊，可以举下手吗？呃，然后有大家有有有真正用过service容器吗。可以举下手吗？OK，我看感觉还还可以，就是那个，因为今天因为是希望通过从问题里面像那个带入到，然后带入到我们的产品设计，所以如果大家有相关的经验，可能会有一个比较深刻的体会啊。
57:16
那接下来我们就开始今天的演讲，我会从五个方面带来我的分享。首先我们想要探讨一下service的需求是怎么样产生的，以及他在我们自研的场景下的一些成功的应用，以及在企业落地中的一些困境。为了应对这种困境呢，就是腾讯是怎么从产品设计上去解决这样的一个问题，然后这种新形态的产品设计下面，我们是怎么保留service原有的一些价值，并且为它赋予了新的价值。此外我就会从我们的通用场景的出发，然后去介绍两个真实的一个案例。最后，因为今天是service加AI的主题嘛，我也想聊聊我们在service容器场景下运行AI类应用的一些优势。
58:07
好，接下来我们就进入第一个部分。其实随着云原生行业的普及，还有经济大环境的一个变化，企业用户其实对于基础设施提出了更高的要求，包括我们在GA的报告中也可以看到，在2025年，其实将有95%的企业应用会部署在原生平台上。在202022年2021年，我们在服务的客户过程中也发现了我们大多数的客户其实已经直接选择了云原生上云的这种方式，并且对云原生的算力提出了一个新的需求。首先我们的客户是希望能够进一步的去降低他们的运维成本，然后提升他们的开发开发效率，去关注于自身的一个业务发展。同时啊，面对那个复杂的一些用户行为，然后他们希望能够轻松的去应对突发的状况，然后保障一个业务的稳定，第三个就是在一个现在的大环境。
59:14
就是大家都有一定的压力嘛，然后有一些降本增效的一些诉求啊，用户希望能够持续的去优化我们的运运运营的，呃，用云的成本来塑造企业的长期的竞争力。呃，所以其实在市面上有一个。有一个很好的解决方案出现了，其实针对这样的需求和趋势，行业给出的解决方案其实就是service容器服务，他全托管，然后自适应的弹性，按照按需付费的这样一个特性，就很好的契合了这样客户的诉求。在我们在其实在一八年的时候就已经推出了service容器服务，然后逐渐在内部的大规模进行落地，刚刚是有也有提到，其实腾讯会议通过使用service服务就已经实现了半个小时扩容十万多核规模，在疫情的期间，也就是呃服务了千万的客户，然后二三年至今，腾讯内部使用service容器服务的规模已经到了千万盒。
60:23
其实我们可以看一下service服务在在腾讯自研的应用的情况，其实最初自研大规模的去上service容器，其实有两个方面的原因，第一个考虑其实是稳定性的考虑，在标准的KS模式下，大家可能可能知道就是pod之间它是共享内核的，然后隔离性也天然就不足，然后有一些资源争抢的问题，因此带来业务的稳定性问题。然后最严重的时候，我记得当时我们有一个专门的。
61:00
就是负责内部自研客户接入的容器平台，然后他们每个月要接十几起的那个稳定性的工工单，然后业务也严重的诟病平台的稳定性，然后都不愿意签上来，然后这个是一个稳定性问题的大前提，然后第二个问题其实是从平台的角度出发的，就是呃，资源的利用率很低，在腾讯云的大盘上，大盘的碎片母鸡持有大量的碎片资源，然后碎片资源没有办法很好的去。利用起来，然后K8S集群本身的装箱率也不高，在保证，因为要保证业务的稳定性嘛，在保证稳定的前提下，资源的利用率的上限就天然被限制了。在这样的背景下。我们就选择了service容器的方案，让自研的业务全部都切换到service容器上，然后可以大家可以看到中间那个图，就通过呃，使用轻量化的虚拟化的隔离技术，然后我们用统一的调度技术和nonu的架构，不仅极大的提升了业务的稳定性，还解放了专门的节点运维。从平台侧的。
62:12
角度出发，呃service容器消耗了大盘差不多两千万盒的呃碎片资源，然后一年为整个腾讯云节省了五个亿，在服务自研的过程中，腾讯云service产品也快速的呃，产品能力也快速的成熟，同时解决了很多兼容性的问题，因为我们有很多就是千奇百怪的自研的业务，大概有100多个吧，就那个每个自研业务大概就是一个小公司，大家可以理解所有的小公司全部上到容器平台上，我们要解决的呃兼容性的问题，为了保证这些呃各种各样的资源业务能够无损的接进来，我们就体会到。我们体会到S的容器啊，其实它是一个好东西，但是它能呃，它能够实实在在的去提升稳定性，还有帮助用户去降低他们的资源成本。
63:13
但是啊，我们把这些在自研的场景中积累到的相关的经验，对于外面推广的时候却发现了瓶颈，嗯，他发现发现他在自在那个客户的场景中很难落地，用户使用的效果其实是跟预期不相符的，我记得我们在接入的时候，呃，大概是二一年的时候，我们有一家头部客户，其实当他们当时就是在一个激烈的行业竞争的状态嘛，为了加速他们的业务发展，需要快速的去响应用户的需求，去提升他们的经营效率，然后经过调研之后呢，他们就认可了service的价值，然后并且认同service能力，然后决定去做这样一个大规模的使用。
64:03
但是立即他们就面临了一个问题，因为他们之前的那个架构比较老旧，然后他们的业务运行在多个K8S集群上，如果要切换到service集群的这种这种架构下，它需要新建service集群，实现跨集群的这样一个服务，发现配置，同步，数据迁移，还有等等的日志啊，监控的解决方案的对齐，然后他们的对于他们来讲就是风险很大，然后挑战也很高，然后投入很多，当时耗时了数月，终于就是咔咔咔就把那个业务全部迁移到那个service的架构上面，然后决定深入的去使用service的特性，然后很快的他们就迎来了第二个问题，其实第二个问题主要是因为呃，Service的一个优势带来的就是service。其实。
65:00
嗯，全托管嘛，然后自主弹性，但是维护的维护的负担变小了，但是因为没有节点，他们不能登录机器，排账也比较困难，然后自动的弹性伸缩，虽然不用预购资源了，解决了buffer的问题，但是有弹性的突发扩容没有成功，就影响到了业务，然后他们又要退回到刚开始的那种手动的那种弹性的那个模式。然后到了一直使用，就是这样磨合兼容的使用，到了年年末的时候，客户又发现了新的问题，其实成本优化的效果也没有想象的那么好，那为什么呢？因为是service，使用service后，业务去随意的进行扩缩容，每一次业务变动会导致成本的变化，然后运维和财务对成本的控制力就变低了，然后最终导致，呃，就是service带来的成本优化的效果不及预期，甚至是不可控。这个就是一个典型的同service，传统的service就是采用传统service去实现service架构的一个案例。service确实它能够帮助客户去提升他们的经营效率，优化成本，但是本身因为它的应用存在一个局限性，其实并不是非常完美的一个这样一个一个架构。
66:27
同时客户要转型的话，就天然面临了一个比较高的一个迁移的代价。嗯，我们希望的service是什么样子呢？就是用户可以很轻易的用起来，然后给客户创造收益的时候，不要为客户带来新的束缚，然后。其实对于企业而言，他们从标准的KS到service的架构是有一个巨大的鸿沟的，我们希望把这个鸿沟给他抹去，我们希望能够对service的形态进行重新的思考，让他更能够契合我们，呃，真正的企业客户。
67:09
其实，呃。句子我们可以畅想一下哈，我们畅想一下理想的so形态应该是什么样子的，其实我们期望它是超越现有的产品形态的一个局限的一个产品，因为我们其实刚刚是有分享了，也也有聊到，就是我们整个原生做so产品的理念啊，就是我们不希望拘泥于某一个既定的产品形态，而是想要聚聚焦于客户的业务，去真正的让客户能够使用起来。然后我们希望他不仅仅有service的优势，也有服务器形态的优势，我们希望用户可以轻易的使用，给客户创造收益的同时不要带来束缚。希望可以向我们理想的。
68:00
就是最终理想化的那个service一样去灵活使用，然后也可以呃成本可控，去能够稳定和弹性高效的去使用我们的service。呃，腾讯其实呃就给了一个答案，其实我们叫它有节点的service，也是我们全新推出的一个产品形态，叫超级节点，它是嗯作为TK集群中的一个节点的类型，用户只需要在标准的TK class集集群里面去添加一个超级节点，就可以开启service容器服务的能力。这个标准的集群的意思啊，就是它是遵循标准的KS规范的，无论是呃，无论是云上的标准的集群，还是说云下的IDC的集群，呃，纳管的集群都可以去呃以这样的方式开启service服务，我们去把任意规格的service容器打包成了一个超节点去进行管理和付费。
69:09
用户的使用，用户的使验，使用体验就比较像管理一台超级大的CVM一样，去管理我们的service的资源，他可以像像CVM一样购买扩容，保持有服务器的一个管理体验，但是呢，他们这个这个节点内调度的pod其实是一个子机，它实际上会直接将容器调到我们底层的service的资源池，然后其实是大家看到跟noe其实是持平的一个物理机上。然后同时去实现了无服务器的这样一个免运维的能力，而且支持有服务器形态下的一个管理体验，嗯，单个超节点上我们现在支持呃，5万盒的资源，然后在单个节点上我们也支持了混合计费的模式，可以去打包购买预付费的资源，也可以弹性使用后付费的资源。这样的设计有一些好处，我们可以在下面的内容中提到。
70:17
其实这样的形态有什么优势呢？在大家都知道，在标准的有节点的KS模式下，节点的运维很复杂，弹性扩缩容的效率很低，其实资源增强也导致稳定性的问题。但是节点维度有一个好处，它就是它的管理是清晰可控的，它的成本核算也很简单。在传统的SRS模式下，迁移变得很困难了，成本也变得不可控了。但是它使用灵活，就。就传统的note模式跟传统的service模式都各有优，优势也也各有劣势，在超级的这种模式下呢，我们期望去融合呃，传统no模no no，传统note架构的一些优势，然后去融合service的一个一个优势，然后减轻运维负担的同时啊去嗯。
71:18
给大家带来了四个新的一个特性，首先其实在我们这个架构上可以做到自由切换，在兼容性和统一调度上我们去做了很多工作，能够让他拆掉迁移的门槛，让所有对so感兴趣的用户都能够无缝丝滑的从传统的架构自由的切换到service架构上，享受新service技术。其次，这样一个节点的设计能够让资源管理和成本管理变得可控起来。我们进一步赋予了它任意维度一键启停的一个可观测性的能力，然后也没有像之前service一样是一个黑盒的状态。最后一点是我们在稳定安全性上所做的保证。
72:08
这个是我们当前service的一些价值，然后新的这个形态是怎么样兑现service的价值呢？下面我从四个方面，就刚刚提到四个优势，从四个方面向大家解释我们新的产品形态是怎么样兑现价值的。在前面的案例中，其实客户选service的容器的时候，最大的挑战其实不是service本身能力的问题，是迁移成本的问题。我们发现大多数客户没有能够成功的使用service容器，是因为巨大的迁移成本导致的。比如传统使用service容器服务，它需要新建一个集群，然后迁移他所有的应用，还要考虑一些兼容性的问题，客户使用标准的传统的service容器里面是没有节点的嘛，因为没有节点，所以它天然不支持原生的，呃，比如说set啊，或者是特权容器，一些依赖节点的能力。
73:12
而客户使用标准的K8S的时候，往往又依赖这些特性，所以他们就没有办法去做到无缝的迁移。超级节点是集群中的一种节点的形态，所以它支持在任意的K8集群中添加。前面的图里面其实我们也有看到，只要标准的K8集群，无论是T1的、IDC的、云上的注册集群都可以添加我们的超节点。然后这个节点的形态能够让service以一个呃一键加入的方式进到集群里面，那么我们的统一调度的能力就能够让呃，Service真正的。让一个po真正在serve和serve，呃，Server for之间去做一个自由的切换，其实我们一直在思考，就是serveness到serve four到sness，是一个a and b的关系，还是说是一个A货B的关系，其实最后解答的时候，我们发现它其实是一个and的关系，就是包括我们对统一调度的思考也是这样的，我们认为调度器其实是一个资源选择的方式，就是这个调度去会去选择那个对。
74:31
无论是成本也好，或者是对资源的那个呃部署也好，是一个最优的方式，我们希望调度去起这样一个作用，而无论是调度的底层的资源本身是怎么样构成的，而调度是一个统一的一个规则，这个时候。嗯，我们就在，呃。我们我们在标准，在那个标准的集群里面去做了统一的调度，能够让用户选择pod，在service和server中间去切换，然后。
75:09
当然这个切换有一个前提啊，这个前提就是我们这个超级节点的兼容性跟标准的KS是一致的，这种时候呢，Po才可以，我们的业务才可以在这个不同的资源上去做漂移，然后我们针对于呃最佳的K8兼容性去做哪些工作呢？其实第一个就是呃，我们发现用户对DS的依赖比我们想象的更高一点，之前我们在做用户迁移的时候，发现他们总是因为set去有有有上云或者是有上service的顾虑，所以我们在KS上原生去支持了S部署的方式。嗯，特权容器还有更多的一些KS的特性，都是为了能够统一调度去去做的一个设计，就客户不需要任何的改造，只需要对po进行重建和调度，就可以完成service到serve的架构的切换，如果原来的，比如说他从原来的服务器调到service模式上，如果云服务器上有资源空闲，他又可以再调回去，然后。
76:24
超级点去通过统一的这样一个调度技术，还有业界最佳的一个KS的兼容性，能够让企业去随意的选择service和service的资源，然后我们认为这个才是service能力真正应该去具备的，就是去随意的选择资源，基于统一的调取给到最优的资源，这个最优的资源可能是成本上的最优，也可能是资呃资源供给上的最优。
77:04
第二个点其实。其实是管理上的，这个管理包含了运维的管理，还有财务的管理，在嗯，在超级节点上，我们希望让运维和财务的管理变得更简单和可控，呃，之所以会想要去做这样一个事情，主要是在传统的有服务器模式下面，我们通常需要去预估节点维度的一个资源消耗，用户的资源的使用也是不灵活的，有一些业务红峰的时候，他们需要添加节点，然后拉起泡的扩容艰难，然后业务流量下去的时候，缩容的时候要去把节点退掉，然后节点上的资源需要全部驱逐才能去退还，然后为了保障业务的稳定性，在。呃，用户不得不去提前去储备一些buffer的资源，然后就会造成一些资源的浪费，其实所以这种有节点的模式下的问题，导致了传统的模式的诞生，它解决了比如说资源浪费的问题啊，还有解决了使用灵活性的问题啊，但这种模式下，因为只能按照po的维度去规划资源和预算，对企业的运维啊和财务都带了很大的挑战。首先其实按量计费模式下财务就不可控了，业务的变动就直接影响了财务的核算，业务没有使用，没有约束，其次就那个计费的对象从pod变成了。
78:36
呃，从那个node，传统node变成了pod，然后这个资源数量就膨胀了十倍百倍，其实带来了很大的管理成本，然后我们就意识到，其实传统的service中，资源管理的精细度与资源管理的复杂度其实是相悖的。呃，他们有一些不可调和的矛盾。精细化的资源力度其实必然会带来沉重的管理负担。对此，我们其实将资源规划和配置管理上移到了节点的维度。
79:09
指数级的降低了资源运维的复杂度。此外，我们将海量的pod进行打包去管理，同时在超级连上实现了全新的节点混合计费的模式，让资源管理灵活可控的同时又有最优的成本。业界常规的service的，呃，通常是按需计费的嘛，按量计费的。前面提到的案例中，企业原本有数十个、数千个业务容器运行在数百台的主机上，迁移到service容器后，他们的计费对象从主机变成容器，计费模式也从预付费变成按量计费了，然后费用账单每个月膨胀了几万，膨胀到数十万条，业务的每一次发布都会引起成本的变化，导致成本失控。为了解决这样的问题呢，我们在超级点中实现混合计费的模式，既支持对超节点进行打包预付费，也支持对超出的那一部分啊进行按量计费。然后对于预付费和按量计费的规格，我们有配额的，配额的控制，在资源的实际规划和使用中，业务去对稳态的业务去进行预付费的配置，对。
80:28
与弹性的业务去进行后，呃弹性资源的配置，其实在这个配置到达一个平衡的时候，他其实就会拥有一个呃最优的成本。这个其实我们给他起了一个名字啊，叫黄金分割线，就是你使用每个月使用资源多少。去买包月多少买按量是对于你企业是最优的，其实这个是一个数学题，但其实很多企业客户是算不明白的，因为他们的数据是不断的变化的。
81:01
然后我们去做了一个能力。就我们会基于finds去基于你的历史附带去做一个呃，你的资源的一个呃观测，然后基于你不断观测的值，去帮你去计算这个黄金分割线，然后去。推荐这个黄金分割线，然后你可以去基于你购买的包月和按量资源的配合进行一个动态的调整，这个动态调整是什么意思呢？就你每个月可以调一次这个额度，但调这个额度并不会影响你实际在跑的所有的业务，它是动态无感的。嗯，我们不需不需要重建你的任何的业务。其实整个的设计我们是希望从呃在灵活可用的基础上去帮助用户能够进行最优的资源配比，然后能够达到成本最优，然后这个也是我们在财务管理，还有呃运维管理上去做的一些工作。
82:11
超节点的另外一个优势其实是可观测性增强，其实我们在前面有提到，嗯，为了快速的去应对市场的变化，企业往往会选择微服务的架构。但其实。微服务架构的改造，框架的维护，还有故障的定位，就对企业来讲有很大的一个负担，传统的service容器，它其实没有办法去帮用户解决这方面的问题，或者是他可以解决这方面的问题，但是它的成本非常的高，他需要去额外的对接一些比如说可观的性的一些产品，然后去自己做一些这方面的能力。然后我们超级点商就看到了这样的一个诉求，以及看到这样一个对接的问题，我们在超级点内置的unit agent内去集成了service的能力，然后我们能够让业务不需要任何改造就可以在任意力度去完成这个。
83:14
呃，服务治理的那个能力的开启，然后这个细力度就是说我们可以控制到呃，Workload或者是po的维度去开启这个能力，然后我们在这个稍微节点上支持了四层和七层的可观测性，嗯。而且四期层是分离的，然后治理能力也和观测能力都是独立化拆分的。比如说如果你想看各个word之间的调用信息，可以去默认打开我们的四层的能力，呃，此时产生的性能开销很小，我们内置的就是内置的这个面比比传统的通过s car主的面性能要好40%以上，其实可以足以的支撑日常的开启。然后在一些特殊的调试，还有排账的场景中，我们也可以在破运行的过程中临时的去开启这个七层的能力，提供丰富的一个应用层的信息，辅助我们去发现和解决问题，然后在任务结束之后再关闭，这个过程完全不影响po的运行，不会带来额外的开销。
84:28
然后在超级眼中去内置的能力，其实是传统的service容器没有做过的事情，我们通过可以随意随意开关的一个设计，其实也是想要把这些呃产品化的能力能够以更低的成本带给用户，我们不希望用户使用了一个service产品之后，还要通过去呃技术性的去对接另外一些产品，才能够达到在呃一些可观测性的效果。
85:01
这个是服务的能力，最后其实我看大家其实也很关心，嗯，今天也很关心安全的问题啊，其实我也想额外强调一下安全稳定，其实保障业务的全方位的稳定，才能够让务让用户没有后顾之忧的去放心的把业务放在云上，因此其实我们围绕稳定安全也做了很多的设计，其实可以说一开始我们就把安全放在了整体的架构的设计里面，在标准的嗯，有有服务器的KPS模式下，其实很很容易发生资源争抢，还有容器逃逸啊，然后包括像网络安全，容器安全都是需要额外的自行集成的，然后不稳定也不安全，传统的service模式下，我们只支持了pod级的资源隔离，如果要想进一步提升网络啊容器的安全性，需要自行的集成一些相关的组件，相关的呃，云上相关的产品能力。
86:02
其实在超级链模式下，我们通过了多维度的技术优化去实现了零干扰和零逃逸，也为业务带来了全方位的稳定。这也是为什么当时自研的业务上到service之后稳定性有很大提升的一个重要的原因。在基础设施的安全层面，呃超级点其实依托于沉淀多年的强隔离的虚拟化技术，然后我们自研了一个容器沙箱叫黑了，嗯，这个沙箱的运行其实是完全不依赖嗯母机文件的，不依赖内核，然后也没有泄露的风险，比开源的一个沙箱是更安全的。然后在应用的安全层面，我们也无感集成了呃腾讯云的呃容器安全的服务，然后有数十年的安全服务经验去为业务的安全去负责。嗯，在流量的安全层面，其实超节点我们后续通过无感支持零零信任网络去保障接入层的安全，包括我们在呃以EPF实现单个pod的控制面网络和业务网络完全隔离，互不影响，这也这也对我们网络的安全性做了一个很好的保障。然后在稳定性层面，超节点我们刚刚其实前面的架构里面也提到，我们单个pod对应的是独立的子机，其实资源是完全隔离的，然后业务间也是零干扰。
87:40
刚刚其实。呃，通过落地上面的这些产品特性，我们逐渐突破了service容器落地很困难的这样一个困境，在过去两年我们也落地了数百家的企业客户，然后我在这里也想就各就我们典型的场景给大家介绍两个案例。
88:05
第一个是在线稳态的场景下，这个是呃，搜狐集团的案例，然后搜狐和手机搜狐在2021年的时候就已经规划切换到service容器服务，他们的诉求其实是免运维，然后降低成本，然后他们自上而下去推动落地的时候，嗯最初就进展很缓慢，遇到了运维团队，比如说呃，顾虑很多，比如监控日志啊，DS组件不兼容，然后业务团队他们无法接受他们核心业务的中断，然后财务团队也无法按照也有规范的审批预算和费用的问题，然后他们找到了腾讯，然后我们通过。呃，Service的方案就是通过超级眼的方案，然后让运维团队并不需要在重建集群，而是在原有的TK集群里面去添加一个超级节点，然后他们用两人天就完成了整个架构的适配。然后并且将业务容器逐步的。
89:09
渐进式的调度到超级点上来，实现了核心的服务零中断这样一个诉求。在成本上呢，客户同时使用了超级点的混合计费的模式，他们包月的部分对应文态的需求，按量的部分对应弹性的需求，整体成本大概降低了25%左右，同时他们的流程管理也变得很简单了，客户的财务主要是当时取得了客户的财务还有运维团队两边的认可，所以这个这个case还是很就是很有借鉴的意义。这个事其实因为因为为什么首先想讲在线和文态场景啊，就大家大家对于service有一个有一个误解，总觉得他好像只适合弹性的场景，但是其实service的稳定性啊，还有包括低成本的资源，其实对于在线稳态场景也依然的很适用，然后第二个在弹性场景下，其实超件对用户而言，它的价值就是免运维，然后弹性的成本很低一点，然后弹性能力很高效，在我们接入的客户中，其实比如说他有一些呃有规律的波风波谷业务的时候，就使用了我们呃弹性的呃service的资源，那它问题之前问问之前使用前的问题是什么，就是用户。
90:33
弹性伸缩很慢，然后扩容的稳定性也比较差，然后弹性伸缩慢，主要是因为它弹no的时候，因为要受首先起节点嘛，然后在节点里面去拉起服务，它弹性伸缩就会C会更慢一点，然后再。在在切到service架构之后，他们就不需要运维节点，我们也不需要首先启动节点，直接就弹出来，就是po，然后弹性的速度是提升了200%的，然后弹性伸缩效率也提升了，然后同时也提到我们架构的稳定性，也保证了他们业务的业务的一个稳定性，然后扩容之前因为扩缩容。
91:14
在运维手动操作的前提下，他们的扩容也经常的出问题，然后自从切到service的场景下，他们的扩容造成的稳定性问题就已经降到零了，然后包括在整个弹性资源的使用上，呃，通过合理的弹性资源配置之后，他们整体的成本是降低了30%左右的，就在高峰期的时候也不需要添加node，然后我们的极致的弹性伸缩能力去可以快速的扩容pod，保证用户的业务高峰没有受到影响，然后低峰期的时候就可以直接把这些pod销毁，相较于长之前的需要去呃驱逐业务然后退掉机器来说，这里是有一个很大的时间差的。
92:04
这个是弹性场景的一些呃落地案例，其实今天后续可能会有很多AI相关的分享，在现在大火的AI场景下，Service容器服务其实也有一些独特的优势。其实我们将AI的流程去进行了一个梳理啊，大概简单的可以划分成这几这几个阶段，然后各个阶段service容器都可以做一些事情，首先我们AI需要去提交一个任务嘛，在service容器平台上，呃，它的任务部署是很简单的，管理也很方便，我们也提供完整的教程去完成，用户在控制台上或者是通过去部署常见的应用，嗯，让他的应用跑在SS容器上面，然后在资源的创建层面，然后service能够保证用户部署批量任务的时候能够做到极致的弹性，在资源的供给上，我们支持1/6卡到八卡的多种的资源规格，以及多种的资源类型，比如TA100A10等等不同的资源类型。然后在。
93:17
为在在资源的保障上，我们也在资源的稳定性上，我们为每个pod也提供了虚拟机级别的隔离，在完全无需运维底层GPU资源的前前提下，能够稳定的享受GPU的服务，我们也额外支持了，比如说像坏卡检测，还有多po帧，呃，通过rdma通信这些额外的能力来保证们的。我们的训练是我们的资源使用的效率是很高的。然后第三个就是镜像拉取，我们在因为AI的镜像一般很大，镜像拉取的时间一般耗时很长，这个时候如果是呃。
94:04
呃，需要光是拉取镜像其实就要耗费很久的时间，嗯，在超级上我们的支持了账号维度的全域的镜像缓存后，通过去提前把制作镜像缓存下来，然后训练过程中可以直接使用镜像缓存，然后有一个免拉取的能力，能够呃极大的降低训练时长，这个经验缓存还支持呃自动更新，然后也能够降低训练的时间，节省我们的成本。呃，在业务启动阶段，超级点上GPU pod是按pod的申请资源付费的，整个业务是独享申请的资源，可以做到强隔离，保障业务的稳定运行。在整个运行的过程中，我们也支持可视化的一个监控指标的，然后可以清晰的看到业务的状态以及资源的消耗。最后我们的pod是按量计费的业务，完成训练去释放资源，Pod秒级销毁，然后计费就停止了，然后这个也无需要再进行资源的退还，没有资源浪费。当然如果是想要长期的持有这个这部分GPU的资源，我们也支持预留券的包月模式，不仅能够降低按量使用的成本，也能够灵活的进行资源抵扣，这个就是我们在AI场景下的一些应用。
95:30
呃，以上就是今天带来的所有的分享，嗯，感谢大家的时间，感谢冰心妹子的精彩分享，那我们进入到互动问答环节。哎呀，我我那个对我们来讲，嗯，大家可以不要那么尖锐哈，嗯，对妹子要温柔一点啊，这位同学吧。
96:01
呃，我这边了解了一下，腾讯这边就是这个社会内容器的计费模式的，按量计费，还是按CPU啊，内存GPU这种，就是按规格去乘一个单价这样计费的嘛，但是我看呃，这个计费算出来比那个CPM的同规格的要贵一些。然后我看友商那边，比如像阿里云，它会有按量计费，按同规格的那个，呃，Ecs这种去计费的，这个怎么考虑的，其实这里我们跟友商有一个比较大的差异吧，就是我们在资源的划分上，因为services，腾讯的service资源是模糊畸型的。就是我们底层调的可能都是比如说S6S5这种比较新代次的机型，对于外部客户的供给，然后所以我们在整个定价上其实是只有一个模糊机型的定价的，然后这个价格你刚刚说是比同代CVM的要贵是吗？其实我们在定价的时候这里是拉齐的，就是如当然如果是小小核心的那种，可能有额外的折扣，可能就是跟STEM有额外折扣可能不太一样，比如说如果对七到八核16G的话，我们这个呃，看例价是就是是持平的，并且嗯，在有些资源规格的场景下，可能是有优势的。
97:28
然后，然后你刚刚提到的阿里云的这种场景，他们其实是呃，在service上支持了自选的那个ec s CI的规格，就ecs的规格，然后就跟ecs的那个定价是完全一致的，但我们其实认为呃，就是service场景下，用户其实不应该去关注资源的具体的型号，或者是资源的类型，我们希望交付用户的是一个呃，一个算力。
98:01
这是我单位单价卖给你一个算力，然后保证你的计算资源，这个其实对于呃，真正使用service用户来讲，我们觉得这样是可能对用户来讲的选择成本啊和理解成本都是更低的。所以我们的丁家其实就是统一的。好的。啊，中间。

展开

我来说两句

0 条评论

登录后参与评论

作者

腾讯云原生

Serverless Days原创

我来说两句

作者

相关推荐

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐