【腾讯云Serverless】腾讯云Serverless + Typescript实践

目的

最近serverless愈来愈火，我刚好在培训，比较有时间去尝试一些新东西，所以趁这个时候去使用下serverless，尝试使用typescript和nodejs开发，部署在腾讯云scf上的一个小工具，探讨下typescript + nodejs + scf的最好实践模式，并同时抛钻引玉，希望有同学提供更好的方案。

项目介绍

想法

由于本人平时会追一些小说，动漫，电视剧等，但是它们更新的时候，我一般是不感知的，都是等我得空或者睡前的时候，我才会去它们的网站去查看下它们是否更新。如果有这么一个工具，能够在它们更新的时候，告知我，它更新了，更新了啥，那么我就不需要老是用手机去查询，对我起到了一定的便利作用。

这放在我没有接触到serverless之前，我的想法是这样的：写一个这么的程序是不难，但是我得去买个机器去部署啊；如果有问题不能及时发现同时又得上机器查日志；还得自己去控制程序定时爬取的逻辑等等等。总的来说就是，实现与维护一个这样的程序的成本远大于了其带给我的便利，让我有想法却懒于行动。

但是了解serverless的概念后，以上提到阻碍我行动的问题变得不再是问题，例如部署难题，使用serverless就是使用云供应商提供的开发者工具创建函数，打包上传代码即部署成功；又例如定时爬取逻辑，使用其提供的定时触发器能力即可，都大大方便了我的开发，让我更专注于代码实现。这里我不会很官方地去说serverless的概念以及好处，仅是从一个开发者的角度去阐述我的想法。

实践

• 流程图 程序的整个流程图如下图所示，逻辑很简单，这个项目的目的不在于实现一个多厉害的功能，而在于ts + node + scf的实践方式的探索。

• 开发 开发能在scf运行的nodejs程序的其实与传统的开发nodejs程序在语言编写上并没有太大区别。比较明显的不同在于，我们开发时得有一个入口的函数，比如像这样：

更具体的入门文档，可以看此处，跟着文档一步步学习编写一个简单的函数。接下来回归正题。

• 环境搭建
  • 首先为了方便开发，建议安装腾讯云scf提供的命令行工具或者vscode插件。但是这里我开发的时候vscode插件还没发布，所以这里主要使用命令行工具，命令行工具的安装与使用的文档，具体可以看此处。
  • 安装好后，使用 scf init（具体参数得去看文档填写，这个提个建议，scf init提供交互式操作，采取问答的模式去创建）创建一个项目、项目文件很简单，一共就四个文件，前三个，应该不多做介绍。第四个文件template.yaml称为模板文件，简单来说是描述这个函数的文件，比如函数的环境变量，触发器类型等等，具体还是前往文档处查看吧。

  

  • 接下来，就是正常配置tsconfig.json，如果没有安装typescript的同学请去官网安装，然后tsc --init就可以快速生成一个tsconfig.json，然后根据自己的需求配置即可。
  • 然后，就是编写npm scripts。 主要就三个操作，build，dev，deploy。 可以使用npm scripts把typescript的编译和scf cli的本地调试，打包和部署串联在一起，使需要敲打的命令简洁和语义化

  

  • 最后，将本地仓库与远程仓库关联起来。（这里提一个优化：有一种场景是用户已经创建了一个git仓库，现在需要将仓库里的代码写成scf模式下的代码，并配合scf cli使用，目前scf cli只支持init一个完整的项目，如果支持在一个已有项目中快速生成调试和部署的yaml，对开发者来说是一个比较方便的功能）
• 编码

我的主要逻辑代码分为上面的文件。

• index，没什么好说的，就是一个入口文件，负责组合其余模块的逻辑。
• config以及config_extra，config_extra文件放了我的隐私配置，例如redis的host，port和密码以及邮件服务的授权码等，这些配置通过配合.gitignore是不会提交到远程git仓库，而config文件则是引入config_extra文件中的配置，并与一些通用配置进行merge，然后输出到各个模块。（注：此处也可以好好利用scf提供的环境变量功能，很适合这种场景，具体文档）
• config_extra_demo，告诉别的开发者，config_extra文件应该如何编写。
• mailer，封装邮件服务的初始化以及发送邮件方法
• redis，封装redis的连接以及同步set以及get方法
• task，暂时简单封装了下初始化以及执行的通用逻辑。但日后该工具扩展，此处仍得考虑如何抽象以及通用化。
• util，封装了一些公用方法，例如封装了retry方法，来包装一些异步函数。

上面简单介绍下主要逻辑代码的文件，具体的实现，有兴趣可以移步到 github地址 查看

• 调试 上面也有提到我编写的npm scripts里有npm run dev的一条。本人开发这个项目时，调试都执行npm run dev来进行调试。这里提一下，测试环境一般是需要和正式环境隔离的。所以可以新建一个 env.json文件，里面填写 { "NODE_ENV": development } 并将npm script中的dev命令改成 npm run build && scf local generate-event timer timeup | scf native invoke --template template.yaml --env-vars env.json 然后在配置文件中根据process.env.NODE_ENV变量来判断是测试环境还是正式环境，并填写对应环境依赖的服务的配置即可。
• 部署 上面讲了这么多，其实都不是我最想表达的，因为我并没有在上面遇到一些很棘手的问题。而在部署的时候，我才发现在使用typescript时，无法在腾讯云scf目前的部署要求以及项目的文件目录管理中做到完美的配合。

