前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >【腾讯云Serverless】腾讯云Serverless + Typescript实践

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

原创
作者头像
Juli
发布2019-08-22 15:24:27
147.2K1
发布2019-08-22 15:24:27
举报
文章被收录于专栏:Serverless的前端项目实践

目的

最近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,输出到根目录

代码语言:javascript
复制
![image](https://user-images.githubusercontent.com/23744602/61192443-e1a6ba80-a6e6-11e9-98f9-c79aaed5cfa3.png)
代码语言:javascript
复制
template.yaml
​
CodeUri改成根目录,Handler改成 index.main_handler,即跟cli生成的一样
​
![image](https://user-images.githubusercontent.com/23744602/61192437-d9e71600-a6e6-11e9-96ae-b298715c0d2d.png)
代码语言:javascript
复制
编译后结果
​
![image](https://user-images.githubusercontent.com/23744602/61192447-e9665f00-a6e6-11e9-926c-43eaea8c0302.png)
代码语言:javascript
复制
最后部署到云上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分支为第五次尝试。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 目的
  • 项目介绍
    • 想法
      • 实践
        • 成果
          • 总结
          相关产品与服务
          云函数
          云函数(Serverless Cloud Function,SCF)是腾讯云为企业和开发者们提供的无服务器执行环境,帮助您在无需购买和管理服务器的情况下运行代码。您只需使用平台支持的语言编写核心代码并设置代码运行的条件,即可在腾讯云基础设施上弹性、安全地运行代码。云函数是实时文件处理和数据处理等场景下理想的计算平台。
          领券
          问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档