这是一个创建于 41 天前的主题，其中的信息可能已经有所发展或是发生改变。
以 Cloudflare Worker 为例， 目前完全支持的是 js 和 ts 。
Python 和 Rust 处于 beta 阶段。
什么原因，造成了 Js 在 Serverless 领域的优势？
18 条回复 • 2024-09-29 14:23:35 +08:00
 |
1
Dolov 41 天前 via iPhone
我觉得前端喜欢瞎折腾占一条吧，node 运行时轻量且适合异步 io ？瞎说的，不懂
|
 |
2
qwqquq 41 天前
编排隔离方便，上下文轻量。
|
|
3
qwqquq 41 天前
同样是以 Cloudflare Worker 为例可以看 https://blog.cloudflare.com/cloud-computing-without-containers/
|
 |
4
falcon05 41 天前
可能是因为 javascript 普及率高，特别是在 web 无处不在，既然大家都在用，Serverless 自然也就优先支持。
|
 |
5
BeijingBaby 41 天前
1 、容易上手，会的人多，普及率高，前后端都能写。
2 、非常成熟，社区，特性等。 3 、非常适合事件驱动的异步架构。 能满足这几点的不多。 |
 |
6
GeekGao 41 天前
启动开销小
包大小小 函数式编程支持良好 |
 |
7
musi 41 天前 via iPhone  2
JS 沙盒轻量，容易隔离，不像其他语言得拉个虚拟机才能隔离。
而且 Javascript 其实是由 ECMAScript 定义的规范+宿主环境提供的 API 共同组成的，比其他语言更容易定制化，权限也更容易管控。 得益于 Chrome V8 的发展让脚本语言也能有不错的性能，另外还能用上 Chrome devtools protocol 增加调试功能，光能跑代码不行，你总得有个地方让开发者调试代码吧。Chrome 提供了一套完整的协议和前端界面，服务商只需要实现对应的后端就行了。 从以上几点来说没有任何一个语言能比 js 更适合了 |
|
8
musi 41 天前 via iPhone 2
另外，每家的 serverless 实现不同，虽然看上去都是支持 js ，有些选择直接使用 node (以国内的云厂商为代表)，有些会选择用其他宿主环境定制(以 cloudflare worker 为代表)，他们实际的开发体验、功能支持、资源管控都不是一个层级的，具体的其实要看对 serverless 这个产品所要解决的问题是什么
|
 |
9
veightz 41 天前
楼上的观点大都赞同。
另外有个自己的观点，js 开发者相比于纯粹的后端开发者更容易成为 serverless 用户，他们更加在意如何能够快速容易地部署获得一个 http api. |
 |
10
povsister 41 天前 2
看到 serverless 都觉得唏嘘，云原生火热的那几年到处都吹着上云都吹着容器化，一时间 servicemesh 风头无两。
不乏有人在探索：下一个突破点是什么？是大规模的 SaaS ，还是 FaaS ？然后就出现了 serverless ，甚至还出现了模仿容器的函数沙盒：宣称下一代容器技术，具有秒级部署，秒级启动，秒级更新。吊打现在分钟级的容器调度。 后面的事情大家都知道了，疫情三年全球经济萎缩，降本成了第一要务，再也没人鼓吹 serverless 。 |
 |
11
pollux 41 天前 1
serverless 作为技术手段，降本增效本身是没错的，只是国与国之间互相掐架，互损利益，造成了经济下滑，相当于直接砸了饭碗，那怎么开源节流都不行了。
|
 |
12
crackidz 41 天前
国内的公有云 serverless 基本上都和 Node 生态关联度很高，你看一下文档就能发现他们的设施很多是 Node 提供的服务。但是实际上一些国内厂商也提供了基于 WASI 等的方案，不过不是在公有云平台上，可能很多人看不到。
国外的 serverless 比较五花八门，比如 Lambda / CloudRun 和 Cloudflare Worker 是不同的。Cloudflare Worker 定位就是为前端服务的，所以选择使用 JavaScript 相关技术栈。对于其他的语言支持，Cloudflare Worker 是通过 WASI 实现的，其实对于能够编译 wasm 的语言都可以跑，只是对官方来说，他们提供了 Python 和 Rust 支持，其实你自己包装一下就能跑一个其他语言上去了 |
 |
13
BeautifulSoap 41 天前
@povsister 眼界不太够，放宽下视野，不要把视野局限在国内。国外(甚至日本)这几年 serverless 的应用都非常多了。我在的公司很多新项目技术选型的时候，serverless 基本都是和 aws ecs 一个等级的备选项。最终很多项目都是选的 serverless 。光我自己参与的项目，整个项目完全跑在 apigateway+lambda+dynamodb/aurora 的就好几个了，还都是有较大用户数量的项目
|
|
14
povsister 40 天前 1
@BeautifulSoap
根本不是什么眼界问题，不如说，一方水土一方人。何况日本 IT 啥水平就不用大家讲了吧。 国内大企业都在逃离公有云，那么自建的情况下为什么要自研一套非常吃基建的 serverless ？徒增运维成本，而且可维护性也比传统 CS 模式差。 降本的压力下所有东西全部向效能看齐，serverless 本质上是重前端轻后端快速迭代的路子，如今增长顶峰已去，大厂根本没有投入 serverless 的理由。 而且另一个问题，国内各种 app 都是奔着门户入口去做的，既要又要的要求下，serverless ？压根不会考虑。 |
|
15
BeautifulSoap 40 天前
@povsister 所以你说这么多，不反倒更加证明问腾出？你因为眼界只局限在国内（你 13L 和 14L 回复里也是一直只说国内），我就提醒你一下 serverless 在国外非但没遭到冷遇反倒在国外应用是越来越多的。你解释再多国内为什么遭到冷遇也改变不了你最开始对 serverless 在国外应用有错误认识这个事情啊。。。。
然后“何况日本 IT 啥水平就不用大家讲了吧”， “serverless 本质上是重前端轻后端快速迭代的路子” 有的自己不熟悉的方面我觉得还是别多发表意见比较好，会更加暴露自己的问题 |
|
16
povsister 40 天前 via iPhone
你开心就好。我感叹下 serverless 在国内的水土不服反倒有人来教育起我来了还给我扣一顶眼界小的帽子。
|
 |
18
type 40 天前
VirtualHost 换个概念
|
Select Language