无服务器计算快速入门指南

引言

我参与的第一个网站可以追溯到 90 年代末，那时甚至有些人还不知道什么是网站。当时，项目规模非常庞大……我是说，真的真的非常庞大。在确定了服务的功能后，我们就制定了项目计划和预算。那时我们的项目成本估算如下：

• 购买服务器：250,000 美元
• 第一年服务器托管费：75,000 美元
• 工程师和其他“人员”相关费用：350,000 美元

此外，为了确保项目成功，我们不得不搬到一个离数字交换中心更近的新办公室，以便获得一条快速的、有保证的 128k < ahem > 速度的互联网连接……这是一个*巨大的*项目…… :)

 

请不要误会，这并不是来自黑暗时代……不涉及打孔卡之类的东西，但当时确实是一个大项目……如果换算成今天的项目，它只是一个基本的网站——但在那时，这可是职业生涯的转折点！

所以，回想起来，对于一个相当基本的网站来说，它似乎异常复杂和庞大，并且消耗了相应庞大的资源。昨天，我有一个关于新SaaS网站的想法……花了 30 分钟将 AngularJS 和 EntityFramework 整合起来搭建我的CRUD，我做了这个……在 Visual Studio 中，“文件 -> 新建 -> 网站（云发布）”。

这真是太棒了……我的第一个网站花费了超过五十万美元，并且花费了数月才能完成。昨天，我在几分钟内发布了一个网站，每月运行成本不到一美元……

再也不用费劲地发布到特定文件夹，通过 ftp 将代码/DLL 和支持文件上传到服务器主机，乞求他们允许我包含某种我*真的*需要的、非标准的新插件或 DLL（以便我能拿到报酬）……然后祈祷一切都能正常连接，网站能够成功部署。当时，当（而不是如果）出现问题时，只有上帝才能帮我，因为在那一阶段，托管机器上的日志记录或调试支持非常少……即使到现在，有些主机在这方面仍然停留在黑暗时代。

托管和云服务的发展...

那么，我们是如何达到如今可以以闪电般的速度处理网络事务的阶段的？什么是无服务器计算和云函数？让我们回顾一下过去几年的发展历程，看看事物是如何演变的……

本地服务器

15 年前，在办公室（或家里）放置一台直接连接到网络的服务器非常普遍——我的意思是，你有一台物理服务器，具有固定的 IP 地址，就放在你的办公室里，暴露在互联网上。有些地方仍然保留这种设置，但出于显而易见的原因，这种设置越来越少见。当我们想发布一个网站或在网上公开一项服务时，这真的很简单——主要是因为我们拥有*控制权*……我们直接访问物理机器，并且可以在这台机器上*做任何我们想做的事*……安装这个或那个 DLL，安装这个或那个服务，或者安装你的网站*无法生存或工作*的那个特殊的 ActiveX 插件……

这种设置的问题在于它很浪费、很昂贵，而且让你不得不成为整个基础设施的管理者，而不仅仅是你构建的网站。

主机托管服务器

然后有人想出了一个主意，将他们数据中心的“机架空间”出租给拥有自己物理机器并希望分担一些管理工作的人。这意味着你仍然拥有物理机器，但你可以将其送到一个专门的地方，那里的人知道如何维护面向互联网的服务器的“正常运行”，并负责备份、数据库连接、服务器补丁、安全等。说实话，网站开发者真的不应该担心这些事情……在这个阶段，它们应该只是基础设施的一部分……

然而，自己托管服务器的一个问题是，它仍然是*你的*服务器，尽管其他人正在管理机器及其相关开销，但效率不高……机器的利用率不高，可能 80% 以上的实际计算生命周期都处于空闲状态。这是浪费的钱，本可以用于更好的地方。

共享服务器

事物发展的下一步是共享服务器。这是主机托管公司在其*自己的*硬件/操作系统上安装了一些高级软件，允许他们隔离某些文件夹/进程，并在多个不同的网站客户之间共享资源。这立即的好处是服务器的使用时间大大增加，但代价是客户的灵活性降低。然后，客户会获得一个“控制面板”，并使用它来与他们可以安装/运行/上传等服务进行交互。

共享服务器的一个主要问题是资源是共享的……操作系统是共享的，机器资源是共享的……如果某个进程失控，并在一段时间内占用 100% 的 CPU，那么该机器上的任何其他网站/进程都会因此受到影响……这真的不是一个好情况。

虚拟服务器

然后，一个聪明人（我很确定不是一只兔子）想出了虚拟机的聪明主意。这是一个系统，可以非常精确地隔离服务器硬件的部分，并将其呈现给操作系统，操作系统将这些隔离的服务器部分视为“整个服务器”……仔细想想——就像我们拍摄整个机器的快照，将其分解成块，然后交给完整的操作系统说“这就是你所能获得的一切”。这很棒，因为例如，我们可以拥有一台强大的机器，比如一个主板、1GB 硬盘空间、32GB 内存，然后将其虚拟分成 8 个虚拟机，每个虚拟机拥有 2GB 内存和 100GB 硬盘空间……其中一个虚拟机足以运行一个合理的 SQL Server 实例，并且仍然有足够的空间来运行底层的虚拟机操作系统服务本身。

