Varish中用于多租户的虚拟机

2020-08-14 02:35:18

关于做一些疯狂或新鲜的事情,我意识到的一件事是,除非你深入其中,否则你不会真正理解其中的可能性。例如,我很早就不知道这个项目是否会成功。或者,您将能够嵌入SQLite数据库并在边缘上以非常高的并发级别生成动态内容。

Varish目前使用VCL作为一种配置语言,用于编程Varish如何处理请求、响应、缓存和其他事情。

有了Workers,我们已经能够将路由和高速缓存推向边缘,使我们能够进一步扩展,同时为数百万开发人员改善NPM的性能。离开VCL意味着我们可以花更多的时间在JavaScript上,这是我们喜欢的。“。

毫无疑问,VCL缺乏通用的计算功能、合适的对象以及许多其他现代功能。但它有天然的速度。它是目前最快的缓存配置语言。不过,我还是能感同身受。然而,问题是,想出一个只需几毫秒就能启动的解决方案并不是答案。也不是完全脱离VCL。在不透露太多内容的情况下,我将讨论我用Varish实现微型虚拟机的项目的当前状态。

虚拟机允许您在任何地方运行不受信任的代码,包括在边缘。它可以承载任何计算机语言,真的,只要该语言可以输出您的虚拟机可以处理的机器代码。微小的虚拟机在任何意义上都不必是传统的虚拟机。在这种情况下,它们被编写为具有低开销、快速启动和拆卸,并且它们不必模拟任何特定的系统(例如Linux用户空间)。在本例中,它们使用为HTTP缓存编写的有限API。他们不能读/写文件。他们不能连接到任何东西,也不能修改系统设置。他们能做的就是修改HTTP报头字段并生成动态内容。

HTTP缓存是以各种方式交付缓存内容的高并发野兽。它们充当传统Web服务器的加速器,如今到处都在使用。在HTTP缓存中编程是一种奇怪的体验,因为一切都被推到了极限。例如,内存缓存总是被丢弃,因此您的所有合成基准测试都没有意义。如果你在大域名上使用-v键,你无疑会看到一些Via Varish弹出。

那么,我到底在做什么呢?嗯,我想探索使用仅针对单个请求存在的微型虚拟机(无论是在HTTP缓存的前端还是后端)所提供的可能性。这是一项非常具有挑战性的任务,因为这些东西会让互联网做出反应。我不能就这么扔进一个仿真器,然后说“去他妈的,多几毫秒不会伤害任何人。”谢天谢地,我一开始的开销是70微秒。这是什么意思很难解释,但我会试一试。看,有一台为每个租户创建的主计算机,除此之外,我们还为每个请求创建了一个快速副本。然后再删除它。这提供了重要的保证,并使人们更容易对安全性和生命周期进行推理。现在,机器的开销是在外部测量的,即为来自该机器的合成响应(例如403禁止响应)提供服务所需的时间。如果我们在内部测量时间,我们得到的各种好看的数字都低得离谱,但我想把苹果与苹果进行比较。

在这方面工作了一个月后,我最终获得了8-13微秒的开销,与本机代码相比,可伸缩性提高了2.75倍。一点也不坏,因为对于任何正常的程序,您都可以在100微秒内轻松完成。当然,如果没有系统调用形式的本机代码的帮助,您就不能调整大图像的大小。为什么不行?嗯,因为CDN操作符对在虚拟机内执行的代码施加限制。那样的话,没有租户可以坐在那里,只剩下我的比特币。不过,我想如果你为这项特权付钱,你很有可能做到!

为了解决合成基准无法解决的高并发环境中的问题,必须应用许多疯狂的优化。我有一个合成基准测试套件,那里的所有东西都是以纳秒为单位测量的。在300k请求/秒期间,只需将几个字节从A复制到B,就会耗尽500 ns。不过,我不会多谈这一点。当我在做这件事的时候,一些有趣的想法浮现在我的脑海里。

