@jeesk

看了 https://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 环境...



总而言之，懒得迁移了，摆了。