前言
背景
我个人和公司用函数计算类云服务已经有两年多了, 函数计算, 云开发, lambda等类似方案最吸引我的有以下几点:
- 零运维, 甚至还附赠一系列运维工具, 比如自带灰度发布, 版本回退等功能, 还有日志收集, 指标监控等, 对于创业型小公司来说, 这套系统已经很好用了, 无需自己开发.
- 自动伸缩, 可以应付突发流量
- 按量付费, 对于很多没有流量的小项目(比如内部系统, 文档站点, 官网展示等)来说, 等于不要钱.
但是这类云服务原生使用的话, 有个很大的缺陷, 就是厂商锁定, 被微信云开发背刺的朋友们不用我多说了, 应该体会很深. 对于架构选型来说, 厂商锁定是一开始就要考虑和尽量避免的问题, 如果公司因为某些原因需要从A厂商迁移至B厂商, 如何能快速迁移, 总不能重写吧.
还有个问题就是代码管理, 因为云服务是默认一个函数一个入口, 一个功能. 但是我们写代码不是这样组织的, 随着业务越来越复杂, 代码会分模块, 分层, 分包来管理.
方案
简单总结一下就是, 云函数本地开发调试麻烦, 但是部署很爽; 传统框架本地开发调试很爽, 但是部署到服务器麻烦. 那能不能结合一下, 取两者的优点, 在本地用传统框架开发, 开发完成一键部署到云函数呢?
当然可以!
社区上涌现了不少这样的方案, 有的是厂商牵头, 有的是社区自发. 比如 Serverless Devs, Serverless Framework,Malagu等, 都可以让你快速地接入传统框架(比如nest, express, next等等).
这样的效果就是, 本地跟传统开发没有任何区别, 在部署的时候, 配置好云函数相关的设置, 然后运行npm run deploy xxx一键部署. 甚至你还可以部署到多处, 比如自购服务器上部署一份, 然后函数计算上部署一份, 前面加个负载均衡, 平时用服务器节省成本(函数计算量大了其实挺贵的), 高峰的时候切到函数计算自动伸缩. 也可以部分业务使用传统服务器部署, 部分业务使用函数计算, 根据业务场景选择合适的部署方案.
Laf
回到Laf, 大家都跑的是node, 理论上别人能支持的, Laf也能支持. 不过直接支持Http框架比较麻烦, 可能还需要Laf runtime级别进行一些支持, 我暂时还没有看. 目前测试了一下本地编译打包, 能正常跑通, 正在优化流程做成通用方案.
好了, 这章专门拿来讲些废话, 干货就留在下篇再讲.