我注意到,我也许可以添加一个更新函数,在该函数中,您向租户提供二进制文件,租户将在运行时立即开始使用它。CDN可以随心所欲地实现更新方法,但一种方法是只接受POST请求。当然要经过一些认证。因此,现在有了租户逻辑的实时更新,允许CDN让路,让租户直接更新自己的逻辑。它立即生效。如果更新初始化失败,旧的更新将继续运行。

我测量了一次更新大约需要1毫秒来初始化等等。这并不重要,因为它不会影响缓存的操作。不过,密切关注这件事是很好的。

/*实时更新机制*/if(req.method==";post";){std.cache_req_body(15MB);set req.backend_hint=tenant.live_update();return(Pass);}。

通过实现一个简单地调用VM的假后端,可以让租户动态生成内容。这和人们想象的完全一样。该函数只返回内容类型和内容。

由于VM几乎可以运行任何语言,例如,它还可以运行内存中的数据库。当然是只读的。有了实时更新功能,它就不会过时。这带来了挑战:大型二进制文件占用大量内存。

函数的作用是:告诉Varish/cdn下一步要做什么。在本例中,我们将返回my_page以生成动态响应。API实际上只是碰巧可以工作的示例代码。

通常,当您考虑共享内存时,您会认为是在主机和虚拟机之间共享。或者在线程之间,或者在CPU之间共享页表。在本例中,我必须在每个租户的所有机器之间共享可执行文件和只读段,以确保大型二进制文件不会耗尽每个请求的工作区预算。请求不能有很多预算,因为它们太多了,而且根本无法扩展。相反,这个内存应该只属于原始机器,不应该复制。毕竟它是只读的。

好的,应该够了,对吧?不是的。原来,在带有溢出分配器的固定大小的红黑树中,每个页面都有80字节大,这也是一个问题。看看这个计算:

15MB/每页4096字节*每页80字节=~300KB。如果每个页面都是零字节,那么它仍然会使用48字节,所以尝试缩小页面不会有什么好处(尽管它们确实从80开始,并且我设法减少了一些脂肪)。300KB太大了,无法对每个请求进行初始化。因此,剩下的唯一一件事就是验证二进制文件是否有一个顺序的执行段,然后是一个顺序的只读段,然后与每个分叉机器顺序地共享这些页面(不是数据,只是页面信息)。最后,在我的大多数基准测试中,它实际上是一个优化,现在二进制大小根本不影响请求!几乎是怪异的。

我目前正在做的一件事就是如何调试这些东西。我编写了类似strace的日志记录功能,它可以在VM内部运行,而无需任何人真正知道或关心:

>;>;>;ypizza.com:[trace]HTTP(REQ)::Append(X-VM:客户端请求)>;>;>;ypizza.com:[trace]HeaderField(REQ,9)>;>;>;ypizza.com:[trace]name()=";ypizza.com";>;>;ypitza.com:[trace]name()=";ypizza.com";>;>;ypitza.com:[trace]name()=";ypizza.com";>;>;>;ypizza.com:[trace]HeaderField(REQ,10)>;>;>;ypizza.com:[trace]Decision(synth,200)>;>;>;ypizza.com:[trace]HeaderField(REQ,1)>;>;>;ypizza.com:[trace]HeaderField(REQ,1)::regsub(0,

Varish本身也已经有了大量的日志记录解决方案,应该真的会涵盖其余的解决方案。尽管如此,我还是计划做一些API模拟,让人们可以直接从Linux运行他们的代码。不过不能保证。

我不知道它能支持什么,但我想我必须选择一种语言并坚持下去。我一直在看围棋,但我不确定它是否可以成型。较旧的语言是,Rust也可能满足这些要求。

现在我使用C++,因为使用newlib构建非常容易,覆盖所有内存处理C函数以将它们加速为系统调用,并编写内联汇编来优化通用API。顶部的抽象使得代码易于使用。但是,C++有一个难以理解的错误消息问题。所以我还不确定。毕竟,这不是真的为我写的。

另外,我可能只编写一个KVM虚拟机管理程序。这是一个很好的概念验证,真的远远超出了我的预期,但我认为VCL已经开创了本机速度的先例。好的,KVM_EXIT_HLT:)