关于 severless 的疑问和痛点

[fanyingmao]

短暂入职了一家公司使用 aws 的 lambda 开发的，离职的原因之一就是用了 lambada 这个我不了解的技术，跑路的原因之一是感觉用了这个技术会降低我的开发效率。

1 、一个接口调用 severless 运行需要将所有函数接口代码加载到内存，运行玩之后就释放，还有对于数据库之类的连接就不是用连接池的方式要不断创建断开，这样运行效率不会比较低吗？

2 、使用了 severless 无法用之前开发的断点调试方式，也许应该是有办法的断点的，但是之前的开发者没有用断点，都是打日志的形式，这样调试起来效率就比较低了。

3 、接手的项目日志只有本地调试有打，部署后由于是 severless 无法存日志于本机，项目并没有做日志功能，如果是用户端反馈 bug，则排查起来比较困难。

4 、接手的项目并没有用主流的 web 框架来开发，而是自己对接口调用进来的像 url，get/post 进行 swich case 或 if 来处理的，这样无法与主流技术保持一致，我想对 koa 之类的框架应该有一些中间件实现对 severless 的支持吧，然后如果后面不想用来，可以比较方便地切换 severless 服务商或者运行在自己的服务器。

5 、部署不方便，要在 aws 的后台传 apigetway 文件，然后再传函数实现部分的代码，无法沿用我以前的 shell 脚本上传方式，加上 aws 网站太慢了，效率有点低，需要额外学习 aws 的开发文档然后写个 shell 脚本。

6 、项目中的 apigetway 文件是 swagger 的 yaml 文件，和接口实现部分是分开的，这样开发需要两个文件间跳转查看修改并保持一致，效率有点低，容易出错，我希望吧 swagger 的接口文档写在对应接口实现的注释中，然后转换成 aws 需要的 yaml 文件。

上面的一些开发痛点也许查一下资料或者看 aws 文档就可以解决了，但是之前的人没有处理，然后我也没兴趣学 aws 的东西，因为 severless 开发起来不够自由，虽然降低了服务器维护的门槛，但是开发与云服务商强相关了，日后我用阿里或腾讯云的 severless 不是还要看对应服务商的文档修改代码，还有就是服务商的 severless 感觉可能有一些坑，然后解决资料又特别少。所以我不想踩 severless 的坑了。

最后我还是想知道解决方案，对于以上痛点有人知道怎么处理的吗？

[xiangwan]

可以看下阿里云函数的文档，你说的这几个问题大部分都有解决方案了。
1 有专用驱动，或者用云数据库
2 阿里云函数有 vsc 插件可以断点调试
3 可以接入云日志
4 已经有几个比较流行的相关的框架了

结论部分的槽点有点多。。。

据说 serverless 是趋势

[chihiro2014]

serverless 是趋势啊，毕竟让 crud 的员工去写这种函数，避免碰到核心业务 2333，某种意义上还省钱

[lhx2008]

十几年前 SAE 就是这么玩了。。现在还是没进步
断点调试的话，其实本地写代码本地调也没有什么问题吧。前面 5 点都不是问题。

[cassyfar]

lambda 是个政治产品，不推荐使用。

1.你是用 relational DB 配合 lambda 吗？这个貌似是硬伤，推荐转成 dynamodb 。
2. 这个是硬伤。
3. cloudtrail
4. 这个推荐 k8s
5. api gateway 其实是个很好的设计思路，不是槽点儿吧
6. API gateway 的 API 可以直接从 你 service 的 swagger 文件导进来自动生成的，你只需要专注 service 的 API 。

[ysc3839]

1. 这是看不同 Serverless 平台实现的。不过靠谱一点的平台都不会运行完就释放吧？许多平台是一段时间没有请求才释放，释放后又遇到请求的话再启动。
2. 如果你说的是远程调试的话，那大部分 Serverless 平台确实是不支持的。要支持也很麻烦吧？印象中 Node.js 的调试协议是没有认证机制的？
4. 这是这个项目的问题，许多 Serverless 平台是用 Node.js 标准的 req, res 接口来处理 HTTP 请求，可以直接配合 express, koa 来使用的。少数使用私有接口的也有 wrapper 转成标准接口。
5. 这是平台的问题。比如 Firebase 和 Vercel 都提供了命令行客户端来提交代码。

[whileFalse]

卧槽什么公司啊，想去啊
这个公司思想太前卫了……但看起来技术没跟上

即没使用成熟框架，也没有玩得明白 AWS 和架构的人
感觉弄好了的话你们的生产力能提升一倍不止……

[594duck]

我在澳洲接触了一些用 lambada 的企业

我就这么说吧，人家只把 lambada 当成定时任务跑一下维护脚本。比如 VPN 断了去改个端口啥的。

至于你说用 lambada 去 all in services 。

对不起 meetup 好几个会被人吐槽那东西了，在 lambada 甚至 serverless 开始的 17 年我就问了一个问题。这东西性能会好？我那叫被喷的惨啊，一堆开发来和我讲道理教我做人。结果缺点全让我说中了。

所以国内面向简历开发瞎搞你能信。

前几年喊的大前端取代后端这两年没声了。

[vcfvct]

1. 高并发的话, rdbms 确实有这个 connection pool 的问题, 如果你用 rds 的话可以试试'Amazon RDS Proxy'. 当然直接上 dynamodb 或者 query Redis(Elasticache)一般都不会有这个问题.

2. 这个可以用一个 local server 把 request proxy 到你的 handler code, 就可以在 vscode/intellij 里 debug 啦. 加上点其他 tool 还能 watch file system 然后 incremetal compilation 再 live reload on change.

3. 日志都在 cloudwatch 里, insight 挺好查询的, 也可以 pipe 到其他工具比如 Splunk/newrelic 去.

4. 中间件你真的想用 express/koa 这类框架也行, 最后无非就是处理一个 http request.

5, 部属到 dev/qa 简单测试的话可以直接用 aws sdk 的 lambda 部份写简单的 script(貌似你是用 nodejs, 一起语言也有), 只用本地 package 好(可以做其他的比如 tree-shaking)然后 update function 就可以啦. 正规的部属最好还是用 cicd, 尤其是 prod.

Serverless 不是 silver bullet, 但还是挺方便的, 不用去管 infrastructure 和 runtime, 也 auto scale, 价格又超级便宜.