前言

在介绍运维之前，我们先来快速了解一下 () 的概念。由于笔者的实战经验是在AWS平台上，所以本文中的指的々是使用AWS搭建的应用。特点是用户无需预先配置或管理服务器，只需要部署功能代码，服务会在需要时执行代码并自动伸缩，从每天几个请◤求到每秒几千个请求，轻松实现FaaS（作为一个）。如下所示：

（图片来■自网络）

在传统的◢应用程序中，除了编写功能代码外，开发团队还需要监控实时负载，相应地扩展应用程序，并处理由ㄨ于非功能故障（硬盘、内存等）导致的一些停机时间。另一方面，无服务器架构将开发团队从服务器维护工作中解放出来，然后可以更多地专注于功能代码（如图）。在实际项』目中№№，开发者只需将功能代码打包上传到AWS，然〇后进行少量配置（环境变量、触发条件、内存、超时等），即可使应用/服务上线。

这些是无服务器架构的基本概念。接下来，笔者将从日志、指标、监控告警、容灾四个维度来介绍架构下的运维。

日志

默认情况→下，应用程序运行时产生的日志会保存在应用服务器上。当需要查看日志时，运维人员需要远程登录服务器获取日志信息。这种方式操作起↓来略显繁琐，而且当应用服务器数量增加时，查找日志的效率会▲严重降低，因为需要先找到产生错误信息的服务器。

一种解决方案是ELK(, , )，这三个开源工具执行各自的功能，负责日志的推送和转换，作为数『据库和搜索引擎，作为图形界面。好处是易于构建、良好的可扩展性和免费。但额外的代价是独立的日志服务还需要做全方位的监◥控（应用状态、硬盘、网络等），避免因基础服务出现问题而导致系统整♀体故障。

AWS 无服务器架构中的日志是一种开箱即用的服务。所有日志都会自动收集到 AWS 日志中。只要根据服务名称找到对应的日志组，就可以查询搜∮索，无需任何配置或维护。成本。

指数

通常，运维工作会包括收集在线应用的运行指标，以反映应用的健康状态、故障率、性能、访问量、访问频ㄨ率等。这里举一个用Boot构建的API服务的例∮子，起到收集指标的作用。默认情况→下，对于每个 API，会自动收集以下指标：

当然，我们可以通过实现一些接口来扩展/自定义集◥合指标，这里不再展开。有了指标数据，还需要相应的报表或仪表盘工具服务器运维，才能⊙更好的查询和展示。您可以选择像 .

那么 AWS 无服务器架构是否╳提供类似的指标收集？答案是肯定的，AWS 会自动收集以下四个指标：

并取总时间，将两者结合得到应用程序的错误率，如下

平均值用于反映一段时间内的表现。在笔者的项目中，耗时主要集中在SQL查询上。这个数字可以相应地反映技术人员对查询优化的＠ 效果。当然，在实践中，这些检查可以在预发布环境中进行，这个例子只是为了便于∏理解。

在作者目前的项目中，并没有使用过。默认并发限制为 1000 次/秒，最常用的调用频率仅为▽每分钟 150 次，远未超出限制。但是，这个数据很重要，对于并发高的应用程序来说是很重要的。

除了几个开箱即用的指标外，您还可︻以结合API在相应的功能代码中埋点，自定义指∑标的集合。比如代码中的一、三个子任务服务器运维，默认提供的只能反映整体的运行效率。如果需要统▲计每个任务的消耗，需要使用AWS API。

监控和报警

监控的意义在于全面了解应用程序的资源使用、性能和运行情况。这些数据可以用来帮助团『队及时进▂行调整，以确保应用程序的顺利运行。这↑通常包括 CPU 使用率、数据传输、磁盘使用率等。当突发事件◥导致系统不可用时，团队的响应速度往往取决于监控和报警的及时性、全面性和准々确性。如果能够根据历史数据的分析合理配置监控系统，团队甚至可以预测不好的事情会发生，提前防备，未雨绸缪。

