云函数Web Function 落地应用实践原创

OK哈，各位同学晚上好，欢迎大家来到本期的，嗯，今天我们主要分享的内容是我们最新上的一个功能外部方，那么基于这样的一个功能，我们会给大家做一个简单的介绍，并且同时我们也邀请了两位我们非常专业的一个基础的大咖同学，然后基来给大家分享一下他们基于function做的一些实战的应用的一个分享，那么首先简单做一下自我介绍，我是来自腾讯service产品中心的产品同学April，那么接下来呢，我们大概介绍一下我们今天的一个we主要的内容。嗯，我们分为三个部分，第一个部分是我外方一个简单的一个产品的一个介绍，那么主要介绍一下它的一个功能，以及它的一些性能的优势，那么第二个部分就是我们的邀请的两位大咖同学，他们会作为一个实战应用的一个分享，那么第三个部分就是一个提问的环节，所以大家如果有任何在整个的宣讲过程中，如果有任何的问题的话，可以随时在评论区去进行一个提问，我们都有收集问题之后会统一的就到最后给大家做一个解答。

那么这边还是简单的先介绍一下外B方式，呃，外函数是我们其实是云函数一种全新的产品的类型，那么它最大的优势是它打破了我们传统的事件函数，它可能对于我们的事件格式会有一定的限制，所以我们可能只需要传的格式啊。那么对于外函数来说，它可以直接的接收原生的HP请求，并且去做一些URL的一些处理，然后去包括一些后端的一些应用的一些呃，进一步的处理，那么简单的流程呢，就可以通过下面这张图来看，就是我们的用户发起一个请求，经过API网关，API网关测不会做任何的处理，他们会直接的透传，透传完成之后在我们云函数内部的执行环境中接收到这个原生的HTP请求，并且通过用用户自己的一个web server这样一个服务代码去对这个请求进行进一步的处理和解析，并且帮将结果返回给用户，那么其实就实现这样的一个逻辑，那么这样的方式我们为什么要做这个东西，以及它最大的优势在哪里呢？那其实就。

下面的这三点就是可以看到，因为我们函数是直接的处理P的求，那么它可以保证我云端的代码和地代完的，那么如果我想做一些调试，那么我在本地去做测试的时候和我在云端其实是没有任何的区别，我可能直接一个请求或者是呃，一个URL就可以去完成相关的一些测试，那么如果我们想去开发一些个人的一个API的话，那么这个是一个非常合适的场景。那么第二点就是在于他的改造成本低，那这个成本其实在哪里？就是在我们之前可能常用的一些外部框架，类似于express或者SS或者其他wrong time的Jung啊，或者这样的一些框架，我们把它放到云上的话，我们要做的最大的一个处理就是我需要把原生的HTP请求转换成这些呃，我函数函数能够去接收的Jason的事件，那么在我express这样些框架接收这个事件之前，我又要把这个Jason事件转换成他们能接收的HTV请求。

就是我要需要去经历一层原生请求到Jason事件格式转换，那Jason事件格式转换到HTP请求的这样的两次的转换，那么其实如果我一来一回，这样我们就需要经历四次的转换，而中间的这层转换的这层接入层代码其实是需要我们用户自己去写的，那么其实如果这样的话，我们本地的原生的express这框架放到云上，其实还是需要去进行一部分的改造，那么其实在基于function这种形式，其实我们就是完全省去了这样的一个改造的成本，也就是我本地怎么写，我云端就怎么写，我都是可以以监听端口的方式去进行一个启动的，那你可能只需要去写一个启动的文件，就类似于一一句话的一个命令，类似于note and这样的启动命令，它就可以去完成相关的一个启动的启动，然后三个优势就在于我们可以提升这个应的效率，就像刚才说的，因为我们其实已经降低了这样两层的一个请求格式的转换，我是直接接收，直接触发，直接处理的，那么这样整个的一个效率的话，会比传统的我不停。

