无服务器架构下的运维实践

前言

在介绍运维之前，大家先来快速了解一下无服务器(serverless)的概念。由于笔者的实战经验是在AWS平台上，本文中出现的无服务器均指使用AWS Lambda构建的serverless应用。Serverless的特点是用户无需预配置或管理服务器，只需要部署功能代码，服务会在需要的时候执行代码并自动伸缩，从每天几个请求到每秒数千个请求，轻松地实现FaaS(Function as a Service)。如下图所示：

(图片来自网络)

在传统的应用中，开发团队除了需要编写功能代码，还要监控实时负载，并相应地对应用进行伸缩，还要处理一些因非功能性故障导致的停机(硬盘、内存等)。而无服务器架构则将开发团队从服务器维护的工作中解放出来，继而能更专注在功能代码上(图中的Function)。在实际的项目里，开发者只需将功能代码打包上传到AWS Lambda，再进行少量配置(环境变量，触发条件，内存，超时时间等)即可将应用/服务上线。

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

日志

默认情况下，应用运行时产生的日志会保存在应用服务器本机，在需要查看日志的时候，需要运维人员远程登录到这台服务器获取日志信息。这种方式操作起来稍显繁琐，而且当应用服务器的数量增多后，由于需要先找出产生错误信息的那台服务器，会严重降低查找日志的效率。

一种解决办法是ELK(ElasticSearch, Logstash, Kibana)，这三个开源工具各司其职，Logstash负责日志的推送和转换，ElasticSearch作为数据库与搜索引擎，Kibana作为图形界面。好处是搭建容易，良好的伸缩性，以及免费。但带来的额外成本是，独立出来的日志服务也需要做好全方位的监控(应用状态，硬盘，网络等)，避免因为基础服务的问题导致系统全面故障。

AWS无服务器架构中的日志是一个开箱即用的服务，所有日志自动采集到AWS CloudWatch Logs中，只要根据服务名称找到对应的日志组，即可进行查询搜索，不需要任何配置，也没有任何维护成本。

指标

通常情况下，运维工作会包含采集线上应用的运行指标，来反映应用的健康状况，故障率，性能，访问量，访问频率等。这里以一个使用Spring Boot构建的API服务来举例，Spring Boot中的Actuator扮演了采集指标的角色。默认配置下，对于每个API，Actuator会自动采集以下几个指标：

uri，例如/api/person/{id}

method，例如GET或POST

status，例如200或500

当然我们可以通过实现一些接口来扩展/自定义采集指标，这里就不展开了。有了指标数据，还需要对应的报表或仪表盘工具，以便更好地查询和展示，可以选择像Prometheus，Grafana这样的工具。

那么AWS无服务器架构是否提供了类似的指标采集呢?答案是肯定的，AWS CloudWatch Metrics自动采集了Lambda function的以下四个指标：

Invocations(实际调用量)

Errors

Duration(执行时间)

Throttles(超过并行限制而被阻止的调用的数量)

Invocations和Errors取一段时间的总数，结合二者可以得出应用的错误率，如下

Duration则通过取平均数来反映一段时间的性能表现，在笔者的项目中Lambda function的耗时主要集中在SQL的查询上，这个数字可以相应地反映技术人员对查询优化的效果。当然，在实际情况中，这些检验都可以在预发布环境下进行，这个例子只是为了方便理解。

在笔者目前的项目中，Throttle并未被使用到，默认的并发限制是1000/秒，而用量最大的Lambda function的调用频率也不过每分钟150次，距离超限差得很远，不过这一数据对于并发高的应用有很重要的意义。

除了开箱即用的几个指标以外，还可以结合CloudWatch metrics的API，在相应的功能代码中埋点，定制化采集指标。例如，对于一个Lambda function，代码里三个子task，默认提供的Duration只能反映总体的运行效率，如果需要统计每个task的消耗，就需要用到AWS CloudWatch metrics API。

监控&报警