同上，这里以一个Boot应用为例，在◥上一节指标数据的收集中提到过。其实除了记录上面提到的指标外，还可以用来采集监☆控数据。这里我们只需要设置一个Boot Admin应用，将Boot Admin配置添加到需要监控的应用中，监控数据就会通过暴露的API传递给Boot Admin。

报警功能一◥般需要根据实际情况自行实现。在 Boot Admin 中实现了 Slack 和 Slack 等第三方工具的集成。如果你只需要一个简单的邮件提醒，并且实现不复杂，这里就不展开了。

随着云︼基础设施的普及，上面提到的监控报警早已是各个平台的⌒标准配置。轮到开发人员担心如何实现和维护它。运营团队可以更加专注于配置优化。去工作。

AWS 默认提供非常完整的监控数据，也允许自定义监控。通过在创建的指标中添加一系列√重要指标，应用程序的运行状态可以一目了然。

如前所述，在发生错误或性能低下时，根据某些关键指标的变化发送警告通知是非常◢必要的。笔者项目的做法是使用AWS和AWS SNS提供的告警通知功★能。您只需选择指标，然后设置触发阈值和检查间隔。AWS SNS 支持 HTTP、SMS、Email 和其他订阅方式。下图显示了如何配置在过去 5 分钟内发ξ生超过 5 次特定错误时发送通知。

灾难备份与恢复

在系统镜像、构建工卐具和容器技术越来越普及的今天，灾难备份的意义在很大程度上是为了有效保护ζ　重要数据。通常的做法是设置一些周期性的任务，将数据传输到异地容灾中心，以物理抵御不可抗力的灾难。如果数据量太大，网络Ψ传输效率跟不上，可以参考AWS用卡车拉数据的方案。

灾难备份的实际需求在笔者有限的经验中并没有发生，但如果不提前计↘划，一旦发生，后果将难以想象。作者项目中使用▓的AWS RDS默认开启自动备份，周期为7天。可以手动调整此配置或将其写入脚本以构建基础架构。在发生灾难时，仅仅备份数据是不「够的，您还需要一个能够快速重建应用程序运行时的基础架构。笔者所在的团队（以下简←称团队）使用AWS和，分别对数据库、网络等基础设施进行重建，在重建数▅据库时，通过持续集成管道，

总结

笔者所在的团队有一个10人左右的配置，采用结对编程的方式，3对结对，包括web端、业务层、数据层。从产品原型ζ确认到首次发布（MVP）需要30天，每周至少发布一次新版本。故事的平均交付时间（周期时间，从需求确认到发布）为 8 天。这∞个速度可能算不上快，但是如果没有运维侧架构〖提供的支持，我们要在交付速度上实现更高的突破ω　会困难很多。

最后，让我们谈谈成本。俗话说，谈技术不商业化是流氓。大多数人看到※一个功能强大且好用的工具时，都会下意识地觉得成本会非常大。事实上，情况并非如』此。我们粗略计算了一下，使用了双核 CPU、8G 内存的 M4 服务器，费用为每月 72 美元。dev、 和 prod 三个∏环境都使用相同的配置，每月 216 美元。事实上，每月的开■销包括大约 20 美元的所有环境。应该注意的︾是，计费是基于使用情况的。我们的 API 访问量约为每月 150 万次。可以预见，当访问量达到一定数量时①，开销将与使用服务器的方案相同甚至更大，但在数量∏较少时优势明显。

得益于强大的 AWS 生态，使用它构建的 应用可以以极低的价格获得完整的运维功能和体∮验，几乎不需要配置♂。与使用开源工具构建的方式相比，研发团队可以从繁琐的运维工作——尤其是基础工程建设——中解脱〓出来，更加专注于产品本身，大大提高了软件交付速度△、可用性、可靠性和可扩展性也得到了相当ぷ的保证。代价是更高的迁移成本，部分功能的非定制化可能成为瓶颈，底层实现原理的屏蔽也可能对开发者的学习和成长〓产生影响。

文/王智