的转换明显会有一些很明显的一个提升，那么对于像类似于这种DQ这样些网站的一键部署，他们对于这种请求响应时间会有一些明显的呃要求的，那么其实这种这种web方式，它会更适合这样的一个场景，那总而言之we function实我们就是专注于开发做的一个功能，包括你在做API的一些个人API的开发，或者一些外部框架的开发，甚至说你部署个人的网站，其实外方都是一个更好的一个更优的一个选择。那么简单介绍就到这里，我们接下来介绍一下我们今天分享的两位嘉宾，然后一位是杨启明老师，他是本身他是一个在前端领域非常。有经验的一个专家，而且他自己也主导了许多产品的生命全周期的一些技术方案体系的开发，目前也是在致力于对于S的一个技术的落地，然后另外一位呢，是范国金老师，他是一个比较资深的PHP开发工程师，也是对我们S这个产品也是我们的一个老用户了，包括对于整个研究也是非常的有经验，而且自己本身也是在对于计算领域，包括广告从业，广告行业的从业也是有比较丰富的一个经验，所以说今天我的介绍到这里，接下来就是我们的最主要的环节，我们邀请两位嘉宾来对做对于自己在外方程这样的一个能力，这样的一个实践做一个具体的分享，那么我们首先可以邀请杨启明老师，然后可以来开始他的介绍。

嗯，好的，嗯。我共享一下屏幕。呃，看到吗。可以的。好的好的好的，感谢主持人。呃，各位晚上好，我是杨启明，是一位前端开发工程师。今天在这呢，主要给大家分享一下最近SCF啊团队新出的函数，还有容器部署这两个功能。以及他们的一些使用方法和最佳实践。

其中内容呢，就主要包含以下五个方面。首先给大家介绍的呢，是we函数与事件函数在web场景的一个对比。另一个呢，就是我们的应用啊，去结合framework去进行部署和迁移。还有一个呢，就是镜像部署的一个用法和实践了。现在就让我们正式开始吧。首先我们可以看一下这张图啊，它就是我们腾讯云控制台啊，新建出来一个最最基础的事件函数，也就是一个hello。而且呢，相信有序开发经验的朋友啊，其实也对这代码很熟悉。代码呢，他就露一个方法入，就是事件event和上下文context。然后呢，再把我们的event作为函数，它的一个返回值给传出去。这个就是一个最基础的CF事件函数了，看上去也是特别的简单。然后基于这个函数呢，我们再添加一些代码，把这个功能进阶一下，比如说让这个函数能提供微博页面访问的一个服务。

接下来他就能改造成这样。可以看到呢，改造之后啊，这样代码也非常简单，而且呢，它不单提供了静态页面的一个托管的能力，而且它还能提供一个简单的服务端渲染的一个能力，比如说我们给他提供个HTM模板。它在获取数据之后呢，就可以把数据进模板里面进行渲染之后再得到HTML的字符串，然后最终在一层一层返回到用户的器里面去显示。同样呢，它也能作为返回Jason格式的一个VBAPI来使用。但是呢，我们仅仅去写这些看上去很原始的代码，实际上我们的开发效率并不是很高，而且工程其实也比较麻烦。要提升我们的生产效率的话，我们通常会使用一些非常流行的微博框架，因为这些流行起来，微博框架呢，他们不仅改善我们的开发体验，更强大，之后呢，他们可维护性强，而且有一个非常良好的生态系统，可以给生产环境啊去快速贡献的一些稳定的一些包。

所以相同的JS呢，我们就会去使用express k OA以及他们的各种衍生品框架来编写我们的服务。做服务端渲染呢，我们也会使用像next。这类和前端类的SR框架来提供页面服务。那么刚刚说了那么多框架呢？我要先说一下，在没有B函数之前，之前事件函数，它是如何去兼容这些市面上已经成熟的框架呢？我们先来看一下这张图啊。这张图上呢，就展示了之前事件函数它去兼容web框架的一个运行原理。首先呢，用户本身为了访问我们的APP，就会去向我们应用的一个域名发送HTP请求。

