V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
witcat
V2EX  ›  Cloudflare

基于 CF Pages/Workers/D1/KV,探索 0 成本部署应用的可能。

  •  
  •   witcat · 2023-10-15 21:55:08 +08:00 · 2120 次点击
    这是一个创建于 405 天前的主题,其中的信息可能已经有所发展或是发生改变。

    上次把一个普通的 Node + Nginx 应用转移到 AWS Lambda 之后,就没有再更新过了程序了,AWS 维护的成本也不低,让人没什么信心。
    虽然 Lambda 解决了一部分问题,比如免运维、低价,也许 serverless 本身也能避免一些内存泄露问题?
    但是产生了更多的问题:

    • 首先就是 AWS 的那个控制台是非常繁琐的,CDK 也需要学习,而且并不能正常的在中国区使用。
    • 如果访问频次低的话,会经常出现冷启动,链接超时。尝试过但最终没能解决。
    • lambda 可以使用非 serverless 架构的数据库技术,但如果想要最佳效果,要使用 dynamo db ,这玩意很强大但只能在 AWS 上用,学习成本比较高。
    • 中国区不仅只对公,而且收费也必须对公转账。有一个 10 块多的账单,我懒得转,索性就弃了。

    前一阵子刷 Github 看到一个热门库Hono,据说是转为 edge function 环境设计(其实就是本身功能比较精简,尺寸小,有一个高性能路由),作者似乎现在是在给 CloudFlare 做布道师。
    感觉 EdgeFunction + Hono 似乎可以在 Lambda 的基础上更进一步,更加简化其他工作,只要开发程序本身即可。遂开始把 lambda 上的程序转移到函数计算架构。
    Hono 有一个脚手架工具可以生成多个基于多种平台的模板。
    因为我是前端,所以最喜爱的是 Vercel ,Vercel 虽然也有函数计算,但是它的函数不能单独存在,必须存在于 Next.js 项目内。
    对于我的项目,我可能希望多个 workers 一起工作,不一定每个 worker 都有前端界面,这样 vercel 的方案就比较受限。
    鉴于现在 CF 的人气比较高,免费计划也很值,于是就开始研究了,经过最近的研究,个人有以下几个感受:

    1. 相比 AWS ,CF 有类似的地方,但文档更清晰和明确。wrangler 也比 cdk 要人性化很多。当然他们不是一个量级的,不知道 CF 如果的服务继续变多,文档会不会也很乱。
    2. 因为使用了这种无服务器的方式,最大的困难就是解决数据库问题。不可避免的要学习使用 D1 数据库,但学习它的成本也很低,它是一种 SQLite 数据库。这样有个好处就是一些入侵性比较低的 ORM 可以配合 D1 使用比如 drizzle-orm 、kysley ,这比使用 dynamo db 的门槛低了太多。
    3. 对 Javascript 程序员非常友好,可以直接部署 typescript 代码,而且 cf workers 就是一个特殊的 Javascript 的运行环境。

    总体来说,我的个人项目从 lambda 迁移到 cf 以后,各方面是提升的。
    冷启动问题没有了,而且感觉 wrangler 很简单很可控很放心。
    相比 Lambda 的花费,现在花费更低了
    原本的 postgres+primsa 本身就与 serverless 相容度低,而且 postgres 用在小应用上没有必要。
    最后是 CloudFlare 天生比较抗攻击的优点。有时候小公司做些东西被小鬼盯上了很容易被流量攻击打死,这也是我拒绝自建网络服务的一个很重要的原因。
    总体来说现在不管程序还是架构还是维护都比以前更轻巧了,继续开发维护也更加有信心了。
    不得不感叹,安全、抗打、低价,CloudFlare 才是未来啊!(对于小公司或个人 sideproject ,我是这样认为的)
    不过这么好的东西,问题当然还是有的。就是 cloudflare 国内不能直接访问。
    但通过转移域名解析服务器到 cloudflare 是可以实现直接访问的。
    听说墙封死 cloudflare 是可以做到的,不过因为 cloudflare 用的公司极多可能造成损失,所以大概还是可以通过这种方式访问吧。
    其他的,我看对象存储和消息队列也是有的,构建一个功能全面的 App 应该没有太大问题,如果不在乎有一天无法访问的风险,我觉得还真是一种相当先进的服务托管方式了。

    第 1 条附言  ·  2023-10-15 23:00:43 +08:00
    写的比较急,写的有些问题:
    “dynamo db ,这玩意很强大但只能在 AWS 上用”:Dynamo DB 可以在外部用,只是多数情况下它都是和 Lambda 一起用。
    “遂开始把 lambda 上的程序转移到函数计算架构。”:这里应该说是边缘函数计算架构,workers 是用全球的节点来计算的,lambda 以我的了解应该还是限制在某个区域内。
    9 条回复    2024-05-12 18:38:26 +08:00
    witcat
        1
    witcat  
    OP
       2023-10-15 22:09:39 +08:00
    关于控制台问题:
    locode nocode 其实效率也不是很高,postgres 函数钩子也太怪异。
    所以最终还是开发了一个管理面板,但好处是我可以把 function 和 pages 放在一起,这样相当于在同一个域内,而且那些管理相关的路由就只有对应的 page 能够访问,对于管理员的鉴权如果不想实现,可以直接打开 cloudflare 的 zerotrust 鉴权。
    最终写入的 api 会只存在于管理面板内。那些读取的 api 会放在另外一个 worker 内。
    结构简单,而且绝对安全。
    chihiro2014
        2
    chihiro2014  
       2023-10-15 22:26:58 +08:00
    是的,其实 R2+D1+pages 可以构建个小型百度盘
    Kirscheis
        3
    Kirscheis  
       2023-10-15 22:36:04 +08:00
    CF 现在能玩这么花了吗。。一直只会用他的 DNS 和 CDN

    cf workers 心动很久了,主要是确实便宜,而且还支持 rust
    0o0O0o0O0o
        4
    0o0O0o0O0o  
       2023-10-15 23:15:52 +08:00 via iPhone
    并且 D1 without read replicas is strongly consistent ,配合 edge network ,太杀手级了
    airyland
        5
    airyland  
       2023-10-15 23:24:05 +08:00
    hono 不错,我有个 AI 应用部署在 cf worker 上已经有半年没遇到什么问题。
    lupus721
        6
    lupus721  
       2023-10-16 09:47:34 +08:00
    在用 microfeed ,全托管到 cf 上了,不过感觉还是摸索实验为主
    cxumol
        7
    cxumol  
       363 天前
    https://github.com/cxumol/URLinkCat 看看全栈部署在 cloudflare 平台的云书签, 用于整理大量链接并分享, 可供多人使用
    linyongxin
        8
    linyongxin  
       309 天前
    低成本部署这个对于无交互、更新频率很低的网站来说很有用
    非常有意思的想法,CloudFlare 可以抗攻击,保护源站很好,就是国内的速度太慢了。
    我之前甚至把 wp 安装在 serverless 上,打算全站生成自动部署到 cf pages 和 cdn ,可惜环境有问题无法实现,wp 无法使用静态化 static 插件
    602120734
        9
    602120734  
       195 天前
    cloudflare worker + page + d1 + r2 可以全栈应用了,就是国内不行吧?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   961 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 21:12 · PVG 05:12 · LAX 13:12 · JFK 16:12
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.