发现函数计算在某些场景下真的可以省钱

[cdlnls]

最近用阿里云的函数计算部署 stable-diffusion 玩，发现竟然可以挂载 nas ，所以它就能实现数据持久化。 (题外话，跑 stable-diffusion 并不便宜)

---

在程序的的访问量少的情况下，成本会低得离谱，要比直接部署在 ECS 服务器上便宜得多。

昨天试着跑了几个程序：

• typecho ，使用 sqlite3 作为数据源，在只有一个人访问的情况下，成本是 0 元
• gitea ，也是使用 sqlite3 作为数据源，虽然能跑，但是项目每次 push 代码的大小不能超过 32M ，否则会失败。成本是 0.02 元
• filebrowser ，可以比较方便的管理 nas 上的文件，成本是 0 元

nas 文件存储服务，也是按量付费的，在占用不多的情况下，会被抹零。我目前是 500 多 M 的大小，每小时费用都是 0 元。

所以，如果程序只是间歇性的需要使用，不需要提交大文件，价格就可以很低。可以用来部署 在线备忘录、git 仓库、密码管理器、webhook 。

缺点是可能会破产。放在公网上公开访问，如果被刷流量，账单估计很难看，这个就不太可控了。

但是如果在域名不对外公开的情况下，只部署一些自用的服务，这个应该是最不花钱的方案了。

[woooooOOOO]

云函数是支持 GPU 的吗？

[woooooOOOO]

@woooooOOOO 是不是可以搞个模型调用集合

[whileFalse]

我理解 sqllite 几乎没有扩展性，并发到了一定程度还是要换正经的 DB/nosql 。

把“玩 lambda”本身当目的还不错，真想用还是算了

[cdlnls]

@woooooOOOO 是的，现在是支持 GPU

@whileFalse 确实没什么扩展性，但是单实例并发不高的情况下还是可以用的。现在主要是看到还可以挂载自己磁盘，数据能持久化，可以玩的就比纯“lambda"多一点了。

[Conantv2]

云函数很适合帮非交互式产品剥离很少用到的用户交互功能，比如企业网站的咨询表单、应用的用户反馈、博客的评论框，如果把这些挪到云函数，服务器本身就可以做到非交互式，提升一个安全等级。

[Bingchunmoli]

还有个问题，用的流量上来请求数和流量带宽是不是单独计费的

[caomingjun]

gitea 还能挂云函数上？有教程吗？

[coolcoffee]

云函数目前的商业模式还是比较鸡肋。小客户群体用量少，云厂商赚不到什么钱就开始各种改规则；大客户用量大，发现还不如服务器包月划算。

[perfectlife]

多说一句 个人感觉 用函数计算部署服务可维护性比较差，数量多了维护起来太累了

[laminux29]

不可维护的玩意，真有人敢用？

[cdlnls]

@laminux29 类似函数计算这种服务设计出来时，它就把“运维”作为服务的一部份来卖了，所以维护自然是不需要的了。

@coolcoffee 我也十分赞同这个观点

[cdlnls]

@caomingjun 基本上部署项目，需要用到数据持久化时，设置 NAS 挂载数据目录就行。 所以这里 gitea 部署的时候只要把 NAS 挂载到 gitea 的数据目录就可以了。

[woooooOOOO]

我试了一下，部署了一个图片转动漫风格的模型，总是生成失败，5 次成功一次的感觉

[caomingjun]

@cdlnls 但是 gitea 不是需要持续运行的吗，比如内部有很多定时任务的（ actions, mirroring, ...）。直接 Docker 部署居然能用？

[joyanhui]

@caomingjun 我这几天也在测试阿里云的 servless,确实你说的这个问题很难受。

golang 的协程 、定时任务，基本没法用。 如果选择保留实例，费用就又上来了。而且保留实例虽然能保证 cpu 不会冻结，但是新换起的弹性实例是没法不冻结的。依旧会导致协程被冻结。


有一些后台功能调整代码可以实现比如每次响应的时候用检查时间戳的方法来触发某些不是很严格的定时任务，有一些就没办法搞定了。

[cdlnls]

@caomingjun 异步的任务都处理不了

[keepRun]

被盗刷问题可以应该可以通过鉴权解决吧，比如套个 cdn ，根据生成的 sign 检验，或者让 cdn 回源鉴权服务器来判断是否允许访问，阿里云都在 cdn 配置里给出了解决方案，建议仔细研究下，再配合 cdn 的云监控的下行流量告警、带宽封顶规则，就解决了盗刷问题。

[lyc8503]

个人用起来很方便, 随便写的代码就可以发布, 还不用刻意维护, 用量小几乎不要钱(以前还是有免费额度的, 现在没了)

不过对大型应用很不友好了, 适配 serverless 开发成本高, 迁移困难, 加上云函数在用量大时价格大于 ECS.

再者难以确定的预算可能也是个问题...

[ibegyourpardon]

作为主功能来说确实不是很适合，但作为非主业务的补充，一些边缘化的事情，写进主单体或者部署个微服务反而头疼，如果正好用量占比又不大，云函数我觉得非常合适，我自己就有大概二三十个类似的云函数。

它们有一些共同特征，本身逻辑简单，没太多状态，放进哪个仓库或者服务都觉得不是很符合语义或者模块划分，单起个又恶心，这个云函数的服务本身甚至可有可无，也许只是个实验特性，这一类我现在优先会选择用个简单的云函数快速跑起来，先满足了业务需求再说。

当然云函数也有一些问题，本身写起来如果依赖的东西多，放云函数里跑限制一堆，很麻烦，数量也很容易暴涨。但数量保障我觉得就是没规划好，说明不是一些适合放到这里面的服务。

我大概二三十个，有的一两年前的我都快忘了代码了，真要更新迭代我十有八九不会去修改这个云函数，而是去直接快速重写一个，很大可能一天内就搞定了。这也是我会把云函数用的地方，有一些属于不需要长期更新迭代，但会长期使用的轻量级业务，我都会扔进去。

而一个足够大型的系统，十有八九总能找到这样一些类似的边缘的业务。当然要不要上云函数那是见仁见智。

我这周才刚又写了一个近似于采集系统的东西，非典型业务，不适合抽象起来放进现有架构，又急需，以后又基本没什么更新，用量不大，一天目测就几百次调用，这种我就是一天写完，一天测试，丢上去完事。

过几个月也许有迭代了再说，大迭代就重写拉倒。

[huyujievip]

@joyanhui 云函数主打无状态服务呀，你这起点就错了，强人所难