过去一年，无服务器计算（serverless）已成为构建和运行现代应用程序和服务的普遍架构替代方案。无服务器应用程序允许开发人员专注于代码，而不是基础架构配置和管理。这加快了研发和发布周期，并允许更好、更有效的扩展。 无服务器计算已成为各大趋势榜单的常客，但是，这个天天被说来说去的东西到底是什么？
无服务器计算与新兴体系结构和技术密切相关，比如微服务和容器。Greenfield、云原生应用通常基于微服务，这使它们成为在容器上运行的理想选择（Docker）。无服务器允许应用程序和基础架构之间进一步分离和抽象，成为开发跨不同环境运行的现代微服务程序的理想模式。
随着无服务器应用程序的使用越来越多（Lambda 是 AWS 提供的最受欢迎的云服务），希望为内部工程师提供无服务器体验的企业也越来越多，这意味着无服务器计算将成为混合云环境中的重要技术。
虽然无服务器计算提供了很多好处，但是与容器一起成功实施还是存在很多挑战，特别是 IT 运营层面。虽然无服务器计算加速了开发，但它需要 Kubernetes 集群才能运行，而 Kubernetes 的部署和管理非常困难。此外，这些新技术增加了企业支持的 IT 环境、工具和应用程序的复杂性。
无服务器架构简介
首先，我们需要了解一些定义。
云原生：云原生架构最关键的特性是动态扩展以支持大量用户及大型分布式开发和运营团队。如果你认为云计算本质是多租户时，这个要求就更为重要。在这个领域内，我们需要解决的典型问题如下：
1、动态扩缩容能力
2、自动处理破坏应用程序可用性的跨层故障
3、通过确保组件本身提供松耦合来适应大型开发团队的能力
4、能够使用几乎任何类型的基础设施（计算，存储和网络）
Micro 和 Serverless：现代应用架构演变
大多数企业的传统应用程序本质上是单片式的，在应用程序组件、基础架构、开发团队、技术和工具之间具有紧密耦合和相互依赖性。这种耦合对开发速度和灵活性，新技术的采用或 DevOps 实践，以及易于扩展和操作应用程序提出了挑战。
微服务是面向服务的体系结构（SOA）范例的自然演进。在这种说法下，应用程序被分解为松散耦合的业务功能，每个功能映射到一个或多个微服务。每个微服务都是为特定的，细粒度业务功能而构建的，可以由独立的开发人员或团队处理。通过作为单独的代码工件，它不仅从工具或通信角度松散耦合，而且从构建、部署、升级和维护角度来看，每个微服务都可以选择本地化数据存储。采用这种方法的重要优点是，每个微服务都可以使用与应用程序其他部分隔离的技术堆栈来创建。
容器是运行微服务最有效，最优化的方式，可以使用容器编排解决方案（例如开源 Kubernetes）来处理容器集群的运行时操作。
无服务器计算是技术趋势的下一步。
无服务器计算是软件开发的新范例，基于此，应用程序开发人员可专注于编写程序功能，不必花费时间和精力来配置、管理、部署和运行这些程序所需的资源。
在此范例中，云或基础架构提供商需要为应用程序执行所有必需的管道，以便在收到请求后对其进行实例化。开发人员专注于应用程序的代码，底层数据中心提供商有责任可靠地管理运行它所需的相关资源。
功能即服务（FaaS）是最常见的无服务器计算类型，其中，应用程序被开发为针对粒度用例的纯软件功能（如果愿意，可以使用非常精细的微服务）。然后，多个功能可以组合并可选地与微服务应用程序结合使用以执行业务功能。
无服务器计算允许细粒度计费，由于其获取空闲功能以消耗更低的 CPU 和内存，因此集群资源与实际使用比例和部署大小成正比。当功能空闲时，服务器资源不会被实例化，因此降低了成本。但请记住，计费优势对实际使用模式非常敏感。每 10 秒运行一秒钟功能在 Lambda 上会便宜一些，但如果每 10 秒运行 2 秒，那么在 EC2 上会便宜一些。用户必须准确模拟使用情况，并评估无服务器是否真的能节省资金。
无服务器架构的特点
无服务器体系结构或功能即服务（FaaS）符合以下主要原则：
- 整体处于松耦合架构状态，虽然使用这些的应用是典型 Web 或客户端程序，但也支持物联网、流数据等的大量使用。这些应用程序利用基于云的第三方服务，比如事件、消息传递，身份验证服务等。
- 支持各种数据模型——NoSQL 占主导地位，因为无服务器体系结构中的函数是轻量级的，需要将所有依赖打包到一个灵活的数据库中，NoSQL 就非常合适。
- 要求横向扩展作为一项基本原则，应用程序应根据吞吐量自动向上或向下扩展。
- 从开发人员的角度来看，无服务器框架提供的灵活性使其成为开发数字应用程序快速且经济高效的方式。
- FaaS 应用程序需要从底层基础架构堆栈中完全抽象出来，这是很关键的，因为开发团队可以专注应用程序代码，而不必担心底层 OS、存储和网络的维护。
- 自动管理云原生无服务器应用程序的供应、部署、规模周期，从扩展和故障转移角度来看，支持任何负载的全天候操作。
因此，FaaS 架构的整体流程非常简单：
- API Manager 接收事件
- 管理器创建 http 请求，函数被启动
- 该函数首先在容器中实例化。容器具有函数运行所需的所有配置，包括其依赖性
- 该函数处理请求
- 自动销毁容器
- 用户只需在运行函数期间支付所消耗的资源（RAM，CPU，磁盘等）
无服务器计算解决了开发人员面临的最大挑战（即使用 PaaS 或容器编排平台，如 Kubernetes）——需要拥有、扩展和管理基础架构。运行这些无服务器工作负载的容器既不是由开发人员配置也不是由其监控或以其他方式管理的，但他们可以构建运行应用程序而无需担心服务器。
关于无服务器与 PaaS 的说明
无服务器框架与 PaaS 技术有四种不同的方式：
- 如果是由数百个微服务组成的巨型组件，那么微服务本身可以分解为数百个功能。与 PaaS 不同，在使用无服务器框架时，DevOps 团队可以免于担心更新，应用程序扩展、缩小，空闲成本以及复杂的构建和部署操作，核心功能及其逻辑的所有内容都由基础架构提供商处理。
- 无服务器技术并不关注用于开发，测试和部署它们的 DevOps 方法，这与通常对开发人员工作流程要求很严格的 PaaS 不同。
- 与 PaaS 上部署的应用程序不同，无服务器功能的启动延迟非常低。
- 与 PaaS 相比，无服务器框架功能有限，增加的简单性确实伴随着特征差异。
与在 PaaS 上运行相比，无服务器框架在 Kubernetes 上运行得更好。大多数 PaaS 技术因在几个领域（开发人员工作流程、架构和定价）过于严格而赢得赞誉，这使得它们不适合运行无服务器工作负载。用 Brendan Burns 的话说，第一代平台即服务（PaaS）正是为了让开发人员采用无服务器架构。麻烦的是，太多重叠的概念被混合到单片产品中。在大多数的第一代 PaaS 中，开发人员体验无服务器和定价模型都在一个不可分割的整体中混合。因此，想要采用无服务器，但可能不符合开发人员的特定要求（例如特定编程语言）或者想要为大型应用程序提供更具成本效益的定价模型的用户都会被迫放弃无服务器计算。 (原文）