然后呢，这些请求实际上就绑定到了我们一个域名的一个API网关那边，然后API网关啊，再去根据请求那些信息去进行路由匹配，根据规则呢，进而找到我们绑定的一个函数进行触发，并传递一个访问事件。接着这个事件呢，就进入到了我们代码里的一个适配层，在这个适配层里面呢，他又把这个事件啊，转化成了HTP请求来交给我们编写的web up处理。然后再得到结果之后呢，再把它处理成API网关那个标准数据结构，一步一步的再返回到客户那边去。所以说可以看到这个流程里面的HP请求啊，在API网关那边被转化成事件之后啊，相当于在这层适配层里面又被还原了。一来一去就白白损耗了四次转化的一个算力。这个呢，实际上就是事件函数在处理web服务的一个弊端，因为事件它毕竟是要靠事件来触发的，而HT请求啊，对他来说实际上也不过是一个类别不同的事件罢了。

当然了，关于这一层适配层，实际上。有些朋友可能以前用过事件函数来提供B服务啊，也可能会好奇，其实我们自己很多情况下并没有写部分代码。为什么我在图里面把它放进了我们的code里面去，也是我们自己代码里面去呢？实际上呢，这一份部分代码大部分我们的一个service组帮忙去做了。假如我们自己去对比我们自己的代码和腾讯控制台，呃，腾讯控制台中真正生效的那些代码。实际上就会发现呢，在里面除了我们自己代码之外，还存在着一些垫片代码。比如说我们在部署上去之后啊，往往会出现这个文件夹，或者在图上标出来了。

这个文件夹呢，就是默认适配层proceed的一个所在地了。通过这种方式呢，就把我们的内转H我架。处理完的结果呢，再通过这一层转化成API网关的一个标准数据结构，返回到API网关那边，再到用户那边。进而通过这种方式啊，内部勉强适配了各种第三方框架。这呢，就是事件函数，它兼容各大框架一个大致的原理了。那么接下来要说的web函数和它有什么不同呢？接下来我们来进一步看一下这张的一个运行原理图。呃，从这张图上我们可以看到啊，其实它整个大体的一个原理啊，和函数其实是差不多的，比如说它都要有API网关，从那里进行触发，并进入SCF云环境去运行我们的一个代码。

但是呢，有一个很大的不同点在于，Web函数把它的适配从我们用户编写的代码代码中剔除了出去。也就是这个部分。而且呢，在使用方法上啊，他也不再是像之前事件函数那样，从内部去导出一个框架实例的方式去动去动云函数了，而是呢，它会去绑定我们代码监听那个端口，比如说像这里呢，就是默认绑定这个端口9000。通过这样的方式呢？我们无论是编写我们的web APP，还是迁移我们一个现有的web server到service平台，都会变得非常的简单。而且更加贴近语言原声，而且通过这种端口监听的方式啊，其实带来一个很大好处，就是更加的限制我们的开发框架了。

比如说像原先事件函数啊，它需要给每个不同的语言，不同的框架组件啊，都去写一个事件转化，现在在web函数的时代，实际上也是不需要的。所以这里呢，我也给大家整理了一下它的一个几点优势。比如说事件函数啊，API网关检测到这个函数类型，就会把原生的HTP请求转换事件。现在在web函数那边呢，就直接把HTP请求给传了。这样带来一个好处，就是它的转化链路啊，实际上是大大缩短了。性能损耗也比较低。这就直接提升了web服务它的一个性能。而且函数本身啊，他也能够通过HTB请求的方式去触发。它的开发呢，也更加贴近原生的服务，这无疑是带来一个开发体验上的提升。

