vos3000落地网关对接教学_跨国合作：Serverless Components 在腾讯云的落地和实践

导语 | Serverless Components 是 Serverless Framework 推出的最新解决⽅案，具有基础设施编排能⼒，开发者通过使⽤ Serverless Components，可以灵活构建、组合和部署 Serverless 应⽤。本文是对腾讯云云函数团队前端负责人蔡卫峰在云+社区沙龙online的分享整理，介绍Serverless Components在腾讯云的落地和实践，希望与大家一同交流。点击查看完整直播回放

一、Serverless Components 实现原理

1. Serverless CLI 工具

Serverless是一个重开发和部署的产品应用，服务提供了弹性伸缩、自动运维的能力，开发者主要关心开发和部署。所以，开发和部署的体验对于serverless业务来说是非常重要的。Serverless的函数本身只是提供了计算的资源，要想实现一个完整的应用，必然会涉及到云上的其他资源，比如网关、cdn、数据库等。如果是控制台操作，需要在不同的服务之间跳来跳去，比较割裂。如果能有一个基于应用的统一的命令行管理工具，对于开发者必然会方便很多Serverless CLI 是用户授权后，通过命令行工具，调用云API帮助用户管理云资源，方便对云上资源进行比较完整的操作。

2. 什么是 Serverless Framework

Serverless Framework 现在大量的使用者是 web 服务的开发者，主要定位于 web 服务场景，它是北美研发团队开源的一个项目，是业界⾮常受欢迎的⽆服务器应⽤框架，开发者⽆需关⼼底层资源即可部署完整可⽤的 Serverless 应⽤架构。Serverless Framework 定义了一套完整的标准化规范，各公有云的插件遵循这套规范，通过对云上资源的编排，覆盖编码、调试、部署、排障等全⽣命周期，帮助开发者通过联动云资源，迅速构建 Serverless 应⽤。

3. Serverless Framework CLI

Serverless Framework CLI 是一个开源命令行工具，它使用基于事件触发的计算资源，例如腾讯云云函数，AWS Lambda，阿里云函数计算等。Serverless Framework 为开发和部署 Serverless 架构提供脚手架，自动化工作流以及最佳实践。并且它支持通过丰富的插件进行功能扩展。 Serverless Framework 在 Github 有将近 4 万的 Star，在国外比较受欢迎。我们团队最开始也维护了一个自己的 CLI，但是维护成本比较高，想做体验好操作流畅的 CLI 需要投入大量人力精力，Serverless Framework 的 CLI 开发者接受程度比较高，它的协议也开放，所以按照规范接入即可。我们也有用户原来用 Serverless Framework 的命令行工具，从 AWS 迁移到腾讯云云函数环境时候提出了这样的要求。对用户而言底层的云资源操作是屏蔽的，只需要跟Serverless Framework打交道就可以了，希望我们也可以提供对接 Serverless Framework 的方式，这样迁移到腾讯云上比较方便。通过和 Serverless Framework 团队的沟通，他们正好也有意愿打入国内市场，双方的合作也就水到渠成了。Serverless Framework 强于 CLI 整体的体验，但是对腾讯云本身的了解比较少，于是就有了基本的合作模式，北美团队负责 CLI 的开发和整体体验，腾讯云团队负责具体落地到腾讯云的 components 的开发和维护。双方合力，打造 Serverless Framework 在国内的实际落地方案。

4. 什么是 Serverless Components

Serverless Components 是 Serverless Framework 的一个解决方案，本身具备快速部署、灵活配置、模板共享的理念。公有云对接 Serverless Framework 后具有了公有云基本的操作能力，但是落地到具体的应用场景就会变得复杂。外部应用不是单纯靠计算资源，也会涉及到静态资源，比如图片、CSS、JS 文件的托管和域名的管理，涉及到底层数据库的管理，也有一些更复杂的应用会涉及到更多的云上的资源。如果开发者要想实现一个应用的管理，则需要通过一系列的操作才能完成一个应用管理和部署，而 Serverless Components 是为了适配各种具体化的应用场景而开发的模板能力。Serverless Components 是 Serverless Framework 推出的最新解决方案，具有基础设施编排能力，开发者通过使用 Serverless Components，可以灵活构建、组合和部署 Serverless 应用。

二、Serverless Components 全生命流程

Serverless Component 部署流程

