Serverless 让我们的运维更轻松
一、介绍
Serverless，又叫无服务器。Serverless 强调的是一种架构思想和服务模型，让开发者无需关心基础设施（服务器等），而是专注到应用程序业务逻辑上。
无服务器方案中仍然有服务器，但它们已从应用开发中抽离了出来。云提供商负责置备、维护和扩展服务器基础架构等例行工作。开发人员可以简单地将代码打包到容器中进行部署。
部署之后，无服务器应用即可响应需求，并根据需要自动扩容。公有云提供商的无服务器产品通常通过一种事件驱动执行模型来按需计量。因此，当无服务器功能闲置时，不会产生费用。
本文作者：领创集团高级运维工程师 李铮
二、架构概述
无服务器与其他云计算模型的区别在于，它是由云提供商负责管理云基础架构和应用扩展。无服务器应用部署在容器中，这些容器在被调用时会自动按需启动。
在标准的基础架构即服务（IaaS）云计算模型中，用户需要预先购买容量单元；也就是说，您要先向公共云提供商支付始终可用的服务器组件的费用，才能运行您的应用。用户自行负责在需求高时扩展服务器容量，并在不再需要时缩减容量。即使在应用闲置不用期间，运行该应用所需的云基础架构也要保持就绪。
无服务器架构则与之相反，应用仅在需要时启动。有事件触发应用代码运行时，公共云提供商才会为这一代码分配资源。该代码执行结束后，用户便不再付费。除了成本与效率上的优势外，无服务器也能将开发人员从应用扩展和服务器置备相关的琐碎日常任务中解放出来。
使用无服务器时，管理操作系统和文件系统、安全补丁、负载平衡、容量管理、扩展、日志和监控等例行任务都由云服务提供商分担。
三、定义
Serverless 不如 IaaS 和 PaaS 那么好理解，因为它通常包含了两个领域 BaaS（Backend as a Service）和 FaaS（Function as a Service）。
3.1 BaaS
BaaS（Backend as a Service）后端即服务，一般是一个个的 API 调用后端或别人已经实现好的程序逻辑，比如身份验证服务 Auth0，这些 BaaS 通常会用来管理数据，还有很多公有云上提供的我们常用的开源软件的商用服务，比如亚马逊的 RDS 可以替代我们自己部署的 MySQL，还有各种其它数据库和存储服务。
3.2 FaaS
FaaS（Function as a Service）函数即服务，FaaS 是无服务器计算的一种形式，当前使用最广泛的是 AWS 的 Lambda。
现在当大家讨论 Serverless 的时候首先想到的就是 FaaS，有点浮夸了。FaaS 本质上是一种事件驱动的由消息触发的服务，FaaS 供应商一般会集成各种同步和异步的事件源，通过订阅这些事件源，可以突发或者定期的触发函数运行。
图 ：服务端软件的运行环境
传统的服务器端软件通常是部署到拥有操作系统的虚拟机或者容器中，一般需要长时间驻留在操作系统中运行，而 FaaS 是直接将程序部署到平台上即可，当有事件到来时触发执行，执行完了就可以卸载掉。
图：FaaS 应用架构
四、Serverless 架构的优点
今天大多数公司在开发应用程序并将其部署在服务器上的时候，无论是选择公有云还是私有的数据中心，都需要提前了解究竟需要多少台服务器、多大容量的存储和数据库的功能等。并需要部署运行应用程序和依赖的软件到基础设施之上。假设我们不想在这些细节上花费精力，是否有一种简单的架构模型能够满足我们这种想法？这个答案已经存在，这就是今天软件架构世界中新鲜但是很热门的一个话题——Serverless（无服务器）架构。
——AWS 费良宏
降低运营成本：
Serverless 是非常简单的外包解决方案。它可以让您委托服务提供商管理服务器、数据库和应用程序甚至逻辑，否则您就不得不自己来维护。由于这个服务使用者的数量会非常庞大，于是就会产生规模经济效应。在降低成本上包含了两个方面，即基础设施的成本和人员（运营/开发）的成本。
降低开发成本：
IaaS 和 PaaS 存在的前提是，服务器和操作系统管理可以商品化。Serverless 作为另一种服务的结果是整个应用程序组件被商品化。
扩展能力：
Serverless 架构一个显而易见的优点即“横向扩展是完全自动的、有弹性的、且由服务提供者所管理”。从基本的基础设施方面受益最大的好处是，您只需支付您所需要的计算能力。
更简单的管理：
Serverless 架构明显比其他架构更简单。更少的组件，就意味着您的管理开销会更少。
“绿色”的计算：
按照《福布斯》杂志的统计，在商业和企业数据中心的典型服务器仅提供 5%～15%的平均最大处理能力的输出。这无疑是一种资源的巨大浪费。随着 Serverless 架构的出现，让服务提供商提供我们的计算能力最大限度满足实时需求。这将使我们更有效地利用计算资源。
在上面我们提到了 Serverless 能带给我们的五点好处，FaaS 当然也包括了这些好处，并且减少从概念原型到实施的等待时间，比自己维护服务更省钱。
降低人力成本：
不需要再自己维护服务器，操心服务器的各种性能指标和资源利用率，而是关心应用程序本身的状态和逻辑。而且 serverless 应用本身的部署也十分容易，我们只要上传基本的代码，例如 Javascript 或 Python 的源代码的 zip 文件，以及基于 JVM 的语言的纯 JAR 文件。不需使用 Puppet、Chef、Ansible 或 Docker 来进行配置管理，降低了运维成本。同时，对于运维来说，也不再需要监控那些更底层的如磁盘使用量、CPU 使用率等底层和长期的指标信息，而是监控应用程序本身的度量，这将更加直观和有效。
在此看来有人可能会提出“NoOps”的说法，其实这是不存在的，只要有应用存在的一天就会有 Ops，只是人员的角色会有所转变，部署将变得更加自动化，监控将更加面向应用程序本身，更底层的运维依然需要专业的人员去做。
降低风险：
对于组件越多越复杂的系统，出故障的风险就越大。我们使用 BaaS 或 FaaS 将它们外包出去，让专业人员来处理这些故障，有时候比我们自己来修复更可靠，利用专业人员的知识来降低停机的风险，缩短故障修复的时间，让我们的系统稳定性更高。
减少资源开销：
我们在申请主机资源一般会评估一个峰值最大开销来申请资源，往往导致过度的配置，这意味着即使在主机闲置的状态下也要始终支付峰值容量的开销。对于某些应用来说这是不得已的做法，比如数据库这种很难扩展的应用，而对于普通应用这就显得不太合理了，虽然我们都觉得即使浪费了资源也比当峰值到来时应用程序因为资源不足而挂掉好。
解决这个问题最好的办法就是，不计划到底需要使用多少资源，而是根据实际需要来请求资源，当然前提必须是整个资源池是充足的（公有云显然更适合）。根据使用时间来付费，根据每次申请的计算资源来付费，让计费的粒度更小，将更有利于降低资源的开销。这是对应用程序本身的优化，例如让每次请求耗时更短，让每次消耗的资源更少将能够显著节省成本。
增加缩放的灵活性：
以 AWS Lambda 为例，当平台接收到第一个触发函数的事件时，它将启动一个容器来运行你的代码。如果此时收到了新的事件，而第一个容器仍在处理上一个事件，平台将启动第二个代码实例来处理第二个事件。AWS Lambda 的这种自动的零管理水平缩放，将持续到有足够的代码实例来处理所有的工作负载。
但是，AWS 仍然只会向您收取代码的执行时间，无论它需要启动多少个容器实例要满足你的负载请求。例如，假设所有事件的总执行时间是相同的，在一个容器中按顺序调用 Lambda 100 次与在 100 个不同容器中同时调用 100 次 Lambda 的成本是 一样的。当然 AWS Lambda 也不会无限制的扩展实例个数，AWS 是有默认限制的，默认执行 Lambda 函数最大并发数是 1000。
缩短创新周期：
小团队的开发人员可以在几天之内从头开始开发应用程序并部署到生产。使用短而简单的函数和事件来粘合强大的驱动数据存储和服务的 API。完成的应用程序具有高度可用性和可扩展性，利用率高，成本低，部署速度快。
以 docker 为代表的容器技术仅仅是缩短了应用程序的迭代周期，而 serverless 技术是直接缩短了创新周期，从概念到最小可行性部署的时间，让初级开发人员也能在很短的时间内完成以前通常要经验丰富的工程师才能完成的项目。
五、Serverless 架构的缺点
我们知道没有十全十美的技术，在说了 serverless 的那么多优势之后，我们再来探讨以下 serverless 的劣势，或者说局限性和适用场景。
状态管理
要想实现自由的缩放，无状态是必须的，而对于有状态的服务，使用 serverless 这就丧失了灵活性，有状态服务需要与存储交互就不可避免的增加了延迟和复杂性。
延迟
应用程序中不同组件的访问延迟是一个大问题，我们可以通过使用专有的网络协议、RPC 调用、数据格式来优化，或者是将实例放在同一个机架内或同一个主机实例上来优化以减少延迟。
而 serverless 应用程序是高度分布式、低耦合的，这就意味着延迟将始终是一个问题，单纯使用 serverless 的应用程序是不太现实的。
本地测试
Serverless 应用的本地测试困难是一个很棘手的问题。虽然可以在测试环境下使用各种数据库和消息队列来模拟生产环境，但是对于无服务应用的集成或者端到端测试尤其困难，很难在本地模拟应用程序的各种连接，并与性能和缩放的特性结合起来测试，并且 serverless 应用本身也是分布式的，简单的将无数的 FaaS 和 BaaS 组件粘合起来也是有挑战性的。
六、AWS Fargate
适用于容器的无服务器计算
Amazon Fargate 是一种为容器按需提供大小合适的计算容量的技术。使用 Amazon Fargate，您不必再自己预置、配置或扩展虚拟机组即可运行容器。您无需再选择服务器类型、确定扩展节点组的时间和优化集群打包。您可以控制要在 Fargate 上启动的 Pod，以及它们如何利用 Fargate 配置文件运行。Fargate 配置文件被定义为 Amazon EKS 集群的一部分。
Amazon EKS 使用由 Amazon 构建的控制器（使用 Kubernetes 提供的上游可扩展模型）将 Kubernetes 与 Amazon Fargate 集成。这些控制器作为 Amazon EKS 托管 Kubernetes 控制层面的一部分运行，负责将本机 Kubernetes Pod 安排到 Fargate 上。除了若干转换和验证准入控制器外，Fargate 控制器还包括一个与默认 Kubernetes 调度器一起运行的新调度器。当您启动满足 Fargate 上的运行条件的 Pod 时，集群中运行的 Fargate 控制器会识别、更新 Pod 并将其安排到 Fargate 上。
特点：
部署和管理应用程序而非基础设施。Fargate 消除了扩缩、修补、保护和管理服务器的运营开销。
通过与 Amazon CloudWatch Container Insights 等 AWS 服务的内置集成来监控您的应用程序。使用第三方工具收集指标和日志。
通过设计隔离工作负载来提高安全性。Amazon ECS 任务和 Amazon EKS Pod 在它们自己的专用运行时环境中运行。
只需按实际使用量付费。Fargate 扩展计算以密切匹配您指定的资源需求。借助 Fargate，您无需超额预置并为额外的服务器付费。
工作原理：
AWS Fargate 是一种无服务器、随用随付的计算引擎，可让您专注于构建应用程序，而无需管理服务器。AWS Fargate 与 Amazon Elastic Container Service (ECS) 和 Amazon Elastic Kubernetes Service (EKS) 兼容。
七、案例分享
使用 Amazon EKS 在 Amazon Fargate 上运行 Kubernetes Pod
7.1 创建 Fargate Pod 执行角色
当集群在 Amazon Fargate 上创建容器组时，在 Fargate 基础设施上运行的组件必须代表您调用 Amazon API。这是为了他们可以执行诸如从 Amazon ECR 中拉取容器镜像或将日志路由到其他 Amazon 服务的操作。Amazon EKS Pod 执行角色提供执行此操作的 IAM 权限。
创建 Fargate 配置文件时，必须指定要用于 Pod 的 Pod 执行角色。此角色将被添加到集群的 Kubernetes 基于角色的访问控制 (RBAC) 以进行授权。这允许在 Fargate 基础设施上运行的kubelet注册到您的 Amazon EKS 集群，以便它可以作为节点显示在您的集群中。
AWS 默认包含了AmazonEKSFargatePodExecutionRolePolicy角色，可以直接使用。
7.2 集群创建 Fargate 配置文件
必须先定义一个 Fargate 配置文件，以指定 Pod 在启动时哪些 Pod 应该使用 Fargate，然后才能安排在集群中的 Fargate 上运行的 Pod。
7.3 Fargate Pod 配置
使用 Kubernetes，您可以定义请求、最低 vCPU 量以及分配给 Pod 中每个容器的内存资源。Pod 由 Kubernetes 安排，以确保至少每个 Pod 的请求资源可用于计算资源。
在 Fargate 上安排 Pod 后，Pod 规格中的 vCPU 和内存预留将确定为 Pod 配置的 CPU 和内存量。
超出所有 Init 容器的最大请求用于确定 Init 请求 vCPU 和内存要求。
将所有长时间运行的容器的请求相加来确定长时间运行的请求的 vCPU 和内存要求。
然后为要用于 Pod 的 vCPU 和内存请求选择上述两个值中较大的值。
Fargate 会为所需 Kubernetes 组件（
kubelet、kube-proxy和containerd）的每个 Pod 的内存预留增加 256 MB。
Fargate 向上舍入到下面显示的最接近 vCPU 与内存请求总和的计算配置，以确保 Pod 始终拥有运行所需的资源。
如果未指定 vCPU 和内存组合，则使用最小的可用组合（.25 vCPU 和 0.5 GB 内存）。
下表显示了 Fargate 上运行的 Pod 可以使用的 vCPU 和内存组合。
为 Kubernetes 组件保留的额外内存可能会导致 Fargate 任务的 vCPUs 数量超过请求预置的 vCPU 数量。例如，由于没有具有 1 个 vCPU 和 9 GB 内存的任务可用，因此如果请求内容为 1 个 vCPU 和 8 GB 内存，则会为其内存请求增加 256 MB，并会为 Fargate 任务预置 2 个 vCPU 和 9 GB 内存。
Fargate 存储
预置后，Fargate 上运行的每个 Pod 将接收 20 GB 的容器镜像层存储。Pod 存储是短暂存储。Pod 停止后，该存储将被删除。对于 2020 年 5 月 28 日或之后在 Fargate 上启动的新 Pod，预设情况下已启用短暂存储卷加密。使用 Amazon Fargate 托管密钥通过 AES-256 加密算法对短暂 Pod 存储进行加密。
7.4 启动 Fargate Pod
Pod 配置文件
只有 namespace 和 label 与 fargate 配置文件内容一致时，才会调度使用 fargate 启动 pod 容器。
每个 fargate pod 会单独创建一个 node 节点，所以 fargate pod 很多后，你会看到相应数量的 fargate node 节点。
八、Serverless 之歌
关于领创集团（Advance Intelligence Group）
领创集团成立于 2016 年，致力于通过科技创新的本地化应用，改造和重塑金融和零售行业，以多元化的业务布局打造一个服务于消费者、企业和商户的生态圈。集团旗下包含企业业务和消费者业务两大板块，企业业务包含 ADVANCE.AI 和 Ginee，分别为银行、金融、金融科技、零售和电商行业客户提供基于 AI 技术的数字身份验证、风险管理产品和全渠道电商服务解决方案；消费者业务 Atome Financial 包括亚洲领先的先享后付平台 Atome 和数字金融服务。2021 年 9 月，领创集团宣布完成超 4 亿美元 D 轮融资，融资完成后领创集团估值已超 20 亿美元，成为新加坡最大的独立科技创业公司之一。
往期回顾 BREAK AWAY
▼ 如果觉得这篇内容对你有所帮助，有所启发，欢迎点赞收藏：
1、点赞、关注领创集团，获取最新技术分享和公司动态。
2、关注我们的公众号 & 知乎号「领创集团 Advance Group」或访问官方网站，了解更多企业动态。
版权声明: 本文为 InfoQ 作者【领创集团Advance Intelligence Group】的原创文章。
原文链接:【http://xie.infoq.cn/article/33e6366ddd1c7389d96e39af1】。文章转载请联系作者。
智慧领创美好生活 2021.08.12 加入
AI技术驱动的科技集团，致力于以技术赋能为核心，通过科技创新的本地化应用，改造和重塑金融和零售行业，以多元化的业务布局打造一个服务于消费者、企业和商户的生态圈，带来个性化、陪伴式的产品服务和优质体验。
评论