后面和同事讨论后，还是有不错的方法是达到两者的平衡。下面是我的多次尝试的一个过程。 如果不使用typescript，仅使用js编写nodejs程序，则不需要编译的过程，部署函数时，只需要打包然后部署即可；但是使用typescript后，则多了一步将ts代码编译成js代码的步骤。为了管理好项目的文件目录，我倾向于ts和js文件分别存放在不同的文件夹，例如，src文件夹存放ts文件，dist则是编译后得到的js文件。我一开始的文件目录便是如此。

• 第一次尝试 文件目录：

tsconfig.json 指定编译src文件夹下的ts文件，输出到dist文件夹

template.yaml CodeUri指向dist文件夹

根据上面的配置，在本地调试是可以的。但是当部署到云上，测试是失败的。如果大家熟练的话可以立刻发现问题所在，打包没有把node_modules打包进去。主要逻辑代码依赖的第三方库全都找不到，测试当然失败了。

• 第二次尝试 根据第一次尝试，我使用npm scripts的pre钩子，在执行部署前，编辑ts代码，同时把node_modules拷贝到dist文件夹，然后再打包部署解决了这个问题。 package.json

copy_node_modules.js

dist文件夹下的文件

虽然这样做可以运行了，在本地文件目录管理合理，但是提交到云上的代码是编译后的，基本没啥可读性，就是一坨能运行的东西，项目代码也不完整。所以个人认为，最完美的是本地开发的项目代码和交到云上的项目代码是一致的，不需要通过额外的脚本去阉割。虽然目前腾讯云scf控制台的webIDE还只是能看入口文件，不过之后会接入cloud studio，起码可以看到整个代码文件夹的每个文件，说不定以后就支持在线支持typescript编译（虽然不知道可不可能）。所以本人开始了第三次尝试。

• 第三次尝试 我有一个想法：template.yaml中指定的Handler，即入口函数，从index.main_handler 写成 文件夹/index.main_handler，即入口函数可以在某个文件夹里。 我在template.yaml处的Handler写成dist/index.main_handler，CodeUri写成了根目录，这样就可以打包整个文件夹，然后指定Handler为dist文件夹的index文件的main_handler函数。 template.yaml

本地调试时，是成功的！ 但是在部署的时候，

额，好吧，我觉得是这个方案是不行的了，因为不符合scf的要求，通过不了校验。

• 第四次尝试 这是我第四次尝试。但是不是最完美的，在文件管理退了一步，允许ts和编译后的js放在一起。这样能做到把整个项目都打包上去，而且可运行，但是ts和js放在一起，文件管理不太合理。修改的地方如下： index.ts文件从src文件夹移动到根目录 tsconfig.json 编辑根目录下的index.ts和src文件夹下的ts文件，剔除node_modules，输出到根目录

![image](https://user-images.githubusercontent.com/23744602/61192443-e1a6ba80-a6e6-11e9-98f9-c79aaed5cfa3.png)

template.yaml
​
CodeUri改成根目录，Handler改成 index.main_handler，即跟cli生成的一样
​
![image](https://user-images.githubusercontent.com/23744602/61192437-d9e71600-a6e6-11e9-96ae-b298715c0d2d.png)

编译后结果
​
![image](https://user-images.githubusercontent.com/23744602/61192447-e9665f00-a6e6-11e9-926c-43eaea8c0302.png)

最后部署到云上scf，是可以运行的，而且是把整个项目都打包了上去，日后腾讯云scf接入了cloud studio，webIDE看到的文件架构和本地看到的文件架构是一致的。

• 第五次尝试 兜兜转转，有时候问题解决很简单。和组内同事讨论后，一位大佬同事点出： 可不可以在根目录写一个index文件，然后调用编译后的index文件的入口方法？。 一语惊醒梦中人！是的，一开始就没注意到，还可以这样解决，思维一直在一个圈子里绕来绕去，没有跳出来。这样做的成本很低，而且能达到了我之前说到的理想状态： 本地开发的项目代码和交到云上的项目代码是一致的，不需要通过额外的脚本去阉割 实施方法即是，把typescript文件放在src文件夹下，编辑后的js文件放在dist文件夹下，在根目录编写一个index.js文件，文件里的main_hanlder方法调用编译后的index文件的入口函数，下面是一些核心代码。 index.js

tsconfig.json

template.json

编译后结果

成果

简单展示下代码线上运行后的结果。

总结

上面说了这么多，这里给一个总结就是：

虽然腾讯云scf没有原生支持typescript，但是经过一些方法还是可以做到两者的完美配合。

首先本地开发是没啥问题的，上面提到的尝试，都是为了能够在本地调试成功的同时可以部署到云上。

主要是部署的问题，其中可行的三个尝试：

第一个是通过一些额外的方法去适配，但是做不到云上的项目和实际的项目的一致，如第二次尝试。

第二个是文件管理上退了一步，不做到极致的分明，如第四次尝试。

第三个是在根目录写一个index.js文件，调用具有真正逻辑的入口函数，做个转发，如第五次尝试，也就是本人认为目前最好的实践方式。

最后，以上的五个尝试，是本人开发的时候的想法与实践，也许不太正确，有误欢迎大家来批评。如果大家有更好的方法，欢迎讨论。五次尝试的源码都在github仓库，前四次尝试均有对应分支，master分支为第五次尝试。

​