cloudfalre worker 也许是目前 web 服务部署的一种最佳实践。
- 先前我问了一下,如果使用 cf 不考虑大陆,数据中心选择哪里好,后面我将我原有的 go 服务使用 worker 重写后, 速度比以前提高太多。
- 这个服务我自己做了一个用户注册系统,主要是帮用户申请签名证书,以及商品订阅,以前用户备份的配置信息。js + d1 数据库完全够用。 关键的是还快,没有内存担心的问题。
- 涉及到 cloudflare api 相关接口, 以前无论是部署到海外还是国内, 接口都慢的要死, 使用 worker 后, 快得无法想象。
- 我以为使用 cloudflare 如果接口超过 cpu 占用 10ms ,接口就会超时, 从我使用的看来,没有这个问题。
- worker 加上 d1 ,加上 cf 的证书,认证,限流,安全验证, 可以说从 serverless 的思想,重点狙击个人使用 springboot ,golang 写的 web 服务。
- 当然也有很多限制, 比如储存文件,文件上传的得使用其他的对象储存。可能没有直接写磁盘方便。国内可能不能正常访问。如果 cf 关闭了这个服务,迁移代码很麻烦。无法使用一些 linux 命令处理一些业务逻辑,这个目前无解。
总得来说如果你有一个简单的服务,如果不想自己处理证书,安全,限流等等一系列的问题, 那么迁移到 worker 目前看,是一条不错的路子。这么香,况且还免费,不是我吹,要是国内能提供这种服务,估计国内阿里云和腾讯云会受到重创。在这种情况下,springboot
和 go 不再是我的优先考虑了。
+1 ,有 all in worker 的想法
Serverless 的优点是在 free tier 也就是用量很少的情况下省钱。再就是独立模块开发比较快。
我司之前有个图像分析的工作流尝试通过 cf ,即使是 paid plan 可用性也不是太好,如果换算成 sla 大概在 99.5% 左右吧,队列中的任务经常三五分钟的重试。
不过瑕不掩瑜,特别是随着 cf 支持 js 之外的语言,我个人很多自动化项目都上了 cf 。我尝试过好几个 serverless 平台,cf 还是更懂开发者的。
存储文件直接 cf 的 r2 就好了。
d1 里要做好索引,有些查询会走全量搜索,当数据量多的时候,多查询几次会超量。举个例子,假如你有个表数据是 10 万记录,查询的时候没走索引,那么一次查询就占用了 10 万次查询的量。turso 和 d1 都有这个潜在的坑,因为查询量是按照扫描量来算的
我刚好在实践这个技术栈,一个基于纯 cloudflare 技术栈的动态博客: github.com/penx-labs/penx ,并且实现了一键部署: penx.io/self-hosted
👍
worker 跟 aws lambda 之类的相比有什么优点?
国内之前腾讯小游戏还能免费用他家的 servetless ,我也觉的香。后面用户一多就开始收割了
从 2000 年开始的免费 php 主机,免费云主机,到现在免费的 serverless 。
severless 的思想, 关注于业务逻辑。 不折腾 https 证书,限流,防火墙,认证,在 cf 提供的其他功能,将传统的运维问题足以简化, 便能够快速部署一些业务逻辑简单的服务,并且是高可用的。
从传统云主机的份额下,撕裂出一块口子,为小型企业,个人开发者提供另外一条快速开发之路, 甚至不再需要运维,不需要懂 linux ,一样能做一套服务, 开发者在 cf 平台下就能够胜任, 一定额度的限制下之下,这一切还是免费的。
php 免费主机: 自己部署 php , 限制多,自己处理证书.
免费云主机: 自己部署应用,有内存和磁盘的限制,自己处理证书。这些都会遭受攻击,甚至会被暂停服务。
cf 的 worker , 在上述的条件下有了阉割,但是自动证书,免费的限流、防火墙,认证,甚至 d1,r2 还有快照,这些几乎是传统云主机的痛点。
- 使用 worker 没有证书的困扰,ssl 错误的生产事故不再。
- 限流功能随便配置,免费足够。
- cf 的认证策略特别多, 相信我,肯定有你能够用到的。
使用 d1 数据库,还有快照, 你自己部署云主机备份过自己的数据库快照吗?
www.cloudflare.com/zh-cn/learning/serverless/serverless-performance/
cf 自己的对比,自己琢磨一下。
Cloudflare Workers 连冷启动都没有,而且 IO 等待的耗时不计在内,只算 CPU 时间,比 Serverless 好太多了
一般都会在 cf worker 部署什么内容呢? 大陆不允许访问,那…
servetless 确实很好用,灵活性强,省了很多成本
用 itdog 测试一下?
cf worker 是个大坑,已经有 2 个业务从 cf 迁移走了。
一旦上量,cf 会一直建议你买企业版,然后你的 worker 和 r2 的账单会无法想象。
cf workers 确实好用,唯一不行的就是免费版的 cpu 时间太受限了,开个 paid plan 就能用得很爽
serverless 对于体量不大的服务来说确实是最佳实践,但是如果体量上来之后,一方面有很多有状态服务(比如云下的非托管数据库),serverless 和这些服务交互有点麻烦,那还不如把计算也放在一起。另一个是 serverless 的可观测性不好做,如果所有东西全放在 k8s 里一把梭就很直观。最大的阻碍是目前国内的开发观念还需要更新,很多人还是觉得有个服务器看着才安心,但是这几年境外用 ts 全栈+serverless ( vercel/cf 等)已经发展得很好了,国内还是 spring 全家桶+前端( vue 等)+云服务器/托管 k8s 比较主流
你说的上量量有多少?
我一直推荐的个人开发者和小企业免费使用。
worker 的问题是,延迟只在你完全不考虑状态的时候还行,d1 的访问延迟太离谱了,kv 稍微快一点,但也不够快,要性能还得上 durable object 。。。(拿来部署 tg bot ,发现延迟问题很明显,tg 的 webhook 响应时间普遍在秒级以上)
cpu 密集型,我暂时没测试,我有些一些加密验证的 需求, 我准备测试一下后, 看看情况。10ms 确实太离谱了, 对非对称加密不知道能不能用。
美国吧
我 r2 选择的就是美国
1 国内访问 cf 都是去美西
2cf 自己主要数据中心应该都在美国
这类服务有 2 大问题让人很难下定决心。
很典型的“除了优点全是缺点”,按量付费看似很便宜,但控制不了账单,账单是失控状态的还怎么玩呢。
1 、理论上资源无限就意味着账单无限。
2 、随便被攻击或者恶意流量怎么办,都是面向用户的东西。
3 、如果账单可以限额,也不管用啊,达到限制是中断服务呢还是怎么办呢。
第二大问题便是难以迁移。
4 、也就是你用了 CF ,要迁移到其他服务商不会容易,然而就算能迁移,这个账单 bug 还是存在。
这也是为什么大家倾向于租用服务器/VPS ,因为账单可控啊。
个人玩玩就算了,也有被人恶搞的风险,要是虚拟主机/vps ,最多就是打爆了被服务商赶走,这种服务咋整,不管是国内还是国外,欠账单的巨额款,要怎么办呢。
如果只能个人玩玩,且风险大,我个人用都得藏起来,那真是兴趣不大,事实上我也在用 worker ,但只是用来跳转页面用,不管拿它来做什么,都担心超过配额,归根结底,没意思。
其实企业也一样,预算也是重要的一环,不可控的预算企业也怕怕,管理人员也不是傻子,真要长久干都是要估摸好预算否则很容易出事。
Worker 可以使用 Go 啊...
当你收到 35k 的账单时就不会这么想了
#21 不可以吧,原生只支持 js/ts ,python 和 rust 都是后加的还在 beta ,除非用 wasm ,那可以支持各种语言了
weread-challenge.techfetch.dev/
这个开源项目全用 workers 托管的,几分钟就做好了,0 成本。但是根据我非常浅显的对比,5 美元的起步价增加的内容不算多,最比如免费的提供每日最多 10w 次请求,一月是 300w 次,而 5 美元起步的是限 1000w 次请求,更多的请求按使用次数收费。
另外阿里云和腾讯云有新注册用户三个月有限制的 serverless ,阿里云的是预付费,起步价就很贵,请求次数购买后还有时间限制。
对比一圈后,CF 的这个 worker 或 page 的确是最便宜的。而且 severless 的代码和 server 上的代码有很多都是通用的,开发上也省时省力。
阿里云的 serverless 的流量费好像是另算,cf 只算请求次数,流量不计费。
腾讯云 SCF ,阿里云 FC ,用户并不多,如果免费说不定尝试的人能多一点。
这种设施,可能更适合个人或者没什么流量的服务,流量一大不见得省钱,账单也不好估算,SLA 也没保障。
- 绑定平台,在不同平台之间迁移很困难。
- 主流框架支持度低,熟悉的的人少。
- wordpress 等现有产品支持的不好。
- 第三方库,比如微信支付宝 SDK 支持的不好。
- 证书,安全,限流其实云网关都做的很好,开箱即用。
说是最佳实践,我认为过于夸张了,是不是良好的实践都不一定,谈何最佳。
看了 www.cloudflare.com/zh-cn/learning/serverless/serverless-performance/,试图总结一下。CF worker 相对于 lambda 的优势有两个:
1) 服务运行在 edge 上,因此从客户到服务器的延迟会显著减少。
部署在 lambda 上的服务运行在某一个选定的数据中心区域,因此如果只有一个 lambda 服务的话,无论世界各地的请求都会被传递到这一个区域,被 lambda 服务处理完成之后再把回应从这一个区域传回到客户那里。当然对于大体量的服务而言,开发者可以在多地区运行同一个服务,再在 edge 上面依靠某些 load balancing 的方法把来自某一地区的请求就近传到相应的地区。但是搞定这些东西费时费力费钱。
CF worker ,以及 lambda@edge 把处理请求的服务放在(每?)一个 edge 区域,对于简单的不需要依赖服务处理的请求,CF worker 和 lambda@edge 可以在最边缘的位置返回用户的请求而不用把请求传到更远的数据中心。但是如果请求依赖其他服务呢(比如需要访问数据库),考虑到无论 CF 创建 D1 ,还是 aws 创建 rds 的时候还是需要选择区域的,我猜这些请求最终还是会回到某一个你选择的区域。那么这种情况下 CF worker 或者 lambda@edge 的优势就没那么明显了。
CF“在全球 200 个城市拥有数据中心”,但是这个比其他大云计算厂商多还是少我暂且蒙古。
2 ) CF worker 使用 V8 作为 Javascript 的解释器,相比 AWS 用的 Node ,启动速度更快。
serverless 冷启动慢好像已经是一个臭名昭著的问题。Node 虽然以 V8 为基础,但是应该有一套属于自己的运行时。考虑到 V8 为处理网页的 JavaScript 代码而生,而 Node 为把 Javascript 从浏览器带到服务器而生,那么 V8 比 Node 启动快也非常合情合理。不过我猜代价是一些 Node 代码没办法直接原封不动的迁移到 worker 的 V8 环境来。以及也许某些仅支持 node 的库没法在 worker 里面用。貌似 worker 现在有 beta 版的 Python 支持,没仔细看不知道是不是魔改版快速启动 python 环境...
总而言之,懒得迁移了,摆了。
是的,现在 worker 两种 runtime ,一种是 js/ts ,另外一种就是 wasm
个人开发者完全够了。 你 App 日请求已经 10w 次了, 这个时候你的收益肯定能够负担 5 美元 1 个月了。
很多说超预算的, 完全是没有预算的计划。 超过 10w 请求的这种, 还不愿意付费。 可谓是把老美的公益送餐, 中产还去白嫖的场景,发挥得极致了。
你只看到我说的流量了。 但是其他的功能是一个不看, 自动 https, 认证,限流,等等。 要不你看看国内云对网关付费的价格? 算了, 你还是别看了, 看了会绷不住的。
- 平台迁移问题, 确实是一个问题, 设置 cpu 密集型的都不适合这玩意,特别是免费套单。 即使换一个云主机, 使用 node 一样的能够运行。
- 啥叫主流框架? spring boot, go frame ? 其他微服务?
- wordpress 凭啥要适配 serverless ? 那为什么不适配 java, golang ,rust ?
第三库只要有 js/node 就能用,甚至直接用 http 接口就行。
目前能看到的风险, 迁移麻烦,cpu 密集型不能用,账单这一块不认可,防火墙就能阻挡大部分流量了,如果真有 dos 攻击,你用啥平台都无法避免停机+高额账单。避免 vendor lockin
我还以为 js 和 wasm 一码事呢
cf worker 最需要的是一个账单限额,不然一旦被 d ,就会很难受了。
自动续的 SSL 证书,限流都是很常见的标准功能,自己配一遍 nginx 要一刻钟?一年能配几次?算不上多大卖点。固定带宽遇到 DDOS 只会停机进入黑洞,没有额外账单。
第三库只要有 js/node 就能用?很遗憾,很多第三方库不支持 nodejs ,自己封装 http 接口可能要在加密解密校验上花点调试时间。比如微信支付,官方 SDK 就只有 Java 、PHP 和 Go 。
资源也限的很死,一个 instance 最大只有 128M 内存,也不能使用 fs 和 child_process 模块,express 这样的框架也不支持,引入一个依赖的时候,还得先搞清楚这个依赖支持不支持部署在 workers 。
限制太多,增加人力成本,也省不了几个钱。适用的场景太少了,就这也能重创阿里云和腾讯云,太过夸张了。
你有钱,怎么搞都行。
worker 最大的问题,他其实基建这一套,包括他的 d1 ,r2+cache ,Workers Analytics Engine
都是深度绑定的。你一个项目可能开始的时候,会比较注意,但是开发一段时间后,你是不可能低改动成本迁移到其他 serverless 的。
当你的访问量上来了,被攻击?你 worker 只能靠 cf 的防火墙来防,但是他那个防火墙的策略简单的可以,很难防住被刷,然后你就看到你的账单从几百到 几十 k 了。
重点是,当出现这个问题的时候:
1 ,如果通过自定义 cf 的 firewall 那些简单的逻辑,你基本要么防不住,要么把普通用户也给关了。。。
2 ,要或者,你当下再想迁移?基本上,也等于需要重写大部分代码了。。。
另外我们当时是 cf 的企业客户(被迫买的),就是为了用他的防火墙规则防止被刷 worker 。。。
blog.cloudflare.com/zh-cn/post-mortem-on-cloudflare-control-plane-and-analytics-outage/
出事的时候,几个组件瘫痪了差不多 2 天吧。。。然后打他那个企业版专属北美电话,也没啥卵用。。。
其实各大云都有故障,损失抛开不说,关键是出问题的时候,基于 worker 和他那些缓存啊,db 开发的方案,不像 go/java ,你基本上迁移不出来了。。。
绑定太深 只适合个人开发者 极小规模初创
是好用,但是代码需要避免 vendor locked-in
小人小玩具玩玩很适合,毕竟免费。但我估计这免费额度和开发体验完全不如花点小钱买个轻量 vps 的。
厂商锁定又有开发限制的东西,碰到问题等得哭吧。
我记得 V2EX 站长就上了 google 类似开发环境的大当,一开始也如 OP 这样吹捧过好一阵,后来就麻了
「如果使用 cf 不考虑大陆,数据中心选择哪里好」楼主这个有结论吗? 翻了你的回复没有找到这篇帖子
谢谢你踩坑。我拔草了
本来还想着把 bot 改造过去呢
为什么可观测性不好做呢?
简单来说,开发/迁移成本高于省下的那点钱。
你现在为了 worker 开发了那么多东西,万一有一天需要迁移到其他服务,你重写代码的这点时间价值立刻就把之前省下的所有开销全部吐出来了。
当然,如果你特别自信你的项目可以永远在 worker 上免费运行无需迁移到其他平台,那确实可以。
但这离你标题里写的「 web 服务部署的一种最佳实践」还有差距。至少企业用户和大流量用户是不会轻易考虑的。
cf 大善人只是对微小型项目而言的,一旦项目成长起来,要么成为 cf 大金主,要么只能切换平台从头来过。
我还是投 docker 这类一票,容器化抹平平台差异。cf 虽然好,那天你要迁出就难受了。
硬件:CPU 5600G + 微星 A520M-A-PRO 平台:PVE 8 正常运行着,大概隔一天就访问不了,路由器中也不见了设备,直接插屏幕访问也卡死。必须强制关机,再开机…
上周接手了个项目,老板说大部分项目都不能工作,本来是以维护的价格来处理接手这一段代码的 没想到坑比我想的还多,这是其中展示通用的一部分,大部分出于保密性就不能透露了 开篇惊喜 …
本人 JAVA 后端,有一些 react 的前端经验。打算开发一个 mac os 的小工具 app ,想了解下目前的跨平台框架对 desktop 的支持咋样? fluter …