本文要点
Serverless 不仅仅是功能即服务（FaaS）。不要担心供应商锁定；接受供应商通过事件集成来提供的功能。开源工具有助于简化复杂应用程序的构建。使用基础设施即代码（Infrastructure as Code，IaC）的解决方案（如 CloudFormation）来定义 Serverless 应用程序并简化 DevOps。强大的监控解决方案可以通过精确的成本管理和评估工具提供函数和集成性能的可视化。
尽管在过去几年中， Serverless 技术已经得到了迅速普及，但是对于 Serverless 解决方案仍然存在许多误解和担忧。供应商锁定、工具、成本管理、冷启动、监控和开发生命周期都是 Serverless 技术相关的热门话题。本文旨在解决其中的一些问题，并分享相关的技巧和资源，以指导 Serverless 新手构建功能强大、灵活且经济高效的 Serverless 应用程序。
对 Serverless 技术的误解
其中一个主要的误解是，Serverless 等同于 功能即服务 （ Functions as a Service ，FaaS），因此不值得为此作出特别激进的改变。虽然 AWS Lambda 无疑是 Serverless 崛起的明星之一，并且可以说是 Serverless 架构越来越受欢迎的因素之一，但与 FaaS 相比，Serverless 还有更多功能。
Serverless 的核心原则是：我们不必担心如何管理基础设施或者扩容缩容，只需为使用的内容付费既可。如果考虑这些因素，那么就有许多可用的服务了，比如 AWS DynamoDB、S3、SNS 或 SQS、Graphcooll、Auth0、Now、Netlify 或 Firebase（还有很多很多）。最终，Serverless 提供了强大的云计算功能，而无需承担管理基础设施或优化容量可伸缩性的负担和责任。这种抽象还意味着基础设施层的安全不再是我们需要关心的问题了，考虑到维护安全标准的难度和复杂性，这是一个非常大的利好。最后但也很重要的是，如果我们不使用它所提供的基础设施，那么就不必为此付费。
也可以认为 Serverless 是一种“思想状态”——一个人在设计解决方案时所采用的思维方式。避免使用需要维护任何基础设施的方式。通过 Serverless 的方式，我们正在试图将我们投入在项目中的工作时间重新分配到对用户有更直接影响和益处的事情上，比如健壮的业务逻辑、能吸引用户的界面及快速响应、可靠的 API 上。例如，如果我们可以通过支付 Algolia 来避免管理和维护一个自由文本搜索平台，那么这就是我们将要做的。以 Serverless 的方式来构建应用程序可以极大地缩短上市时间，因为我们不再需要担心如何管理复杂的基础设施了。这样可以规避管理基础设施产生的责任和成本，并能集中精力构建客户真正需要的应用程序和服务，这种方式，Patrick Debois 称之为“ 全服务 ”，这个术语已经得到了 Serverless 社区的认可。其次，函数应该被视为将服务绑定在一起的粘合剂，并且可概念化为部署单元（而不是部署整个库或 Web 应用程序），从而允许对应用程序的部署和变更进行非常细粒度的控制。如果不能以这种方式部署函数，那么这可能是一种代码坏味道，表明该函数承担了太多的职责，应该进行重构了。
在开发云应用程序时，有些人担心供应商锁定。对于 Serverless，这种担心仍然存在，我认为这是源于对 Serverless 真正含义的误解。例如，以我在 AWS 上构建 Serverless 应用程序的经验来看，采用 AWS Lambda 将其他 AWS 服务粘合在一起，是 Serverless 架构强大功能的一部分。这个例子很好地说明了整体是优于局部的。试图避免供应商锁定实际上会导致比我们想要解决的问题还要更严重的问题。使用容器时，在云供应商之间管理自己的抽象层可能会更容易些，但是当使用 Serverless 时，特别是考虑到 Serverless 的成本效益时，这种努力就不值得了。一定要考虑供应商是如何提供设施来暴露服务的；一些专用服务依赖于与其他供应商的强大集成点，并且提供了开箱即用的钩子。从 API 网关端点处指定需要调用的 Lambda 比将请求代理到现有容器或 EC2 实例中要更容易些。Graphcool 使用 Auth0 提供了简单的配置，这比使用自定义标识提供程序也更容易。
为我们的 Serverless 应用程序选择合适的供应商是一个架构决策问题。我们不应该假定某天再回过头来管理服务器，并以此前提来构建 Serverless 应用程序。选择云供应商与选择使用什么容器或什么数据库来构建应用程序，甚至与用什么语言来编写代码没有什么不同。
最好考虑下如下几点：
你需要什么服务以及为什么需要这些服务。云服务供应商提供了哪些不同的服务，以及如何使用你所选择的 FAAS 实现将这些服务粘合在一起。支持哪些编程语言（是动态类型还是静态类型、是编译代码还是解释代码、基准测试、冷启动性能、开源生态系统等）。你的安全要求是什么（SLAS、2FA、OAuth、HTTPS、SSL 等）。如何管理 CI/CD 和软件开发周期。可以利用什么样的基础设施即代码（IaC）解决方案。
如果你正在对一个现有的应用程序进行扩展并添加了 Serverless 功能，那么这可能会限制你的选择，不过几乎所有 Serverless 技术都提供了某种形式的 API（通过 REST 端点或消息队列），这些 API 提供了一个简单的集成点来将应用程序扩展成可以独立开发的二手手游账号交易平台核心应用程序。选择使用那些提供了易理解的 API 并且具有可靠的文档和强大社区的服务，这样你就不会出错了。很多时候，当谈到 Serverless 技术时，集成的简单性可能是我们关注的关键指标，它可能也是自 2021 年 Lambda 发布以来，AWS 获得成功的最大贡献因素之一。
在什么情况下使用 serverless 是有益的
Serverless 几乎可以用在任何地方，我发现现在的使用情况还远远没有发挥出 Serverless 计算的好处。由于 Serverless 技术的存在，云计算的进入门槛现在非常低。如果开发人员有一个想法，但不知道如何管理云基础设施和优化成本，他们完全无需担心是否能找到一个有工程背景的人来帮助他们。如果一家初创公司正在试图构建一个平台，但又担心由此产生的成本，那么他们可以采用 Serverless 的方式轻松实现。
由于 Serverless 能节约成本且具有可伸缩性，它可以像适用于具有遍布全球数百万用户的 Web 应用程序那样，适用于内部 IT 系统。当谈到计费时，我们可以用美分而不是用欧元（或其他货币）来结算。这是非常强大的。就算是最基础的 AWS EC2 实例（t1.micro）持续开一个月，即使什么都不做（谁还没有忘记关闭的时候呢！），我们也需要花费 15 欧元。为了和 AWS EC2 进行比较，产生相同的成本水平，我们需要在同一时间段内运行一个 1 秒内可达到 300 万次的 512MB 的 Lambda 函数。同样地，如果你不使用这个函数，它就不会产生任何费用。
由于 Serverless 主要是基于事件的，所以可以将 Serverless 基础设施直接添加到传统系统中。例如，可以使用 AWS S3、Lambda 和 Kinesis 为传统零售系统搭建可以通过 API 网关端点接收数据的分析服务，或者使用 DynamoDB 流和 Algolia 来改进自由文本搜索系统。
绝大多数的 Serverless 平台都支持多种语言，最常用的有 Python、JavaScript、 C#、Java 和 GO。一般来说，各语言都没有对可使用的库进行限制，因此，我们可以随意选择使用我们最擅长的开源代码库。然而，保持低依赖性仍是个不错的主意，它可以确保函数尽可能地在最佳状态下执行，并能利用 Serverless 应用程序强大的可伸缩性。容器需要装载的包越多，冷启动时间就越长。
冷启动是指容器、运行时和函数处理程序在使用之前要先初始化。它可能会导致大约 3 秒
