首先说下 durable object 中转的优势
- 可以使用 cf 全球 330 个城市的机房部署你的中转实例,除了中国,用户到中转服务器的延迟不会高于 20ms 。给一组我实测的数据,测了两个位置,在 scaleway 的法国机房,延迟 16ms ,在腾讯云香港机房,延迟 10ms 。
- do 按运行时间计费,不按流量计费,因此假设你将每一条中转信道都分配独立的 do 实例,那么你可以得到一个比较完美的收费模型,基于每条信道的存活时间收费,这对 toC 或者 SaaS 都是可接受的。
- 流量免费,do 通过 worker 的 websocket 对外暴露端点,worker 的流量是不计费的
- 自动水平扩展,do 实例拉起是秒级并且基本不做数量限制的
下面说下实现思路
worker 对外暴露 websocket 连接,worker 内部把 websocket 连接转成 streamable http 和 do 通信
worker 对外暴露 websocket 连接,一个是为了实时性,一个是为了规避 worker 上传请求体 100MB 大小限制
worker 对 do 的连接转成 streamable http 则是为了优化 do 的计费机制,do 对 websocket 的计费是按流入方向每 20 个 packet 折算成一次调用收费,但是如过你用 streamable http ,一个请求就是一个请求。同时让 worker 和 do 实例发起一个 websocket 连接,这是为了保活 do 实例,do 实例在你的请求返回后会自动销毁,所以你需要一个保活的 websocket 连接到 do 。
我已经在一些应用场景测试了这个中转信道
- 端到端加密的即时通信,所有痕迹随着 do 销毁全部消失
- 一对一视频通话,我用的香港节点去创建中转信道,因此我猜测 do 实例是在 cf 的香港机房,延迟在 2-3s