Deep Dive
Shownotes Transcript
好现在我是不是可以来下一个今天的第三套问题了然后评估好了我们就接入今天下一个话题其实本来我们就是这次请宇晨来的一个契机就是我们想聊一下
Halfware 最近开源的 Pingora 这个项目简单来说 Pingora 我理解它就是一个 EngineX 的替代品其实我就是非常好奇首先你们为什么要开发一个这样的然后背后有什么样的故事包括为什么要用 Rust 开发也都可以跟我们聊一下然后雨晨是这个项目的算是创始的工程师是吧主持人可以跟我们分享一下
对然后我的理解是评估了它其实并不是 NZX 的替代品对我看到它的原码我看下来它其实是更多是一个 framework 然后你很多的逻辑包括你的 load balance 然后你的选择逻辑还有你的 slow start 很多逻辑都是需要去
自己写但是他提供了很多的教授间比如说 catch 然后还有 SL 的处理还有挺多其他的包括 H1H2 的处理对他更多的像是一个就是说你可以基于这个苹果来搭起一个没错我的理解是这样没错首先就是个苹果的这个东西确实它是一个 framework
它是要程序员在上面实现去 customize 你的服务器是 customize proxy 为什么这么设计呢这个实际上是根据我们在 Cloudflare 的多年的经验
就是说是 Internet 包括这个 Lua 这一套就是在你的业务逻辑写多了你就会发现你实际上是在上面写 code 而不是写 configuration 是的没错对的然后所以觉得既然是写 code 那就大家就直接去写 code 好了就是我们开放尽量多的 API 我们开放就是让大家想怎么变想怎么改你这个 proxy
就可以怎么改然后另一方面的考量是苹果的这个 framework 我们想做一个叫 unopinionated 就是一个比较中立的一个服务器就是并不想替他的用户去猜或想用户可能需要这么用我们就把这些所有的选项这些所有的这个 decision 留给用户这是一个非常 high level 的一个东西我下面讲一下我们为什么要做这件事情好吧
咱们先说一下 Proxy,Index 这些事情刚才像我们提到的 Proxy 在我们的代理在 Cloudflare 用的非常广泛 Cloudflare 你可以想象成 Cloudflare 的那些 workers 计算不谈其他方面 Cloudflare 本质上就是一个代理对吧它把客户端的流量代理到真正的服务器上去
然后在代理中比如说我们做了一些比如说 WARF 去看一看你这个 request 请求的头有没有什么可疑的东西 reject 然后如果要做 caching 的话也是在上面去做然后用户可能比如说你要去验证用户的身份你要去看读一下 cookie 什么的对吧实际上代理的本质就是我们要看一下请求看一下 respond 然后把它们修改一下或者是把它们给拒绝掉或者怎样对吧
然后这个就中了一个水坝对然后这个在其他的一些地方比如说 Kubernetes 上也有应用比如说你在你的这个里面开了好多的 instance 你要做负载均衡实际上你要从外面进你的 data center 实际上是需要一个 load balancer 在前面去说我要
随机的或者是怎样的 hashing 的去选一个 backend 对吧实际上 injax 最开始是一个 web server 是一个 serve 这个是 show html file 的你有好多 file 在 disk 上然后你去看它但是后来大家 injax 用的最多的实际上是作为一个 proxy 一个代理对 是的 是的对吧
然后呢为什么 Index 这么火是因为它是个代理这个代理呢它本身有个什么问题因为他们是一个 webserver 变成的然后呢 Index 本身有好多 config language
就是你可以在里面加一个头呀就是改一个头或者怎样的但是比如说我们刚才举例子 Waf 作为防护的你可能要看一下比如说如果这个 header1 有 5 个字符 header2 有 20 个字符 header3 有这个 string 那么这是一个非常可疑的情形要不他给 block 掉
这些复杂的逻辑在 Intel X 的 config 里是很难写的写出来非常 dirty 这种就是后来要写 Lua 最开始最早期的 Nginx 配置能写一部分但是非常 dirty 因为你要看 Intel X 的源码实际上它的 config 并不是一个 programming language 它只是一些 key value 然后它用 c 去 parse 去
对最古早的一版服务发现中心他们的一个实现就是说然后有 register center 对吧然后我服务注册上去之后然后我基金上跑了一个 demo 然后隔一段时间把服务拉下来拼成一个数十 K 行的一个超大的 nginx config 然后 reload 相当的对的 index 本身实际上就是它的 config 或者它的 programability 是非常小的
然后这就是,对,Cxtension 也非常麻烦,对,而且你要去写,你去写 C 其实有好多好多很难的,对吧?然后所以这是为什么,对的,大家都,现在大家用 IntelX 实际上都不是只是 IntelX,都是 Lua 或者我们叫 OpenResty,OpenResty,对的,OpenResty 这个东西的历史好像是大家都知道春歌是不是?
张一春对 知道从阿里出去然后从阿里穿上 OpenResty 也在 Cloudflare 做了很久没错我跟春哥有幸有大约半年时间是时同事吧
就是这一套东西的思路是我们想编程但又不想写 C 怎么办呢我们把 Lua 这个语言 embed 进 IndianX C 的里面嵌了一个 Lua 的 VM 嵌了一个 LuaJIT 的 runtime 进去它 Lua 的这些 code 就是 naturally 就是 hooking toIndianX 的我们叫 request flow 就是 IndianX 有些扩展的这些接口
然后在收到一个请求头的时候我要 call 一个 callback 然后我收到了一些请求的一些 body 的时候我要 call 另一个 callback 比如说这才有好多这样的 callback 然后 openresid 的工作原理就是挂在这些 callback 上一旦 callback 被 call 了我执行一些 lua code 这些 lua code 里面就是 C 里面的一个请求的一个结构也就是 expose 给 lua
然后 Lua 可以去读它可以去改它你可以写 E-files 可以写循环然后非常牛的是你可以在里面再去做 TCP 就是 Lua 可以 send 一个 TCP request 去 somewhere 然后再读是没错对的然后就是非常容易的就像写你的 logic 去实现有好多用 Lua 实现的 WARF 用 Lua 实现的好多好多 feature 都在上面写
这个也是 Cloudflare 的技术战是基本上是过去好长时间也是 Cloudflare 也是在上面这个我特别好奇就是基于把 Lua 嵌进 EngineX 的这套想法是就是说春哥在 Cloudflare 工作的时候产生了吗还是说他当时并没有这么写而出去他做 OpenResty 然后你们发现这个可以然后你们也这么做是怎么样一个历史
好像是我不确定去问春哥我可以一会发微信问问他
好像是他之前在阿里就有这个想法然后呢在 Cloudflare 里他是把这一套完善的更好了我的了解是他好像在阿里就做了一套对的然后就是对路啊然后现在可能知道然后那个 TNG 现在还在用呢还在用 G2 那套 TNG 然后他出去之后就做什么开了买了 OpenVST 现在 G2 的 TNG 好像也和那个 OpenVST 也合并了
对然后 index 写 Lua 的确是一大创新但是 Lua 写写其实也不轻松这是我们最大的感受对这个时候咱们可以稍微说一下 Lua 这个 Lua 这门语言是一门非常有意思的语言是吧 index 从一开始对吧这是最让人吐槽的 index 从一开始
不过 Lua 这个东西好在它这个语言非常小它这个非常容易的嵌入其他的东西里面比如说我们用的这个 NewVim 是吧它里面就是用 Lua 做 script 或者是再往远点说魔兽世界好像那些脚本都是 Lua 写的对 是的没错然后所以呢之前 Clafford 招人好多招 Lua 招到的好多都是做游戏的因为
然后刚才说到把 Lua 嵌进去这是一个非常大的创新我们可以写 program 了可以在上面做好多复杂的 logicC 也能做但是没有 Lua 那么方便然后就在上面我们做了一套很复杂的系统而且有一部分 C 没法做比如说你要去做热源性之类的
对然后就是 C 的你的更新和其他发布都是被很大的问题没错没错这是我不想说的两点之一就是第一点是 Lua 这门语言可能感觉就是有点太简单了
我们这个业务逻辑一复杂了就很难有时候这个函数是传三个参数还是四个对的没错他接收四个我传三个他也 OK 他跑出来不对是吧然后就一直在反复去查比如说这个返回值是空还是一个布林还是一个字符串实际上对我很讨厌他的 tables 的设计对的就是这门语言就是很难就是你写出一些特别特别复杂的 business logic 特别复杂的 logic
然后还有一个就是性能上比如说 Loyal 好像它的你要先写一个 struct 实际上它是一个 table 然后它这个 table 还是一个 hashtable 比如说你要写一个 a.b 实际上它这个点是一个 hashtable lookup 是在 wrong time 要去查的所以这个东西就是写复杂的逻辑很快你的性能上就会消耗好多我们可以去在生产上看 flame graph
就是路外里面百分之可能七八十的草稻都是在 String 在 Create new string 然后 Delete string 这种感觉就是因为他们的表达能力非常有限实际上是只要不是数字的东西就是 String
然后它还没有一个 static type 这样的东西所以就是业务逻辑一旦复杂了就很难写这是第一点第二点就是像刚才说的就是不是 Lua 或者是 OpenREST 的这些 API 不是能解决所有 Index 的问题的最大的一点比如说我们想就是 IndexIndex 支持 HTTP1 跟 HTTP2 从下游行行来但是它不支持 HTTP2 到上游去
有好几个原因一个是它社区不活跃我们之前有一个工程师给他们提交了一个 pull request 说你看你加上这个就有 HTTP2 了然后他们说我们不想要然后这种类似的东西我们自己去改也很难因为有好多 C 上的东西然后经常是有一些 feature 需要改 C 的改了一些然后上线就 core dump 就 sec fault 然后要查要好难就是改一行
release rollback 这样的有好多好多的这种 developer 的 velocity 或者开发速度很受影响尤其是到了 Index 本身的一些东西比如说它的一些 memory 的一些 buffer 实际上这些这个就涉及到我们想说的 memory safety 就是感觉
我们最经常疑惑就是谁把我的 buffer 给 free 了然后这个 buffer 是不是已经 free 了我能不能用有这种问题就是很难我们去把这个东西想清楚一方面原因就是 Index 的作者不写注释然后他这个逻辑还是就是虽然很巧妙但是你想完全去理解它还是挺难的
对而且它纯一步的一个东西就会导致说它的同一个 buffer 的不同那个那个 lifetime 然后就是整个套我还觉得你不知道从哪一点去 cook 进去的时候这个 memory 它你是不是应该要去加就是说是屏障然后去加一些额外的处理没错没错没错非常麻烦没错想
想象一下另外一个难点就是它是在 C 里面写的 asyncIO 是的没错我们可以想象一下 asyncIO 是说比如说我要读一个 socket 这个 socket 不 ready 就 return 一 again 对吧你要等它好了再读一遍然后这个就导致你在 C 里写函数什么样呢我一个函数叫 read header 我做了一些工作 allocate 了一些 memory 准备开始读了他说你没有好怎么办我这个函数得 return
然后 return 去 eepoo 过一会再读一遍如果这个函数短还好这个函数长我可能前面已经做了好多事情了我已经 allocate 了好多 memory 我已经做了好多 computer 我已经 pars 了好多东西了你让我再 return 然后我再 call 一遍我怎么办呢我只能在里面去写状态就是 if 我上次读到这了下次我 go to 这行继续读
对它还是一个很复杂的一个召开器对的然后它可能在不同的位置因为它要做 callback 它在整个不同的时候去写我的 callback 在这个函数里是它下函数里是这个然后你 follow 代码你是不知道它跑到哪的
你只能去猜 没错所以说我记得像 OpenHS 地区就还要包括有很多协助案的就是说 NGK 上做操作的人他们被逼的没办法就只能大范围的用就 global memory 然后这样一下来然后整个内存管理又很炸有一种史上雕花的感觉这是当时我们当时做网关的时候的感觉
就是 inertx 你要不去改它代码你看它自己做的东西其实是感觉这个东西好牛呀但是你要一旦去改它的话就感觉哎呀啊 exactly 对啊
对我之前也就做完出来的但是我们搞的时候就非常痛苦就我们体系大然后 Lua 写起来没法维护然后没法维护然后你要去做一些 Seed extension 的时候然后写起来可能就写的质量还不如写 Lua 然后你要去扩展有很少的选择然后即便到现在好像也没有很多更好的选择像 NVR 之类的其他又是一堆坑对
没错然后还有另外一个坑我们遇到的就是在写这些 LUARQ 就是我们的公司在部署 ARM 服务器的时候
然后发现 Logit 在 ARM 上跑不好因为它有好多它做这的时候好像是 make 了好多 assumption 就是我们的 memory 是 x86 的什么样的然后呢这些东西到了 ARM 上就不 valid 了然后就导致这个东西我们花了好久的时间然后呢包括也跟这个 Logit 的作者 Mac Paul 跟他去 communicate 了好多然后最终现在好像在 ARM 上可以跑了不过这个东西花了好多时间
是的 我记得当时 APS6 他们在做基于 OpenRisk 的一个开源厂商他们在做 哪个厂商的话的时候就遇到了然后如果在 T 上面就有一些就是说是 spective 之后的 code 它是有问题的然后对
对刚才说到了这几点然后实际上总结一下就是说是在 index 的 c 开发上很难然后在 lua 你一旦的 code 写到一定程度了就也很难维护
第三点就是我们在公司的博客上之前提到的,就是 Intel X 的 Architecture,有一些跟我们的 Intel X,它是一个叫 Worker Model,就是它有好多进程,这些进程是不相干的,然后它的好处是每个进程里面只有一个线程,也就是他们进程里不管读什么 Memory,也不用加锁,也不用考虑什么问题,非常简单,而且一个进程 crash 了,再几个,
没问题然后这个东西特别容易 scale 然后呢对他做的本身的事情来说还是挺好的但是呢就是在我们这个 model 里呢我们公司发过好几篇博客在讲这个进程的问题首先就是有一个问题呢就是一个进程一旦跑得比较慢就是每个进程可能会有好多 connection 好多 request 比如说某一个 request 我们要经过一个 machine learning 的一个 model 我们要去看它是不是 bot
可能它就是比较 CPU intensive 然后这个时候 Machine Learning 的 code 实际上是占了整个的 CPU 然后就导致其他的 request 如果也在了 Worker 进程上的话就要等
然后这个问题是什么呢就是我们有好多 request 可能是不需要或者是非常快的但有一些慢然后就导致有一些 request 的延迟比较高可能是这 50 个 request 绑定在同一个 worker 里面了某一个 request 做了一些慢的事情其他的 request 就都要慢
然后呢不仅是 request 它是一个 connection 就是说是经常为了性能嘛我们有一些 long lived connection 然后呢这个 connection 上把很多 request 然后有的时候就导致就是某些这个 worker 得到的 connection 比其他 worker 多然后呢就导致它是不 balanced 然后呢就也有一些 CPU 上的影响
是的之前我都能遇到过这样的问题就是因为我虚拟性它有一些措施来比如说它是会尽可能的防止这种 Balancing 的情况出现但是在实际上比如说像在用 ReducePod 或者说其他一些更好的改进之前
NX worker 它反而出現熱點就是說某一個 worker 非常 hot 然後 CPU 你會看到它 CPU 流利非常高然後其他 worker 卻是又在普通 over 的時候接近餓死的情況他就不上 CPU 來 balance 的嗎不是是不是用比如說 Rung robbing 之類的這種比較簡單的方法
他在 connection 的时候是 run robin 的但是如果你这个 request 你摊到了一个核让这个核上有一个其他的一个非常 heavy 的 request
对 你记得吗他只能就说是因为你的东西就是你有一些出的快比如说你投入到入的地方然后你有些出的就请求返回的快有些返回的慢然后比如说你有些返回的很慢的请求全部集中在某一个 worker 上因为他可能说是某一次的服务出现了问题就正法导致说这个 worker 出现了问题然后那么就有返回出现了
就像你去超市排队排错队了,你前面那个人忘带钱了,然后你就在后面一直等。然后另外一个类似的问题就是我们 team 非常关心的,就是一个连接复用的问题。就是说 Index 在后端它是有现成池,比如说你要连接一个 server,如果上次连过来下次可以复用。
但是这个现成池只是限于这个 Worker 的如果比如说我们一个服务器上假设有 20 个 Worker 就是第一个进程来了找到了 Worker1 然后脸上的后端然后在 Worker1 上保存了一个 Long-Live Connection 然后 Request2 来了他们要去同一个地点它有 20 个 Worker 它有 1/20 的概率
到同一个 worker 上找到这个现成池然后最后就导致我们可能要跟客户的服务器去开好多好多的 connection 然后这些都是不太必要的
是的理解对我们之前有遇到过这种问题对我们我们的服务器上是有一个限制就是你可以限制就是说最多你从一个就是前端类似于 walker 这种概念吧发连多少个请求到后端就避免出现这种请求爆炸的情况比如说 1000 乘 1000 你就直接炸了对
所以在某一段时间我们的部署辅助器就是处在一个很尴尬的阶段就是我们的 Worker 多了我们进程多了我们的客户受不了进程少了它又 CPU 又不够跑所以就是在这样一个非常尴尬的时候然后这种问题我们觉得实际上是也不是因为 C 也不是因为 Lua 就是因为 Index 的 WorkerProcess 进程的 Model
我们就想如果我们做一个以现成为调度方式的这样首先大家所有的现成都可以享用同一个分享同一个叫连接池就是第一个现成用了放回去第二个现成可以直接用然后在现成里面如果做好了调度我们叫 work stealing 如果一个现成跑得很忙那么剩下的请求就由其他现成来做了
这样的话就解决了这样一个问题实际上这个是我们比较主要的一个在架构上的一个想法这个想法不是我们在写苹果的时候才想的而是这个想法已经有好多年了基本上在 17 年 18 年大家都感到了 IngeX 这个 model 感觉有点难然后大家都陆陆续续发现了这些问题然后陆陆续续觉得如果我们有下一个 project 下一个 framework 的话一定要解决这些问题
然后呢,直到了大约是在 19 年年末 19 年下半年冬天左右吧我们决定开始用 Rust 来写这个东西然后这就是苹果儿的这个开始
这个我可以详细问一下比如说你相当于你列了很多这种就是 NGNX 不好的地方那相当于你们可能内部有一些讨论就说我们有很多这种 issue 有很长时间然后解决不了所以大家就集体讨论一下说 OK 我们就重新写一个还是中间有什么别的
是怎么样一个决定要重新写一个的过程因为这个显然是一个很重大的决定对吧实际上就像我们刚才说的我们好多的这个 technical 的决定是 bottom up 是从工程师来决定的就是在这个之前各个 team 的各个组的工程师都写过好多我们内部的博客我这个要提一点就是你们看到了 Cloudflare 的这个公开的博客非常精彩我们内部的博客实际上是有更多更好玩的东西
然后过去这几年大家都会写一些遇到的问题或者是一些思路什么的然后当时大家基本有一个共识可能我们要重新写但是怎么写多少都不确定或者是我们要是从 index 迁到了另外一个第三方的东西比如说 unvoid 这也是一个可能性对吧
我也吃一坑当时我们 team 我的 manager 我的老板我觉得非常感谢他他跟我们讲说我们来自己写吧我们来试试吧因为我们已经说要自己写或者是要试图 move away from index 已经好长时间了他说择日不如撞日我们就开始吧然后呢我跟我老板说你这个想法非常 ambitious 不过我们来试试看
首先第一个想法是用另外一个第三方的还是自己写这个当时就想是安慰还是怎样就是当时一个思路就是不想从一个坑跳到另一个坑虽然不一定它是一个坑但是第三方的东西用着用着很可能就会变成一个因为我们在 Cosplay 有自己非常 specific 的用途
然后如果要再用另外一个第三方的一个 solution 实际上是并没有好多少我觉得因为好多时候我们在用 Index 的时候就是想自己改但又怕改太多就是 upstream 跟上游的差太多他们升级的时候不好升级对吧这是一个 concern 就是以后不想考虑这些事情了就是
还是我们自己的东西盖起来恭喜回头来看你们真的没有掉进去 10 万信真的是超大的然后下面就是说语言嘛
首先就是我好多年前大家都说用勾浪线一个吧反正那个东西也挺好用的但是觉得好像可能性能上跟 C 可能是有一些想法然后呢当时 19 年正好那个时候还是 20 年就是 Rust 的 Async 的 Stabilize 就是你可以用 Async
然后觉得这个语言还是挺好的因为首先说明我在这个 project 之前也没有用过 rust 你就觉得这门语言好像是听起来就是跟我们想象的好像是挺好的如果不是这个我们用 C++自己写一个东西其实也行但是后来发现它有这个 async 了有这个 memory safety 感觉就是我们想要的它都有
然后当时就想让我们就学一下我老板当时是这样的就是因为当时也是一个非常叫 experimental 就是非常冒风险的也不可能全组大家开始就写了对吧然后别的都不干了这个是不可能的对吧当时就是让我一个人说你自己去试试看吧
然后我就说那我就我先学一下 Rust 吧好吧然后 19 年当时是 9 月份《非诚信机》这么清明是 19 年 9 月 9 月十几号公司上市然后呢我拿着那个 Rust 很厚的一本书从三藩坐飞机到纽约我们去参观公司上市就拿着那本书在飞机上看看着看着就睡着了然后那个飞机上大约有好多是我们公司的人看然后拍了一张照片说你看他学虚言学睡着了
然后就是你们公司在之前是完全没有用 RAS 是吧你这第一个这是个好问题当时不知道好像是很少至少没有大部分要么是第一个要么就是很少这个具体的不确定了是第一个吗是第一个不确定但是确实那个时候还是挺少的 OK
然后基本上在 19 年就是从大约 9 月份到 12 月份就是自己试图去用 REST 用这个语言去写一下就是最基本的一些东西就是模仿着 Intel X 去写一些比如说是最基础的 TCP 处理什么的
然后基本上 19 年 12 月份的时候就是能写出了肯定不是第一版就是写出了一个就是 Hello World 跑通了就是我有一个 async 的一个 server 自己写的一些 passer 什么的然后就可以 return Hello World 了然后大家都知道了 20 年一开始就爆发新冠了然后反而对于这个 project 还是一个好事就是大家都闷在家里
就一直在写这个东西当时的一个想法就是这个东西我们可以模仿着 OpenREST 的 API 因为我一直觉得它这个 API 还是挺好的我得到了一个请求我怎么处理这个 request 然后如果在这个请求返回的时候我怎么处理这个 response 它有 OpenREST 可能有七八个还是十几个这样的一个叫 callback 我们就想
用类似的东西因为我们觉得这个 interface 设计还是挺舒服的就是用户主要去想我在什么时候要做什么事情就可以了而不用真正去发数据去收数据所以就是按照跟他类似的方式设计这个 API 然后大约在 21 年 19 年 20 年在 20 年的下旬的时候就是最基础的第一版就已经做好了
就是有最基本的功能了但是当时感觉就是很实验性的一个东西接下来怎么办呢又是我老板我老板说咱们上生产试试看我说老板你真敢好我们试试看吧
然后在 20 年的时候因为 Cloudflare 有好多 Free traffic 好多 Cloudflare 的新的一些 feature 一些 code 都是现在 Free 的免费用户上做实验的好多新的功能可能是免费用户先用到然后就开始实验这个就给我们好多反馈因为大家知道互联网上的 HTTP 的 traffic 它完全不是按照你 RFC 的标准来做的有好多千奇百怪的 traffic
然后通过这些 traffic 我们再不断的完善我们 code 有各种各样的 corner case 比如说什么有用户想在 header 里加一个 emoji 的什么然后什么就这种奇奇怪怪的东西然后我们就要处理还有好多比如说用户比如说我们连 server 它不是有那个叫
ALPN 就是问这个 server 你支持 HT1 还是支持 HT2 好多 server 说我们支持 H2 连上就出错了然后好多这种奇怪的东西然后基本上是 21 年到 22 年之间我们不断的在发现这样的问题然后不断的让我们更多的用户从免费的到刷新云卡的最后到 Enterprise 签 contract
然后基本是到 22 年中的时候就是把所有的我们的流量从 injects 迁到了新的 pingola based framework 上去了
你指的所有的流量是就是所有服务的所有流量还是 CDN 或者过一块就是经过 CDN 的所有流量都开始都是通过苹果的这个 service 去 exit 了因为我们内部还有好多其他的 index 的服务就是很难一下都换掉理解理解
对肯定是先换新的或者你们都控制的对先换我们 team 最控制就是 Cloudflare 的最后一条就是我们内部有好多服务他请求要从一个服务到另一个服务然后最终离开 Cloudflare 的最后一个服务我们先把这个服务给换掉了对我在公司也做一些这种 migration 相关的东西然后我想了解一下你们是怎么去评估这种切换的效果比如说你们会跑一些实验然后发现评估
去 server 里请求它的 CPU 占用更低 web 占用更低然后说 OK 这个挺好然后错误率可能是一样然后我们就说切换这个大概是怎么做的这个其实就是像你说这样的很难在现实中做因为首先说这个正确性
就是这个正确性实际上是你要跑到互联网的流量才知道就是有哪些客户就是发哪些奇怪的请求你是能 handle 还是不能 handle 然后就是用真实的流量做一些 experiment 这种没错就是用真实的流量然后去看这个错误率然后呢也是相互比较实际上就没有做的像你说的那么科学就是我们去同样的流量去经过 A 还是经过 B 因为这个有好多 customer 可能他们有好多这种 API 的 traffic 这种东西
就是很难去 replay 很难去重放对的所以呢也是就是看这样的东西然后呢一个大客户说他们的连接就是我们这是正在做这个 migration 正在做切换当时还没有轮到大企业客户呢这时候有一个大客户来提了一个 ticket 一个 ticket 说他们的连接到他们的 server 太多了然后呢我们想这样的我们当时说那部分人说要不要试试这个新服务呀
然后他们说好呀然后试了之后感觉效果特别好就是他们的连接的数量降了好多然后连接的付用率从好像是 60%多到了 98%好像是这样然后就感觉这个东西还是挺好的对就是因为你直接说 VODL 的改进就像你没有这样一个 worker 的效果大家都是付用一个连接池的一个没错没错
Dev Velocity 开发速度方面因为你之前也说是一个痛点有没有什么你体会到的改进体会到改进首先刚才讲的 IntraX 不支持 HTTP2 回源我们在开发苹果的时候就顺手把它加进去了因为好像看起来没有很难的样子然后苹果一上线就支持 HTTP2 回源了
然后就感觉这个还是挺舒服的后面由于我们的苹果的 API 接口是跟 OpenREST 的大同小异在同样的 request 的 face 要靠然后这样把之前从 Lua 里面的业务逻辑迁过来还是挺容易的我们的工程师只要同样的 Lua code 你用 REST 写一遍就 OK 了
我们这个在中间又加了好多好多 feature 然后感觉都是挺容易的我们也没有遇到 crash 或者说很少这是一个非常欣慰的
我之前在我们的 blog 里讲了一个故事我们跑了 Pinball 了是二年左右我们跑得很稳定然后我们用突然某一天开始有一些服务器开始 crash 开始 core dump 开始 seg fault 然后我们去看 backtrace 让 backtrace 一点都不 make sense 也不是我们的 codecore dump 在了好多奇怪的地方
如果这是 innex 我们就开始怀疑人生怀疑自己是哪改错了的由于这是一个新的很稳定的系统我们就跟我们 Kernel 的 team 回来我们的 ops team 说我们这个系统没毛病是你的机器坏掉了然后去看然后果然是找到了一个在 Linux Kernel 里的一个 bug 我们正好我们另一个 team 在 enable 这个 feature 然后一看到这些机器 Enable feature 了你的服务器 crash 了那就是他的错
就是不用去处理这样的问题不用去担心这样的问题了我们就可以去开发也好去加新 feature 也好改动也好实际上感觉还是挺好的对对对
所以就是说可以理解为 Calfair CDN 的服务已经全部是跑在 PinkGurus 上面我们还有一些服务还是在 IndiaX 我们还在做结婚的过程中对可能确实比较没有那么快然后其他的服务也会逐渐迁如果能迁的话对 PinkGurus 我自己之前看的时候我就感觉设计的蛮好的我自己有一些小的东西都准备迁移到 PinkGurus 上面去
我不想问现在跟之前的 Lua 的开发速度上哪一个会快一点个人觉得还是这个上更快一些有几个原因一个是刚才说的就是 Lua 的这个东西一旦复杂了这个函数传几个参数你都要去来回反复 check
就是在这个里面一些 test tool 也好呀这个就是 rust 自带的一些这个 check 也好实际上是帮助我们好多而且呢感觉就是即使组里来了一个新人只要他这个 code 只要能 compile 就差不多是对的
就是之前在 Lua 里面有好多这种坑或者说好多这种就是你要去注意的东西比如说假如说刚才说的 A.B 因为在 Lua 里面是一个 hashtag lookup 所以在 hotpass 我们会告诉他们你要把这个 local variable 就是 C 等于 A.B 把它存起来然后下次用采快有这种好多这样的东西就好多心智负担在这上面然后现在这些东西就都没有了
有打算支持 PIO3 吗这个还没有想过我看了一下结构其实可以支持但是我觉得意义不大
用一些拍子其实这些中间件多少可能比较难管理其实可以自己扩展一下因为中国代表我大概看一下他扩展点其实做的挺好的而且他 billing 就 take care 很多就 corner 的东西比如说很多人会忽略的 grisful 就 shutdown 然后就 grisful upgrade 这种东西你其实自己用 pio3 去写一部分他 load balance 而没些逻辑我觉得其实也挺快的说不定会有人
就是对再二次开发一下我其实已经尝试过了但是我反正我尝试过了我感觉还行嗯这就是我们有一个想法可能不是我们 team 或者苹果的 team 在实现就是我们打算就是在里面欠一个 wasm 的 run time 我是了对吧 I have tried 哈哈哈
对 我自己做你们出来的第二周我就做了一个 Phototype 了 挺好玩的但是我对 WASM WSI 我觉得还不如直接在里面印写模子这些是给那些比如说想在用 JavaScript 想用 Python 想用什么的去取语言不乱对其实我试用了一下其实你们的困难点是扩散还是比较容易的 WASM 和 Python 我都试了
就这些赶紧招了呀赶紧招了进公司了
没有因为我之前给 OpenDAO 在做的一个项目就是说我给他提升到各种的 WASM 客户都在里面然后那一趟当时 PinkWire 出来之后我就说我能不能把 WASM Time 给切进来因为像 Avoid 他们就是基于 WASM Time 和 V8 然后 V8 我没做我就做了 WASM Time 然后做进来我觉得写的还好但是 WASM 他们的东西最后写下来说实话你的性能就还是就 overhead 就很多的
很隐私的跟路外一样就比如说你 WASM 你需要去它是线性内存布局然后你没法直接去然后你的 host function 和你的 WASM function 之间来回到一个 memory 的一个交互那也是非常恶心的一个事情是 可以笑笑了
就回到 Pingora 开发的故事上其实我今天想问一个问题就是你们在之前是不是 22 年的中旬已经相比 8.6 千到 Pingora 从 Nginx 迁到 Pingora 上了到这步 Pingora 还没有开源对吧还是一个内部框架对还是内部框架那最后开源故事是怎么样
从我们开发初期就觉得这个 framework 可以开源然后另外一方面就觉得这个东西如果想要做一个好的一个 framework 即使不开源在内部也要做到一个有一个非常干净的 API 层保证你的业务逻辑跟你的底层的处理相互不混合
实际上在 20 年的时候我们已经基本做到了就是我们的 pingora 的 pub 就是 neutral 的 library 在一个库里然后我们的 business logic 在另一个库里那个时候我们可以直接把 pingora 的 code share 给大家虽然 API 可能不是现在好用但是里面并不会包含任何我们的业务逻辑就是那个时候说有可能不一定以后要开源但是这么写
这种 API 实际上也让内部人好好理解如果我们以后内部再加另外一个 service 也用它来写的话实际上这个扩展就很容易好的我意思说实际上说是你是就相当于说把业务逻辑和 info 给 JEO 拍了没错这个就是那个二年那个时候就已经是这么做的了对思路非常好就跟他们做应用层的很多框架一样
比如说像阿里他们 JavaScript Node.js 统一孵化出一个 1.js 也是把基础的东西和他们的业务逻辑给解维开对然后我们实际上一直在做这样的一个实验比如说我们有个业务逻辑需要改内核就是我们苹果的 library 如果存在这样的情况说明我们的 API 做的不够好我们就要想我们要怎么样提供一个 neutral 的 API 来实现这个东西对
是的没错然后呢从 20 年到今年年初开源吧实际上这个内核并没有做太大的改动可能做了一些 refactor 什么的然后呢实际上也就是卓利本来是要还有这样的一个故事就是我们 20 年发了 block post 之后我们有
有一些我们的客户也想用这个东西我们内部商量一下觉得这个东西还没有做稳定还没有做成熟当时给他们可能不是对用户很负责任我们说你别急等我们来开源大约是到了 23 年下旬的时候我们当时就是要说可能是 23 年 9 月份开源可能这个情况
然后这个时候又发生了另外一件事情大家可能都知道 Let's Encrypt 就是免费给大家发证书的这个地方然后它的背后的基金会叫 ISRGInternet Security Research Group 它是一个就是 non-profit 的一个组织然后它是大力的推动一些 security 的东西
他跟我们来联系他们说我们想写一个这个 Memory saved proxy 你们有没有兴趣跟我们一起写然后我说我们已经写了一个了你们要不要直接来用呀
他说好呀我们就一起 plan 这件事情然后就把本来是 23 年可能 9 月要开源就是到了 24 年 2 月份然后他们之间招了一个 full time 的 engineer 在苹果网上做二次开发做的是什么呢主要是做的一个 config
因为要用苹果了你要写 Rust 但不是所有人都想写或者是都可以写 Rust 对吧更多人还希望我写一个简单的 config file 就可以做好多事情然后这件事情就是由 srg 来去担当的他们在苹果上开发了一个正在开发一个 proxy 叫 river 它是一个 binary
这个 binary 最终会有这些 config language 然后最终这些 wasm 的这些支持可能由他们来做然后这个就是拼入了开源前这半年的故事这个真的挺有意思我当时其实最开始我看到你播了的时候我其实也挺期待的因为说实话当时我们也在学新游玩的东西社会也就被逼无赖最后跑出了我也的坑然后用了我遇死的遇死海里米也找那个
对这也是另外一个就是为什么开源的原因就是由于 Rust 这种 language 它本身它有这个 async support 实际上开发起来没有想象那么难然后觉得就是这个东西好像是我也可以做别人也可以做的样子一方面觉得如果这个东西我们不开源了说不定再过一年别人做出来了
别人用然后呢那实际上就去 support 他们很难因为另外一点是什么呢就是我们有好多 enterprise customer 他们现在用比如说 inx 我们要去支持他们的一些东西如果有人又做出了另外一个东西然后他有自己的一些 corner case 需要来支持他还不如用我们的呢是吧然后呢这也是凯远的另外一个原因是是
我突然想到一个问题就是不是前段时间 EngineX 好像有一个切换许可证的事件吗不是切换许可证它是这样的前段时间也就是开源我们开源前大约几周时间好像是这样 EngineX 历史是它是有一个独立开发者开发的然后后来它成立了一个 EngineX 这个公司再过了几年好像是 17 年 18 年然后它被美国的一个公司 F5 给买对 F5 申购了对的
他的好多核心开发者走了但是最核心的一两个人还在但是他们可能跟 F5 的关系并没有特别好然后那个人在 14 年 1 月份还是什么时候发了一个 announcement 就是说我打算 fork 了 injects 叫 free injects
因为我跟 F5 的对于什么一些 security 的一些管理并不一致 24 年但是我们仔细看就是 Ingex 之前走出去的那一帮开发者已经 fork 了一个 Ingex 现在有三个 Ingex 在那边
当时看到苹果二开源然后联想到了 EngineX 我们叫分裂或者叫反正这个事件就感觉你们开源时机非常好然后就是有一种抓到得量的感觉说他们这个有些问题然后你们还用苹果二实际上是我们这个开源是其实头一年就定下来的实际上也不知道它事情会发生
而且我们也不知道我们这个开源日期的两天前白宫说你们不要用 CC 东西了你们要用 Rust 对
不是说拜登说然后要把 Rust 列为合法语言吗其实都可以吧这个也是挺有意思这个确实并没有预谋这个我们的日期是早就选好的然后传下去然后迪在国那个 Cloudfare 在国会山当时各种什么公众号的就是搞这大新闻什么什么白宫宣布虽然家不合法之类的
搞这种标题的对然后但是说实话 Engines 它这几年的发展说实话我觉得就粉业能进他们自己的 Engines plusEngines plus 的 JS engine 其实也推的不是太顺利的他们基于 QuickJS 去做的然后也是据我所知大家的反馈也是很难用然后基于 Engines 系的创业公司然后现在好像也就购空一家否则还不错的
其实我挺好奇后续基于苹果会不会在我玩这一层然后因为我玩这层就不管你是东西向反正是南北向的流量都挺重要的我很好奇就不知道会不会基于苹果再孵化一些创业公司出来因为像现在 Envoy 现在有不少然后 Engines 虽然控制 API 是几年了快点了然后控制读苗苗了但是好歹也还是有个大苗苗在这对吧
我觉得很好奇会不会基于 Pinkora 孵化一些出来我觉得不会孵化出新公司我觉得可能是有一些现有的公司可能去 embrace 这个东西
因为我们这个东西是苹果这个没有带来什么就是产品上的不同它还是一个 Proxy 它还是个代理它还做这些事情对吧就是但是呢尤其是白宫也说了你们不可以用 C 了是吧就是肯定会有一些公司会去觉得我们要用一些 MemorySafe 的语言或者是公司的这个客户可能也觉得我用的产品这个产品是 C 呢还是 MemorySafe 的东西呢
但可能客户会有一些考虑嗯
所以未来 Pingora 有什么计划肯定是在公司内部继续去推广然后对在公司内部肯定是继续用然后希望因为我们的设计师就是 on opinion 也是把我们的能用的 API 也好这些接口开放给用户让用户在上面去做或者是三方做二次的开发比如说可能有人觉得我们的 load balancing 算法非常 naive
你可以写一个更好的不用给我们提交普罗快因为我们的 API 是 public 你可以直接靠那个东西就好了或者谁在我们上面写一个 WARF 在上面写一个什么东西实际上都是可以去做的包括 config 包括可能有用户想要用 JSON 想要什么去控制他的东西可以你们去自己写好了挺好
我听起来感觉 Pingora 的就是说从一开始发展到后来开源这个故事就挺童话的就是一个就是 engineer 推动然后在公司内部很怕推行然后有很大 impact 最后开源就是很像一个童话故事然后我觉得就很少很少有我去点像对就是一个童话故事
但是又是一个童话故事就是感觉不能实现那一定要还是实现我想说的点就是很少有共产党能有这种体验对真的挺难得的是的然后你已经流下了羡慕的口水和羡慕的眼泪我觉得一个就是在 Cloudflare 一个得天赌后的优势就是我们确实有好多流量就是可以去 battle test 我们这个 framework
就是我们开源出的东西我们有信心这个东西虽然不能说是 bug free 的但是对于绝大多数互联网的流量别人考虑到没有考虑到的我们其实都考虑到了
对,我觉得更重要,同样说,你们有这样一个环境能够从一线的工程师发起一些项目,他们的 idea 能够得到支持,能够得到应用。在某些公司,比如说 Google 是几乎不可能的,因为 Google 是一个很 top-down 的公司,它的所有的目标都是从上层一起定下来,拆解成 OK,然后分析起来,几乎不可能。
以前可能还能有一些这种底层可能是发起的但是现在在这种文化下几乎就不可能所以我也是非常羡慕就是 Costler 这种文化以及对你能够做出很多你羡慕扑了而且他们的流量对于我这种以前是做网关和很观测性的人来说包括我现在也能做一些内涵的东西我好像 just in dream
不过就加入太好听了那要是 Cloudflare 主要是地域的问题现在 Cloudflare 主要还是在欧洲和美国招人对吧对主要是在欧洲美国其他地方呢尤其是中国这边可能有一个就是工作签证的问题你们会给就是说 Visa 是办签证的时候有支持吗有 Visa 跟绿卡都有的好再努力学习一下争取加入 Cloudflare
可以好反正我觉得 pingura 我之前我就觉得反正是我感觉是能做蛮多好玩的事情对不对对这也要靠社区大家来做我们把这些 API 这些接口开放出来了意思就是大家一起来玩是吧对你们整体上 node balancing 和 plastic head 就是包括你们留的口子都是挺好的
我觉得是挺好用的我觉得就加 hook 点就是我之前做 POC 的时候加一些 hook 点或者是其他的东西都很方便我觉得这件事的确挺舒服的好的行我觉得我们苹果二是不是聊得也差不多大家有什么要补充的吗如果没有我们就可以然后老传统我们还是让嘉宾推荐一些你想推荐的东西就是任何比如说你读了你在看你在用的
妙的事情都可以好的说到推荐我想到的是一个 YouTube 的 channel 是一个 CMU 的 database group 是我读研究生时候在学校的这个 group 然后呢这个 database group 他们放了好多上课的这个教学的 video 就是他这个 professor 给本科生还是给 PhD 学生上课
讲了好多 database 的基础,有好多比如讲 page cache 怎么用呀,什么时候要用不要用啊,里面有什么数据结构需要用,包括分析一些这个事下比较著名的一些数据库,比如说分析 Snowflake 的 database 是怎么做的。
然后分析这个 Databricks 的怎么做的然后 Amazon 是怎么做的然后就有好多好多我之前不懂的东西吧虽然看过之后也不是太懂但是觉得大受震撼觉得这个 YouTube channel 很好而且它一直在 upload 我昨天看它好像是几周前有一个最新的 upload 我看到了感觉看着了好多 Database 的东西啊
他有个特别好玩的就是之前有一个 Andy Powell 的一个课然后他就上课然后把这个课给录下来他的上课的助教叫 DJ Drop Table 每天上课前会给大家搓一顿 DJ 好像是有病我看到他的好多像什么 Morning Circle 他的好多都好贴近现代化的得推荐听众们去看一下
虽然数据不已死但是还是推荐听众们大家都去看一下你还有什么要推荐的吗我这就没什么了 OK 好的行 OK 就聊了很多感觉
听起来就是 Cloudflare 就是一个没什么缺点的公司对吧我觉得好多公司都就是曾经是 Dream Company 我记得在我们最早做节目的时候 20 年的时候 Tidybee 还是 Dream Company 当时我好像在节目里也感叹过
对是不是像我说的然后 JIM Company 都会变得 Bloom Dream 对我觉得 Cloudflare 和 TIDB 其实有点像我就是这种技术驱动的公司可能还是更容易去 Cloudflare 和 TIDB 还是两条路子然后 TIDB 核心没法解决的一个问题是说我为什么要给你付钱但 Cloudflare 实际这个问题是走通了的
你不管是说我能帮你访问很好的速度然后就还是其他东西 TeddyBee 他是走开原生要把炉子他核心的一个逻辑是说没解决了一个问题他说没什么法要解决我为什么要给你付钱他能赚钱的地方都是深水区所以说他赚钱的难度会比 Cloudflare 大很多而且我觉得数据库特别卷现在就是竞争者太多了我刚才说了数据库已死了
对 CrossFitter 感觉没有什么竞争者就是这个钱赚的很出处至少我在肉眼可及范围内说实话的真没有竞争者对就一家赌道相当于跟 Google 的搜索也差不多对然后而且他们做的确牛逼这个你不得不服就你用了各家的云厂商出来之后你会发现那是真的做了牛逼
然后我当时感觉说我要是有 Cloudflare 我们当时是因为有一些原因没法上 Cloudflare 我说要是 Cloudflare 我当时就不我去年有差不多两个月时间都在搞 anti-bot 的东西了人都麻了
好对我觉得这次也是趁着聊品多热的机会给大家科普一下 Cloudflare 所以如果有人还没有用起来的话就是真的可以考虑用一下是吧也是一个然后如果有人还没有投简历的话也可以赶紧考虑一下好了对然后我来问一下对了那个 9m 宇晨推荐完了你有什么推荐没有
我还推荐吗因为我觉得我们聊了挺久所以我没有打算推荐什么我暂时就不推荐了对如果你有什么想推荐你可以说一下星涛你有什么要推荐的吗因为我记得我们之前主播也有推荐的对之前是对
后来推荐了很多期之后好像没有什么剩下什么东西还需要推荐的好吧然后我推荐的话就是我今天给大家在播放里面说的如果你们对 ELF 就可执行文件感兴趣的话
就是 how to execute an object file 这是主要是有 part4 就是 4part 然后欢迎大家去看这个真的写的非常非常详细你去读完之后你基本上对于一个可执行文件的细节然后有非常多的了解然后当然最后一个推荐是摇曳录音第三季正在放送之中请大家及时观看暴露你的真实目的哈哈哈哈
对摇摇录音是世界上最好看的动画以后要一代多出一期来聊摇摇录音好所以可以做好准备好的好那我们就差不多这样结束了对非常感谢雨晨然后我们最后非常感谢雨晨谢谢大家听众打个招呼然后我们就结束吧就各位听众我们下期再见对啊拜拜下期再见拜拜拜拜