Serverless Components 部署的完整全流程，首先读取 .env 文件，在 .env 文件中可以输入腾讯云固定的密钥信息进行授权，也可以通过微信扫码赋予 CLI 临时的授权，授权 Serverless Components CLI 在某一段时间可以操作云上某些资源的能力。同时在 .env 文件里面可以注入相应环境变量，你可以直接在 serverless.yml 中通过 ${env} 的方式，直接引用环境变量配置(包含 .env 文件中的环境变量配置，以及手动配置在环境中的变量参数)。接着读取 yaml 配置。yaml 文件要指定使用到的组件名以及组件相应的输入参数，每个组件因为涉及的操作会不一样，所以每个组件对参数也有自己的一套固定的规范。通过 CLI 的命令进行部署的时候，会把用户代码压缩之后上传。首先压缩指定的代码目录，上传到一个公共的 COS 里面。然后新建或者更新组件的状态，同时会在服务端把代码下载下来，并注入 Proxy 代码。proxy 代码都实现了什么能力呢？云函数主要的适用场景是事件驱动型的，对于 http 请求的实现是通过 API 网关触发器转发的。网关接收到的 http request 会转换为云函数需要的参数对象，在函数执行包装后的 web 框架，执行完后再把 http response 转换成 API Gateway 需要的结构返回给网关，网关再把 response 转换成标准的 http response 返回，这样就实现了整个 HTTP 的访问。用户不需要关注这部分的实现，按照正常的开发就可以，Components 部署的时候会自动注入这部分转换逻辑的代码。服务端在注入完 proxy 代码后会把代码上传到用户 COS 里面，然后创建或更新云函数，同时会再创建或者更新 API 网关的配置。这个时候再把整个创建的过程以及创建的状态保存到服务端，控制台再输出整个组件最终需要给用户看到的一些云上资源的信息，比如 SCF 的信息、API 网关的信息、CDN 的数据和数据库信息等，整个部署就算是完成了。应用部署完后会返回 API 网关公用的二级域名的一个访问地址，跟正常的函数与自己组装资源去访问应用方式是一样的。大家可以看到，我们抹平了一些云函数和正常服务器差异化的实现，抹平后通过 Serverless Components 可以不用关心这些特殊的逻辑逻辑，也不需要关心其他的云上的资源。如果自己要创建一个应用，同时要创建云函数，代码里面要自己转换 HTTP 请求，然后创建一个触发器绑定到云函数。如果需要做静态资源的加速，需要拆分静态资源部署到 COS，并配置一个 CDN。这中间涉及到多个云资源的操作。而我们在 Serverless Components 中已经将整套都实现了，只需要在 yaml 文件里把这些配置进去就可以，部署完成后就可以看到你的应用了。

三、Components生态建设

1. Serverless Components 生态

如上图所示，其中列举了一些用户使用比较多的 Serverless Components 组件，还有一些没有列举出来的，这些基础的组件包括了腾讯云上的各种常用的基础资源。可以通过对多个组件的组合来组成完整的应用，也可以直接使用现有的高阶组件。我们也欢迎第三方开发者贡献他们的组件，现在就已经有很多第三方的开发者在贡献他们的组件。

2. Serverless Next.js

接下来详细介绍一个 Serverless Components 的具体实现。以 Next jS 项目为例，首先是初始化一个项目，安装 CLI，原来的项目不需要做什么改动，按照 Serverless Components 要求的规范进行配置后，直接用命令行工具进行部署。执行部署后 component 会帮用户通过 CLI 进行代码的构建，完成构建后会把代码部署到云函数上，创建 API 网关代理 web 服务，同时部署静态资源，会把目录下的静态文件自动拆分，并部署到 COS 上面。我们后面也会做更加智能化的优化，next 框架代码比较大，每次部署都要上传两三百兆代码，对上传的效率和启动效率也有影响。腾讯云提供 layer 的能力，我们会自动拆分用户的n ode_modules 到 layer，之后的部署只需要把业务代码上传和部署就可以了，对部署效率有很大的提升。这里是部署一个有一些复杂度的 next 应用的屏幕截图，可以看到完成部署仅需 31 秒，部署效率非常高

四、跨国合作：挑战和收获

1. 跨国合作:挑战

从开始合作到现在已经有一年多了，还在不断的磨合中。下面是我总结下来的，我们在一年多的合作里面具体的挑战，与大家一起分享交流。

(1)沟通效率

由于时差，语言表达，以及东西方思考方式的差异，导致整体的沟通效率比较低。

(2)开发模式

他们那边是游击队的开发模式，有一些研发发布比较随意，导致了一些线上的问题。而我们其实是有比较严格的开发流程，发布前的验证，发布后的确认，监控告警的体系等等，都有严格的要求。慢慢把我们这一套严格的规范灌输给他们，并要求他们能够按照我们的要求执行。

(3)问题定位

由于整套体系比较庞大，大家在前面也看到了，一个完整的 component 的生命流程比较长，步骤比较多，之前也没有统一的日志收集体系和系统，导致出现了用户问题定位花费比较长的时间。

(4)目标

两个团队的目标导向不完全一样，我们更注重用户云上资源的安全，对于密钥的使用及权限控制比较严格，而他们更多的考虑的是使用上的便利。

(5)人才招聘

整套体系采用 nodejs 开发，涉及到后端、存储、数据库等方方面面，对于开发的要求比较高。另外，需要开发和产品有技术运营的理念，有开放的心态。对于英语也有一定的要求，最好能和北美的开发团队直接对话。

(6)运营理念的问题