而且呢，也让传统应用迁移改造到web service平台，它的一个成本给降低了，部署相对来说也非常方便。这些因素呢，就造就了他在外部场景的一个天然优势。而且关于这个性能好呢，其中也不是口说无凭的，这一块呢，我也专门写了一段代码，而且分别把它部署成web函数和事件函数，并做了多轮的压力测试进行对比。接下来呢，我给大家展示一下这个结果。大家可以看一下这张图啊，它就是一个压测结果的平均QS折线图。其中呢，这个黄色和红色这两条线就是我部署的一个函数。然后呢，这个蓝色和绿色这两条线呢，就是我同样的代码部署的一个事件函数。X轴呢是我压力测试的一个并发量，从十到100 Y轴呢，就是我每秒的一个请求量了。可以看到呢，在QBS上啊，随着我们并发量的提升。

Web函数和事件函数啊，它们之间差距就逐渐拉开了。尤其呢，是到并发量九十一百的时候啊，函数在这时候已经完全超越了时间函数，他们平均每秒的一个接收的请求数啊，也要将近相差500左右。而且呢，像我使用的note JS啊，它的一个版本也会数据造成一定的影响。从图上也可以看到，像12的版本就相对于NOTE10具有一定的性能优势。这毕竟版本的进步也带来一定的那个性能提升嘛，嗯。接下来再来看一下吞吐量的这个一个折线图。这张图的X轴呢，还是并发量？然后轴呢，就是每秒的一个吞吐量就是K，也可以看到在吞吐量上，函数实际上和应函数两者之间的差距就并不是很大了。

接下来看一下请求延迟的一个统计图，其中呢，X轴还是一个并发量，Y轴呢则是一个延迟时间单位呢就是毫秒了。在图上可以看到，在延迟时间上面，微函数是完胜的。其中呢，像物函数啊，它的一个响应时间大部分集中在30~40毫秒左右。最终呢，随着并发量提升，最终趋于33毫秒30毫秒左右。但是呢，像web函数啊，像事件函数啊，它就主要集中在40~50毫秒之间浮动，并最终趋于40毫秒。这显然呢，Web函数它的一个延迟时间更短，也就是说通过这些数据我们也能够知道，在web场景下面，Web函数它显然是一个更优的选择。接下来呢，我来讲讲如何利用frame去快速部署web函数，以及原先已经部的一个事件函数啊，它如何牵函数。

像service呢，之前我也介绍过，他可以利用我们给他的一个云厂商的授权，再通过我们的一个命令行或者脚本形式，快速把我们的一个代码给部署上云。省去了繁琐的UI操作，也是一个非常不错的提升效率的一个工具。像目前呢，它已经兼容了函数，我们就可以利用它来进行快速部署和运维的一个操作。所以接下来我们来讲一下frame它的一个函数的一个组件。比如说原先我们要部署或者签一个微博服务的一个数啊，是往是需要显示声的一个框架组件的。比如说我们要部署一个express框架，那这时候就需要我们的service里面去配置component这一行为express。当然，我们写Python，写江口亦然，也是需要去配置这一行的。

配置这一行的目的呢，都是为了告诉云端，我使用是这个框架，给我这个框架适配层，也就是刚刚我提到试验函数那一层。然后云端呢，就会找到这个框架，它对应的一个代码，我们加进我们自己的代码中去。显然呢，这种方式是存在一些缺点的。比如说，它会导致我们的代码和使用的service组件产生一定的强耦合关系。但是呢，像官方或者第三方提供的框架选择啊，实际上相对来说就那么多，总量是比较少的，我们应用呢，可能会用一个非常冷门的框架，或者原生的一些那个请求，甚至这种框架冷门到目前我们官方并没有提供这样的框架组件呢。遇到这种情形。怎么办呢？当然方法实际上是有的了。