虚拟机运行得很好，现在仍然如此，但它们仍然存在一个限制——它们是完整的虚拟操作系统环境……如果你需要为每个需要的服务启动一个完整的操作系统。这有点浪费，并且资源利用率不高（哇，与我们办公室里那些专用机器的日子相比，我们已经走了多远！）。

容器和 Docker

好了，这次演进的下一步是转向容器化。容器技术使我们能够在*机器内部*（无论是虚拟的还是其他的）创建一个隔离的资源块，并共享底层的机器资源，而不会溢出到使用相同资源的其他服务中。所以实际上，它就像一个共享服务器，但没有因不良资源管理而导致一个安装系统意外控制另一个的副作用。容器的另一个主要好处是，你可以指定特定版本的系统级依赖项。例如，假设你的系统需要特定版本的 DLL 或其他可安装项……但问题是，这是一个自定义的，甚至是过时的依赖项版本，它与*共享*该资源/依赖项的虚拟机上的其他进程不兼容。使用容器，你可以这样隔离依赖项，并有效地将它们从彼此之间防火墙化。这样做的好处是，如果*在你的机器上可以正常运行*，那么你可以拍摄这个配置的快照，并将其传输到在线主机（或其他开发者的机器）上，在那里它*将简单地运行*，无需任何疑问。这是容器的一个极其强大的功能，即使没有其他原因，也值得为此进行研究。

隆重推出*服务型函数*

容器范式使我们进入了一个区域，我们可以拥有“手术般切分”的操作系统部分，仅用于我们的简单系统。我们可以使用容器托管简单的、单一的服务，例如 SQL Server，或者更复杂的不同服务组合。但有时，我们需要*更精简*的东西。有时，我们需要一个简单的“小东西”，你会想，实际上，我系统/架构的*这一个特定部分*最好放在一个*共享实例*中……在我需要它的时候就能工作，而无需虚拟机或甚至需要管理（和编排）容器的开销。现在，你可以两全其美了……隆重推出“服务型函数”，或“无服务器计算”。亚马逊 AWS 提供“Lambda”服务，微软 Azure 提供“Functions”。你现在可以编写一个简单的函数，无需支持网站或容器，只需说“当 X 发生时运行此”。这张图解释了我的感受……

服务型函数使我们能够编写一个简单的函数/方法，在 Web 上执行某项操作，并部署它来运行，而无需担心底层基础设施，无需担心设置容器或虚拟机，也无需担心我们通常需要做的任何事情才能开始。

它被定义为“无服务器计算”，因为它就是字面意思——能够编写一个函数（或者实际上是一组函数），并将它们部署到一个对我们来说看似无服务器的环境中。云提供商负责部署、隔离，以及至关重要的、必要的自动扩展。与虚拟机和 Azure 的“平台即服务”类产品不同，Functions 的计费不是按小时，而是按执行次数和微秒计算。这引发了一个非常有趣的问题……过去，现在也是如此，我们查看我们的应用程序并思考“瓶颈在哪里……什么导致速度变慢？”……嗯，随着无服务器计算的引入和*按函数*收费，我们现在可以从“哪个函数*正在花费公司最多的钱*”的角度来看待问题……真的很，真的有趣。但我跑题了……

假设我们的客户来找我们说：“嘿，我们能实现一个简单的功能，当上传一张图片时，我们检查它是否在我们指定的尺寸范围内，如果不是，我们就编辑/调整图片使其符合我们的要求吗？”……

在 Functions 出现之前，我们不得不将其添加到我们现有的 Web 服务代码中，进行集成，然后上传更改。有了 Functions，我们只需进入在线编辑器，定义一个端点（在本例中，是监控传入图片文件的位置），然后编写一些代码，当图片上传时就会被处理。就是这样。无需托管设置，甚至无需“文件 | 新建 | 项目”！ （好吧，你可以这样做，但实际上并不需要）。
 

现在，Azure 和 AWS 中的 Functions 并非万能，并且像许多新工具一样，它们有可能被滥用于错误的事情。然而，我坚信在微服务领域，Functions 具有巨大的潜力，非常值得探索。

入门资源

想要深入了解（并且你应该的，真的！），请查看亚马逊的 Lambda 产品和Azure Functions。你不会后悔的。

两个视频让你快速上手

Azure

AWS Lambda

我将很快在这篇文章之后提供一些示例，帮助你入门。

历史

• 版本 1 - 2016 年 12 月 6 日：初始发布
• 版本 1.1 - 2016 年 12 月 7 日 - 更改为“Bob 的大脑受到震撼！”