国内外开发者习惯是有差别的，国外比较多的开发者更容易接受命令行工具，而国内开发者对这套东西不熟悉，需要有一个接受的过程。我们也会做一些妥协，比如后面可以考虑提供界面化的配置方式等。其实对于 Serverless Framework 与 Serverless Components，腾讯云本地化的运营方式和引导上跟国外会有所差别，我们会针对国内开发者做一些贴合开发者习惯的尝试。其实在跨国合作中涉及 CLI 的时候，我们一直很迷惑。虽然我们很想把事情做好，但是对命令行工具的设计和交互设计方面受限于腾讯云的产品，无法突破自己的框架。通过跟北美团队的交流合作，对我们的思路也有很大的开拓，我们跟他们学习到了他们的产品设计理念，在产品设计方面，AWS 和周围的生态确实对于我们是很好的借鉴意义。进行大型开源项目的实现，合作过程中对协作方式也学习到了不少，对于整个后期的开源项目推进，后面再去参加别的开源项目，对于我们而言都是非常宝贵的经验。同时，我们也把严格的软件开发经验输出给北美，并获得了他们的认可，对于我们而言也是比较自豪的一件事。以前软件开发方面北美领先于我们，所有方面我们向他们学习。现在并不完全是这样了，我们比较严格的软件开发规范比他们走得更靠前，把我们的规范输出给他们的同时也得到了北美团队的认可。

2. 跨国合作:收获

学习先进的交互设计以及产品设计理念；
以AWS的理念要求我们自己的产品；
大型开源项目的协作方式；
输出严格的软件开发规范，获得认可；
同类型开源项目的借鉴和学习，开阔视野。

同类型开源项目的借鉴和学习开拓了我们的视野，北美团队也会经常发一些他们能够了解到的信息同步给我们，我们能够从中得到借鉴和学习，并得到自己的增长。所以未来也会更加紧密合作。

Q&A

Q：Serverless现阶段适用和适用的场景，腾讯内部有哪些业务在用?A：所有的场景都是可以的。小程序云开发底层云函数的能力就是用我们 Serverless 的实现，腾讯内部还有比如微信支付、微信读书、腾讯视频、腾讯课堂有不少场景在用 Serverless 的服务。Q：部署而言Serverless相对TKE有什么优势和劣势？A：TKE 本身是需要自己管理的，但是 Serverless 在计算资源方面完全不需要自己去管理，我们有一个完全的动态弹性伸缩能力，会根据访问的请求量去做自动的伸缩，基本上省去了运营的需要。Q：监控方面有什么成熟组件的接入？A：正常的外部应用都是可以接入的，和虚拟机、容器等计算资源使用的方式相同。我们平台也提供了一些基础的监控和日志能力，另一方面，也在联合腾讯云的监控团队做了自定义监控组件上报能力的接入，可以在代码里面自定义的上报到腾讯云监控，自定义监控平台可以看到监控的数据。Q：Serverless对业务较复杂的大型项目是否适合？A：肯定适合，比如微信支付、微信读书、腾讯视频、腾讯课堂都有不少场景在用Serverless的服务。Q：稳定性保障的情况如何？A：Serverless 是基于腾讯云整套体系来建设的，稳定性方面也是经过了大规模的压测，有可靠的保障。比较大型的项目提前跟架构师沟通，来做资源的预留或者是资源等级的提升Q：学习路线是什么？A：部署自己的业务到 Serverless 服务上面来，可以在实践中不断的熟悉。还可以加入我们的微信或者qq群，和大量的开发者一起学习和探讨，这样在不断的讨论和学习过程中可以得到不断的成长。有使用上的疑问或者问题也可以直接和我们的开发或者架构师沟通。Q：冷启动支持需要有低延时的应用吗？A：如果对冷启动比较敏感的业务，可以通过预置并发来应对冷启动的问题，设置了预置并发后，服务保留一定的最小资源量，这些资源量长时间存在，更大的并发到来时再通过自动伸缩去拉起，就可以保证服务既可以解决低延时的问题也可以应对大请求的流量Q：如果部署在腾讯云的Serverless服务受到DDoS攻击怎么收费？A：用户可以设置并发的上限，更多的请求自动帮着挡住，不会把这些流量放进来，实际消费用到消耗的 Serverless 请求才会收费，其他的挡在控制并发外的请求我们不会收费。Q：平台具体实施中如何避开Serverless的劣势？A：关于 Serverless 的劣势，一是冷启动，二是开发习惯的一些改变，这些劣势可以通过一些手段避开。冷启动的问题可以通过预置并发等高阶能力解决，web 场景用 Serverless Components 的能力就可以帮助抹平中间的差异Q：企业应该如何设置Serverless Components？A：要看具体的应用场景，腾讯内部的团队在使用上也有各种差别，主要还是依赖具体的应用场景和需求。Q：Java这种启动慢的语言，未来可以在Serverless上应用吗？A：其实国内 java 开发者比较多，我觉得这是非常有潜力的发展方向，我们也在考虑启动比较慢的 java 应用如何部署到 SCF 上面，这是我们努力的一个方向。

讲师简介