云计算平台称为Flare云计算平台。与我所知的其他云计算平台本质上不同，它不使用容器或虚拟机。我们相信这是无服务器和云计算的未来，我会尽力说服你为什么。隔离两个几年前我们遇到了一个问题。我们内部可以构建的功能和选项数量有限，我们需要一种方法让客户能够自己构建。我们开始寻找一种方法，让人们在我们部署在世界各地的服务器上编写代码（那时我们有一百多个数据中心，截至本文撰写时为155个）。我们的系统需要以低开销安全地运行不可信的代码。我们坐在一千万个网站前，每秒处理数百万个请求，它也必须运行非常非常快点。那个我们以前使用的Lua不是在沙盒中运行的；没有我们的监督，客户无法编写自己的代码。像Kubernetes这样的传统虚拟化和容器技术对于所有参与其中的人来说都是非常昂贵的。在一个位置运行数千个Kubernetes pods将是资源密集型的，在155个位置运行会更糟。扩展它们比没有管理系统要容易，但远不是微不足道。什么我们最终选择了Google Chrome团队开发的一项技术，该技术为浏览器V8中的Javascript引擎提供动力：分离。分离是轻量级上下文，使用允许对变量进行变异的代码对变量进行分组。最重要的是，单个进程可以运行成百上千个隔离，在它们之间无缝切换。它们使得在一个操作系统进程中运行来自许多不同客户的不可信代码成为可能。它们被设计成可以很快地启动（几个必须在您的web浏览器中启动，以便您加载此网页），并且不允许一个隔离项访问另一个。我们只需支付一次Javascript运行时的开销，就可以在几乎没有单个开销的情况下运行基本上无限的脚本。任何给定的隔离都可以比在我的机器上启动节点进程快100倍左右。更重要的是，它们消耗的内存比这个数量级要少过程。他们拥有所有可爱的功能即服务的人体工程学，只需编写代码，而不必担心它如何运行或扩展。同时，他们不使用虚拟机或容器，这意味着你实际上比我所知的任何其他形式的云计算都更接近金属。我相信使用这个模型可以接近在裸机上运行代码的经济性，但是在一个完全没有服务器的环境中环境。这个并不是为了给员工做广告，但我想给你们展示一张图表，以反映两者之间的差异有多大，展示为什么我认为这不是一个迭代的改进，而是一个实际的范例 班次：这个数据反映从部署了所有功能的数据中心发出的实际请求（包括网络延迟），执行CPU密集型工作负载。SourceCold starts并不是每个人都完全理解Lambda这样的传统无服务器平台是如何工作的。它为您的代码启动一个容器化进程。它没有在任何比在自己的机器上运行Node更轻量级的环境中运行代码。它所做的是自动缩放这些进程（有点笨拙）。自动缩放会导致冷启动，冷启动是指当你的代码的新副本必须在机器上启动时发生的情况。在Lambda世界中，这相当于启动一个新的集装箱化进程，这可能需要500毫秒到10秒。你收到的任何请求都会被挂起长达10秒钟，这是一种糟糕的用户体验。由于Lambda一次只能处理一个请求，所以每次收到额外的并发请求时，都必须冷启动新的Lambda。这意味着延迟请求可以反复发生。如果Lambda没有很快收到请求，它将被关闭，然后重新开始。无论何时部署新代码，都会再次发生，因为每个Lambda都必须重新部署。这被正确地引用为Serverless并不是它被破解的全部原因是的。因为工人们不必启动一个进程，隔离在5毫秒内开始，持续时间是不可察觉的。隔离以同样的速度扩展和部署，完全消除了现有无服务器服务器的这一问题技术背景切换操作系统的一个关键特性是它使您能够同时运行多个进程。它透明地在希望在任何给定时间运行代码的各种进程之间切换。为了实现这一点，它会进行所谓的"上下文切换"：将一个进程所需的所有内存移出，并将下一个进程所需的内存移出在。那个上下文切换最多需要100微秒。当乘以平均Lambda服务器上运行的所有节点、Python或Go进程时，这将产生一个沉重的开销，这意味着并不是所有的cpu能力都能真正用于运行客户的代码；它花在了在之间的切换上他们。一个基于隔离的系统在单个进程中运行所有代码，并使用自己的机制以确保安全的内存访问。这意味着没有昂贵的上下文切换，机器几乎所有的时间都在运行代码.记忆Node或Python运行时是由个人在自己的服务器上运行的。它们从未打算在多租户环境中运行，该环境中有成千上万的其他人的代码和严格的内存需求。不运行实际代码的基本节点Lambda消耗35mb内存。当你能像我们一样在所有的隔离系统之间共享运行时，这个数字会下降到3个左右MB内存通常是运行客户代码的最高成本（甚至高于CPU），将其降低一个数量级会显著改变经济学。基本上V8设计为多租户。它被设计成在一个单独的进程中从浏览器的多个选项卡运行代码。节点和类似的运行时不是这样的，它显示在构建在上面的多租户系统中it安全运行同一进程中的多个客户代码显然需要仔细注意安全性。对于Cloudflare来说，如果自己构建隔离层，将不会有效率。它需要大量的测试，模糊化，渗透测试，以及建立一个真正安全的系统所需的资金复杂性。这个唯一可能这样做的原因是V8的开源特性，以及它作为地球上最受安全测试的软件的地位。我们还建立了一些安全层，包括针对定时攻击的各种保护，但是V8才是制造这种计算模型的真正奇迹可能的。比林并不是要对AWS的账单进行全民公决，但它值得一提，因为经济学很有趣。Lambdas是根据它们的运行时间来计费的。这个账单被四舍五入到最接近的100毫秒，这意味着人们在每次执行中平均多付50毫秒的费用。更糟糕的是，他们会为Lambda运行的整个时间向您收费，即使它只是在等待外部请求完成。由于外部请求可能需要数百或数千毫秒，因此您可能会在规模。孤立内存占用如此之小，我们至少可以负担得起你的代码实际运行时的账单正在执行。输入在我们的例子中，由于较低的开销，每个CPU周期的工作人员成本降低了大约3倍。一个提供50毫秒CPU的工作线程是每百万个请求0.50美元，相当于每百万个Lambda是1.84美元。我相信，将成本降低3倍是一个足够强大的激励因素，单凭这一点就可以激励公司转向以孤立为基础的公司提供程序网络是亚马逊的一款产品边缘处的Lambda部署到CDN数据中心。不幸的是，它的成本是传统Lambda的三倍，而且最初部署需要30分钟。它也不允许任意请求，限制了它对类似CDN的有用性-目的相反，正如我提到的，通过隔离，我们能够以比Amazon更好的经济性将每个源文件部署到155个数据中心。实际上，运行155个分离物比一个容器便宜，或者亚马逊收取的费用是市场承受的，而且远高于它们的成本。我不知道亚马逊的经济学，我知道我们对我们的。很久了-以前很明显，要想拥有一个真正可靠的系统，它必须部署到地球上不止一个地方。Lambda在单个可用性区域、单个区域、单个数据中运行中心。劣势否科技是神奇的，每一次转型都会带来不利因素。基于隔离的系统不能运行任意编译的代码。进程级隔离允许Lambda启动它可能需要的任何二进制文件。在一个孤立的世界中，你必须要么用Javascript（我们使用大量的TypeScript）编写代码，要么使用一种针对WebAssembly的语言，比如Go或生锈，如果你不能重新编译你的进程，你不能单独运行它们。这可能意味着基于隔离的Serverless只适用于不久的将来更新、更现代的应用程序。这也可能意味着遗留应用程序最初只将对延迟最敏感的组件移入隔离区。社区还可以找到新的更好的方法，将现有的应用程序转换到WebAssembly中，呈现问题模拟。你的帮助我希望你能尝试工人，让我们和社会了解你的经历。我们还有很多东西要做，我们可以用你的反馈。我们还需要工程师和产品经理谁认为这是有趣的，并希望采取新的方向。如果您在旧金山、奥斯汀或伦敦，请联系出去。有兴趣吗部署Cloudflare Worker而不在Cloudflare上设置域？我们让我们更容易开始建造服务器