“每个新应用都应该从无服务器开始。”

Adobe Creative Cloud早期的服务是用Ruby编写的，但是它们的性能并不好。因此，我们决定用Node重新构建它们。这是我的工作之一。

开发和维护始终在线的API路由是一个昂贵的过程。我们有定制的车队管理软件。每个服务都有一个“/version”路由，我们会自动和频繁地ping它，以便检测停机时间并将离线服务从负载均衡器中循环出来，用新实例替换它们。每个服务器实例都运行一个专为云操作设计的最小Linux发行版。运维团队每周花费几个小时来跟进更新并自定义我们的VM配置。

我们还有一个定制的自动扩展程序，它会监视流量和服务器负载，并在繁忙时自动启动更多服务器。我们有专门的服务器运维支持人员，他们帮助我们构建和维护一个发布训练系统，该系统每小时左右将新更改推送到生产环境。我们的构建和部署流程使用Jenkins自动化处理，这个配置需要相当长的时间才能演变成适合我们的工作的样子。

我们有定制的日志记录服务，它们聚合了我们所有的服务器日志，以便我们可以轻松地查询特定的请求，如果出现问题并且需要调查和调试，我们就可以做到这一点。我们还花了很多时间与MongoDB的工作人员交流，以确定如何将我们的数据库操作水平扩展，以跟上Creative Cloud服务的快速增长。每次推出新服务时，我们都必须进行负载测试和水平扩展测试，以确保它能够很好地扩展。

在Adobe Creative Cloud的早期，Adobe已经是一个成功的软件企业，拥有大量的运营预算和成千上万的开发人员。运行所有这些操作是昂贵的，在Creative Cloud的早期阶段，我们并不确定自己能否很快找到产品市场的适合点。我们有预算去冒险，使其成功，今天，Adobe Creative Cloud是一个每年10亿美元的业务。

如果我们今天从头开始构建Creative Cloud，我们可以用少得多的预算来完成它，而且我们可以免费获得可扩展性。

无服务器架构可以为新开发团队节省数十万美元 - 有时甚至数百万美元 - 在成功的产品发布和增长道路上。除非有非常特殊的情况，否则几乎所有的新软件产品都应该首先采用无服务器架构，并根据需要添加托管服务。

什么是无服务器？

无服务器架构是一种构建和运行应用程序的方式，它不需要传统的服务器基础架构、维护或扩展操作。无服务器应用程序使用第三方后端服务和API，例如Google Firebase或FaunaDB。这些服务通常可以平稳透明地扩展，从小流量到海啸式的峰值流量，这种流量会比你自动扩展以满足需求的传统服务器架构更快地淹没。

使用无服务器架构有许多好处，包括：

• 降低运营成本： 在早期的增长阶段，流量峰值经常带来比通常更多的流量。为了防止服务超载，许多初创公司支付了比他们需要的更多的能力。例如，在DevAnywhere的早期阶段，我们的托管成本超过了每月1,000美元，以跟上大约每周一次的大流量峰值。切换到无服务器架构后，服务器成本降至不到100美元。当预算紧张，重点是找到产品市场的适合点时，这些差异可能会让公司崛起或失败。
• 增加开发人员的生产力： 无服务器架构可以通过允许开发人员专注于构建功能和功能而不是担心服务器基础架构来提高开发人员的生产力。
• 增加可靠性： 无服务器架构可以通过允许它们根据需求动态扩展来增加应用程序的可靠性。无服务器架构对流量峰值的响应具有相对较低的延迟。相比之下，传统的弹性扩展可能需要几分钟才能响应突然的流量激增，这会让第一波用户看到错误消息而不是你的产品。

什么时候需要服务器？

首先，无服务器并不意味着“没有服务器”。仍然有服务器在幕后运作，但你不需要管理或维护它们，因为你的内部API比服务器更细粒度：它们是按需函数和数据查询，而不是始终在线的专用Web服务器。换句话说，你不需要在Docker容器上启动Node、Apache或HAProxy，而是构建函数并让云服务提供商为你处理函数调用。大多数应用程序在没有始终在线的Node运行时侦听请求的情况下都可以正常工作。

你可能需要服务器来处理始终在线或长时间运行的过程，例如高速、低延迟的PVP游戏服务器或使用定制硬件（例如ASIC、神经元群）进行优化。即使你需要这些东西，你的应用程序的许多部分仍然可以受益于无服务器架构（例如你的UX或业务逻辑服务）。

无服务器堆栈

本节是有偏见的：没有详尽的选项列表，列出了利弊以帮助你做出自己的明智决策。相反，我们只会列出我最喜欢的选项。如果你知道一些很棒的替代方案，请在评论中分享。让我们稍微展示一下众人的智慧。

