无服务器架构使企业专注解决业务本身问题

发布于: Nov 30, 2022

【概要】无服务器 (Serverless) 架构替我们屏蔽了服务器的管理，当不再需要维护服务器，才真正开始回归问题本质，专注解决业务本身的问题。Serverless 可使开发人员专注构建和运行应用，而不需要管理服务器。

无服务器解放运维

容器化以及自动化的架构演进，使得业务的发展更加敏捷可靠。然而这一切复杂的工作都是因为有服务器。解决的都是如果没有服务器就不会存在的问题。

无服务器 (Serverless) 架构替我们屏蔽了服务器的管理，当不再需要维护服务器，才真正开始回归问题本质，专注解决业务本身的问题。Serverless 可使开发人员专注构建和运行应用，而不需要管理服务器。不过，实际上 Serverless 方案中仍然有服务器的，只是是由云厂商负责管理云基础设施架构和应用扩展。

Amazon Web Services 提供了两种 Serverless 计算服务，一种是 EKS 和 ECS 平台的 Fargate 容器引擎，另一种是 Lambda 平台。

Fargate 是一种适用于容器的无服务器计算引擎。通过使用 Fargate，不需要再预置或者管理服务器，只需为运行的容器付费即可，而且可以非常方便地实现容器的自动扩缩容，不需要关心计算节点的扩缩容。而且在 EKS 和 ECS 平台中使用的 CI/CD 流程以及监控流程都可以继续在 Fargate 平台中使用。

而 Lambda 相比 Fargate 提供了更深一层的托管，它将容器环境也托管起来（当然现在也支持了容器在 Lambda 平台运行）。客户只需构建代码即可，应用会自动部署到 Lambda 管理的容器中，这些容器在被调用时会自动按需启动。而且在 CI/CD 流程方面有不同于容器环境的实现方式。我们通常所说的 Serverless 应用指的就是基于 Lambda 平台构建的应用。

Serverless 应用实现了真正的资源按需配置，自动弹性伸缩，实现更快速的部署流水线，以及更高的系统安全性。而且可以使用平台支持的任意语言，不需要限制开发人员使用特定的编程语言。与传统服务端应用常驻内存的特点不同，Serverless 应用不需要长期运行，而是通过事件触发，执行之后即可释放资源。

因此，在讨论 Serverless 应用之前，不得不提一下事件驱动模型。事件驱动的体系结构使用事件在解耦的服务之间进行触发和通信。事件是状态的更新，例如放置在电子商务网站上的购物车中的项目，或者 S3 文件上传事件等。事件驱动的体系结构具有三个关键组件：事件生产者、事件路由器和事件消费者。生产者服务和消费者服务是分离的，这使得它们可以独立扩展，更新和部署。

几种常见的事件驱动场景有：

Amazon Web Services 平台的事件，实例重启、S3 上传文件、CloudTrail 记录的事件等，都可以作为事件源，触发 Lambda 或者 System Manager Automation 对其进行自动处理。前面的容器集群的弹性伸缩配置也是事件驱动的一种情况。
业务逻辑，比如用户的登录、充值、提现等操作，都可以作为事件源通过触发 Lambda 进行处理，来实现完整的业务逻辑。
定时任务，不需要长期运行在服务器中，定时触发执行即可。

在 Amazon Web Services 中使用 SAM (Serverless Application Model) 来管理无服务器应用，Amazon SAM 无服务器应用程序模型是 Lambda 函数、事件源和共同执行任务的其他资源的组合。需要注意的是，无服务器应用程序不仅仅是 Lambda，还包括其他资源，如 API、数据库和 SQS、SNS、事件源映射关系等。

Amazon SAM 包含两个部分：

Amazon SAM 模板规范，定义构成无服务器应用的相关资源，是 Amazon CloudFormation 模板的扩展。
命令行，可以结合 Amazon CodePipline 等 CI/CD 工具来部署 CI/CD 流水线，并且在本地开发环境做测试和 debug。

另外，还可以把无服务器应用程序部署到 Serverless Application Repository（Amazon SAR），即无服务器应用仓库。它类似于容器镜像仓库，我们可以把无服务器应用发布到公共或者私有的仓库中。通过应用仓库可以方便地进行无服务器应用程序的分发，使开发人员和企业轻松地在云中快速查找、部署和发布无服务器应用程序。

对于无服务器应用的监控，我们使用 X-Ray 服务。X-Ray 可以跟踪通过整个应用程序的用户请求，进而准确发现应用程序造成性能问题的位置和原因。最后，还可以非常方便地使用 CloudWatch Logs 来收集业务日志。

下面用简单的例子来说明如何实现 Serverless 的 CI/CD 流程。如下图所示，当风控模块接收到前端请求的时候，把消息统一推送到 Event Bridge，然后通过不同的行为规则触发相应的 Lambda 进行处理，处理之后把结果写到 Serverless 的数据库中。每个方框里的相关资源定义为一个 Serverless 应用一起部署。

我们来看一下这个 Serverless 应用是如何部署的。

左上角是代码目录结构，cmd 文件夹里边是业务代码，最终会在构建之后被发布到 Lambda 中，同级目录下的两个配置文件是发布过程用到的配置文件。其中 template.yml 是模板文件，定义了 Serverless 应用所有的相关资源。samconfig.toml 是 SAM 命令用到的配置文件。

有了配置文件和模板文件，就可以通过 sam build，sam deploy 来完成部署，两个命令会自动去找到模板文件和配置文件，并完成如下操作：

构建代码，并且把构建好的代码上传到 S3 桶；
根据模板定义创建 Lambda、SQS 等相关资源，同时把代码部署到 Lambda。

Serverless 的应用架构给我们带来了更加快速方便的应用部署方式，业务无论大小都不需要提前预估容量，也无须提前申请服务器。而且，因为资源模板和业务代码统一管理，开发人员可以自助部署以及维护服务，不需要运维参与。通过把基础设施的配置和变更自动化和流水线化，这天然就是基础设施即代码的管理方式。当然容器环境也可以使用 Cloudformation 模板来做基础设施即代码管理，但是远不如 Serverless 应用这么自然和简单。

上面通过一个简单的例子对 Serverless 做了介绍，在实际场景中可以结合所有计算、集成和数据存储三个层级的无服务器服务来构建丰富的适用于各种场景的无服务器应用程序。

例如，通过 Lambda、Amazon API Gateway 来实现后端逻辑以验证和处理 API 请求，使用 Amazon DynamoDB 作为数据库来实现通用的事件驱动的 Web 应用程序，从而可自动扩展和收缩，并跨多个数据中心中运行，而无须在可扩展性、备份或多数据中心冗余方面执行任何管理工作。