这种方法呢，就需要我们自己去学习适配层这一层到底怎么写，然后再把HTP它的一个源码或者用法多看几遍。并且使用它去编写我们自己的一个。但是这种方式呢，实际上变相提升了我们的开发成本。同时呢？由于框架们他们的一个存在，实际上在一定程度限制了我们的一个架构的选择。举个简单例子啊，有一个杰框架叫。但是假如啊，官方并没有提供fast这样一个框架，那么是不是很多用户在编写代码时候啊，就不会选用这个框架来编写service函数呢？而且还有一个缺点啊，就是他对组件开发者也非常的不友好，因为像原先这种形式，每个语言每个框架都需要去写组件，而且还需要在不同的语言里面，其实是实现功能相同的一套。

这其实也是一件费时费力而且重复性高的工作。现在在函数时代呢，我们就不需要那么多组件了，我们自己去编写server去部署呢，无论我们使用什么语言，什么框架。在这里呢，都可以只使用一个组件，就是component CF这个组件。这个组件呢，能够直接的把原先那些框架的应用啊，给部署成web函数。而且像刚刚也讲过，我们原先编写的服务啊，代码和service组件是强耦合的关系。现在呢？通过这种方式也变成了端口之间的相互依赖监听的关系。通过这一方式呢，就直接把原先事件函数中那些用于web场景组件给解放了。而且代码部分呢，基本上是就只需要改两行代码就可以轻松部署函数，也就是说在原先导出框架APP实例那一行啊，把它转变成使用那个APP去listen我们的9000端口就可以了。

在这呢，我也给大家展示了一个service，它的一个配置的迁移方案。可以看到牵引的第一步呢，实际上就是我们把组件从component，我们原先的component换成component的CF，也就是我图上所示的这里变成一行。接着呢，我们再加一行来声明它的一个函数type是。行，实际上就是告诉我们的那个CF，我需要部署的是一个web函数。然后接着呢，我们就需要更改我们的一函数的入口文件，像刚刚也提到啊，原先事件函数通常是要求我们去暴露一个SLS这样的文件框架运行。

然后现在呢，要代是我们需要去编写一个CF这样一个件，也就是我这个handle。这个文件里面呢，就写着我们的一个暴露端口和启动命令端口呢，就是刚刚讲过的一个9000。然后启动命令呢，就是我们去找到我们代码的一个运行的语言环境。然后用它去执行我们的一个应用的入口文件就可以，其实它的本质啊，就是相当于在命令行里面直接敲no，然后写我那个，比如index。总的来说呢，这块熟悉之后啊，迁移还是非常的简单，而且成本相对来说非常低。这里呢，我也给大家展示一下目前函数啊，它默认支持的一个标准语言环境，大家可以看一下这张图。像目前呢，Web函数，它默认支持的主要就是诺基S2个版本，Python PHP go Java之类的语言。

但是呢？我们可能是一个程序员，或者是一个c sharp程序员。在这张表上并没有找到我们应用所需要支持的语言，遇到这种情况咋办呢？所以说接下来呢，就需要用到容器镜像部署这一个腾讯团队新出的一个功能。像很多时候呢，实际上函数啊，它的一个默认容器环境是不满足我们的一个运行需求的。比如说我们经常会遇到我们运行时所依赖的语言版本太老，比如说我们应用啊，它可能基于是诺基S14，也就是它最小版本就是四，但是刚也看诺基最标准版本。这就导致我们应用会跑不起来嘛。

又或者说呢，我们应用是需要依赖大量的系统底层库，标准语言的一个容器环境里面并没有。再或者说呢，就是刚刚遇到那种标准语言环境，它支持我们编写语言这样的问题。这几类问题呢，都可以使用容器镜像部署这个功能来帮助我们去解决。比如说我们想部署一个应用到service平台上面，怎么做呢？我们就可以完全在本地拉取我们的多个镜像，在容器中进行开发部署测试之后呢？到我们的一个镜像仓库，然后再通过来快速上云。这里呢，我也给大家画简单画一张图，来演示一下镜像部署的一个部署流程。可以看到啊，像我们在本地拉取dob上的一个基础镜像之后呢，就可以去安装我们需要的一些系统依赖，然后在本地进行开发和测试。