让我们看看一些常见的要求：

• 应用程序框架和部署
• 身份验证
• 数据库
• 内容管理
• 商业
• 媒体和存储

应用程序框架和部署

长期以来，我一直在说使用Vercel就像雇用了世界上最好的DevOps团队，但是你不需要支付他们的工资，他们可以帮你省钱。他们并没有发明它，但是Vercel让与无服务器工作变得轻松。

AWS Lambda可能更为人所知，但是它也很难集成。你需要花费数小时阅读文档。使用Next.JS，你只需要将一个函数放入API文件夹中。要开始，请使用npm install -g vercel，使用npx create-next-app创建一个新的React+NextJS应用程序，然后使用vercel push推送你的第一个无服务器网站。试试看-你可以在几分钟内启动你的第一个部署。

我强烈建议使用Next.js构建你的应用程序。Next是一个原生支持无服务器的框架，支持无服务器函数、边缘函数/API路由、服务器端渲染（SSR）、静态CDN/边缘网络部署、增量静态再生、自动图像优化、捆绑拆分、页面加载时间优化、缓存管理-完美的一应俱全。我曾经担任过一家视频社交网络的技术领导，该网络被NBC、BBC、CBS和《华尔街日报》使用。在我负责的其他事务中，我需要将《华尔街日报》的全球流页面加载时间从惊人的20秒以上缩短。

在这个过程中，我们优化了一切：我们将每个文件压缩到适合网络的大小和格式。我们缓存了所有资产并将它们推送到靠近访问用户的CDN服务器。我们花了一周的时间仅在缓存优化策略上工作。我花了几天时间浏览我们的JavaScript包，手动拆分和优化（这是在打包程序拥有树摇之前）。我编写了一个自定义框架，使我们能够有选择地推迟JavaScript的加载。我尽可能地延迟了每个资产的加载。

最终，我将我们缓慢的移动加载时间从20秒以上缩短到约4秒，宽带加载时间缩短到约2秒。我们获得了Webby提名，并成为众包社交视频的首个大规模演示之一。想象一下在TikTok之前的TikTok。在我们的应用程序之前，电视网络没有好的方式邀请观众参与众包视频。但只有通过大量具有挑战性的优化工作，它才获得了现在的成就。

但是，我使用Next.JS构建的每个应用程序都经过了更好的优化。毫无疑问。你必须犯了什么错误才会在Vercel中无法获得良好的lighthouse分数。看看自己：我们使用Next.JS在Vercel上构建了EricElliottJS.com，我们没有特别优化它。截至本文撰写时，我们的lighthouse性能得分为96。

通过抽象化服务器，Vercel和Next.js使得他们的极其有效的运维团队能够优化部署堆栈的每个部分。我们不必担心哪些服务器具有最低的响应延迟，NodeJS、Apache或HAProxy，我们可以专注于构建应用程序，并通过默认实现世界级性能。

认证

关于认证，你绝对必须了解两件事情：

• 密码已经过时且不安全。
• 永远不要构建自己的认证。 这需要全职、专门的安全专家来正确处理。 因此，自从Magic推出以来，我为我构建的每个应用程序都使用了Magic的Web3认证。他们目前是我唯一信任的认证提供商。也就是说，来自Google这样的大型提供商的社交认证也是可以接受的。Google Firebase还提供了社交认证，完成工作。无论你做什么，都不要启用用户名/密码流程。

数据库

我更喜欢Fauna的GraphQL支持、事件流、可扩展性、超低延迟读写性能和可靠性。额外奖励：你可以使用Fauna DB事件流功能将数据库用作复杂应用程序的消息总线和作业队列，而浏览器内查询订阅可以让你的客户端保持同步。

过去，我也使用过Firebase，但我更喜欢Fauna的功能和查询灵活性。

内容管理

Notion具有API和易于使用的内容管理，许多公司已经在使用它来进行内部团队文档。与大多数无头CMS系统不同，它的价格非常实惠。将他们的API与Next.JS增量静态生成和按需重新验证结合使用，你就可以避免让你的用户等待往返于Notion API。

商务

Stripe非常适合简单的订阅和支付处理。对于更复杂的商务，可以查看Shopify或BigCommerce。两者都支持无头API。对于加密货币交易，Magic Connect提供了即插即用的法定货币入口，包括即时ACH、信用卡、借记卡、Apply Pay、Google Pay和SEPA转账。

媒体和存储

如果你的内容都是由你自己制作的，Next.JS会通过其自动优化的图像标签系统为你提供帮助。如果你需要托管大量用户生成的内容，我最喜欢的可编程媒体API服务是Cloudinary。如果你需要永久的、不可变的存储NFT，你需要NFT.storage - 托管在IPFS上，并由Filecoin支持。