开发完成之后呢，我们可以把我们的应用啊给做成镜像，Push到腾讯的一个镜像仓库。然后呢，再通过编写对应的一个service的一个配置，通过service framework命令行一就可以快速部署上云了，然后在云端测试环境进行进一步的一些测试之后啊，就可以通过那个流量切换版本发布的方式去进行正式的一个发布了。我们个人的所有上传镜像呢，也都会在腾讯的云产品控制台里面显示。它的一个位置呢，就存在于容器服务中的镜像仓库这个功能里。我们也可以在这里呢，获得我们一些镜像的一些额外信息，像图上所说的一个函数地址啊，命名空间啊这一类的。

而且呢，我们也可以在这里对所有已经上传的镜像啊，进行一些管理上的操作。这里呢，我也给大家简单分享一下我两个镜容器的一个例。首先呢，我们来看一下这个第一个事例啊，这个事例呢，是一个升级note JS的一个版本，然后再加上定制依赖库的一个案例。像刚刚之前提到note JS，它的一个标准语言环境只能到12。像我们想使用更新的一个note GS版本，比如说我们用LS就可采用这样的方式。比如说我这里的这一行，就是拉取像note JS lts它的一个版本。然后这一个的，呃，大大码块呢。就是去安装大量的一些系统底层，底层依赖的一个扩展库。通过这样的方式去定制我们的一个service，它的一个线上的一个运行环境，然后在容器里面进行开发下应用，做一下我们的镜像到那个镜像仓库里面，实际上就完事了。

而且右边呢，就展示了我部署的一个service样配置，这个样配置呢，实际上也相对来说简单，而且呢和之前讲的像事件函数还有外部函数啊，它们的配置上其实上大部分都是一样的。最大的不同点就在于镜像部署这种方式啊，是不需要配置src这一个配置项，取而代之的呢，是需要配置image这一项。像src啊，我们知道。这个配置呢，是需要用来标记我们的一个本地代码位置，然后这样的话，Service framework就知道它的一个位置，就可以去打包它，然后上传到我们的一个云平台。也就是我现在标出来这个配置项。

这个配置呢，就是告诉腾讯云我们上传应用，呃，上传镜像它的一个类型，以及它所处的一个位置了。这样的话，CF啊就可以去拉取我们的一个镜像，并进行部署。这两个配置项的值呢，目前都可以在我刚刚的一个镜像仓库里面找到，这里呢就不演示了。然后还有就是下面一个事例。下面一个事例呢，是一个。呃，SP的call应用成功部署了一个do。然后它的一个部署的一个样，配置呢，和刚刚那个样实际上就差不多了。就这样的，像自定义容器部署这一部分啊，就这样大概的快速过了一遍。因为啊，实际上这个功能是有，对于我们前端来说是有一定的学习成本的，但是学会之后啊，就会发现它的灵活性非常高，而且呢，能够满足我们各种应用部署和牵引的一个需求。

接下来呢，我来给大家分享一个James他的一个案例。当然了，在这个之前啊，我先给大家简单介绍一下我们前端传统SPASR他们应用部署的一个方式。比如说我们想部署一个SPA的web应用，我们通常会把它那个，然后经常是往服务器里的一扔就完事了。而且呢，即使SSG啊，也就是一些那个静态页面生成的一些那个framework也是如此，只不过它会多加一个这样一个过程。把它的内容啊，预先渲染成一个静态页面，然后部署啊，实际上和也是类似的。而SPA ssg这种方式在云端部署啊，就可以抛弃我们的。取而代之的是使用cos静态加CDN这种部署方式来做。

像我们的服务端渲染SSR相对来说就有一些区别，因为SSR默认的所有资源都存在我们的服务端。用户呢，通常也是直接访问我们的SR站来获取页面。不过呢，相对来说，我们SSR应用也通常会选用这种动静分离的方式去部署，也就是我图上所示的一个note集群，负责他动态的一个部分，然后所有的静态资源呢，再通过CDN来进行一个分发。通过这种方式呢，来把所有的静态资源啊给host在CN上，因为毕竟把静态资源host在我们的诺集群啊，实际上也是一种算力上的一个浪费。像这场景呢，就是刚刚那张图的一个衍生，首先给大家看一下这张图啊，这张图呢，就给大家解释了什么是这样一个问题。

它呢是一种使用静态网站生成的一个技术，核心呢就在于不赖web server来提供服务。主要的好处呢，就是它性能比较高，开发部呢也相对来说比较方便，安全性也好，毕竟呢都是一些静态文件嘛。它主要依靠service函数来给它提供后台服务。然后CDN来负责从原站那边获取内容，然后来进行分发。所以呢，这种应用啊，有时候也变相的称为CDN优先程序。那么，我们如何在腾讯云去实现这套机制呢？在这里我就结合了service framework，还有CF的一个web函数也是。和那个CDN这个产品进行组合，来实现这一整套的一个流程。这流程呢，实际上也非常简单。

在所有的一个service组件中，我们只需要两个。一个呢，就是刚刚提到的一个CF组件。还有一个呢，就是website组件。其中CF组件呢，是用来提供API的一个后台服务的。然后组件呢，这里简单介绍一下。这个组件可以帮助我们把本地编写的代码来快速上传到我们的一个腾讯的对象存储上，并且部署构建静态网站。同时呢，它还具有一定的部署CDN和CDN刷新预热这样的一个功能。也就是说呢，Website这个组件啊，可以帮我们的对象存储CDN产品。最后呢，就是CRCD了。这个倒是没有任何的限制，可以随便用。当然了，像腾讯云coding是非常不错的一个选择，因为它和整个腾讯云的集成度啊，实际上非常高的。

或者呢，我们也可以只用getb actions来完成我们的持续性集成的一个操作。所以呢，这里我也基于刚刚那原理图啊，进一步画了一张。基于刚那套架构下的腾讯云的一个。我们网站应用的部署啊，就变成了上图这样。CF web函数提供API服务，CCD呢，它既负责构建我们的网站，并把它上传到cos去部署。同时呢，他也负责我们的CDN进行一个预热和刷新。然后CDN呢，再从cos原站那边去同步拉取内容。这样的话，每次网站一旦发生变更，就会去触发持续性集成。然后CCD它去创建容器，去打出新的静态文件，再去上传到cos，去部署静态网站。

再接着呢，去刷新预热所有的C节点，告诉变的一个部分，让站那进行同步。至于这套机制下面啊，潜能框架实际上就不怎么重要，直接去跟James挖机里面去随便挑一个就行。而且呢，即使是像next JS中。做某种程度上深度绑定的一个框架，也可以在这套机制上快速迁移到腾讯云的这套service体系中去。所以呢，在这里我也写了一份例子啊，来把部署在那个那边的一个应用给迁移回国内的腾讯云。这个方案的核心呢，实际上就是一份get up actions的一个配置文件了。这个action呢，会在我们提交代码的时候啊进行触发，并依次执行我们的那些部署命令。

然后里面的核心指令呢，实际上就是这最后一步啊，我也给大家标出来。也就是这一部分的一个代码块。这一个部分呢，就是在里面去安装我们的I，并且给他授权我们腾讯的ID。然后告诉他我们需要部署的平台啊，是国内的腾讯云。这样呢，他在获取新的改动之后啊，就可以去重新生成我们的页面，然后去上传部署到cos了，然后再接着去刷新CDN，从而变相的达成了那种持续性集成的一个效果。最后呢，直播时间也有限，更多的案例细节呢，也欢迎添加我们的一个小助手的微信，进入我们的service技术交流群里面去。在群里呢，我们也有更多的场景和案例可以分享给大家，也欢迎大家进群和我们进行更进一步的交流。