前言在介绍运维之前，我们先快速了解下Serverless的概念。由于笔者的实战经验是在AWS平台上进行的，所以本文中的serverless指的是使用AWSLambda构建的serverless应用。Serverless的特点是用户不需要预先配置或管理服务器，只需要部署功能代码，服务会执行代码并在需要时自动扩展，从每天几个请求到每天数千个请求。第二，轻松实现FaaS（FunctionasaService）。如下图所示：（图片来自网络）在传统应用中，开发团队除了编写功能代码外，还需要监控实时负载，对应用进行相应的缩放，并处理非正常情况导致的宕机。功能故障（硬盘、内存等）。Serverless架构将开发团队从维护服务器的工作中解放出来，进而可以更专注于功能代码（图中的Function）。在实际项目中，开发者只需要将功能代码打包上传到AWSLambda，然后进行少量配置（环境变量、触发条件、内存、超时等）即可启动应用/服务。以上就是Serverless架构的基本概念。接下来笔者将从日志、指标、监控告警、容灾四个维度来介绍Serverless架构下的运维。日志默认情况下，应用运行时产生的日志会保存在应用服务器上。运维人员在查看日志时，需要远程登录服务器获取日志信息。这种方法操作起来有些繁琐，而且当应用服务器数量增加时，查找日志的效率会严重降低，因为需要先找出产生错误信息的服务器。一种解决方案是ELK（ElasticSearch、Logstash、Kibana）。这三个开源工具各司其职。Logstash负责日志推送和转换，ElasticSearch用作数据库和搜索引擎，Kibana用作图形界面。优点是易于搭建，扩展性好，免费。但是，额外的代价是独立的日志服务也需要得到全面的监控（应用状态、硬盘、网络等），避免因为基础服务问题导致系统全面崩溃。AWS无服务器架构中的日志是一种开箱即用的服务。所有日志都会自动收集到AWSCloudWatchLogs中。只要根据服务名称找到对应的日志组，就可以查询搜索，无需任何配置，也无需任何维护成本。指标正常情况下，运维工作会收集在线应用运行指标，反映应用的健康状况、故障率、性能、访问量、访问频率等。下面是一个使用SpringBoot构建的API服务的示例。SpringBoot中的Actuator起到收集指标的作用。默认配置下，对于每一个API，Actuator会自动收集以下指标：uri，比如/api/person/{id}方法，比如GET或者POST状态，比如200或者500当然我们可以实现一些接口扩展/自定义采集指标，这里不再展开。有了指标数据，就需要相应的报表或仪表盘工具来更好的查询和展示。可以选择Prometheus、Grafana等工具。那么AWSserverless架构是否提供类似的指标收集？答案是肯定的，AWSCloudWatchMetrics自动收集Lambda函数的以下四个指标：Invocations（实际调用量）ErrorsDuration（执行时间）Throttles（超过并行限制被阻塞的调用数）Invocations和Errors取总数一段时间，结合两者就可以得到应用程序的错误率。下面的Duration通过取平均值来反映一段时间内的表现。在笔者的项目中，Lambda函数的耗时主要集中在SQL查询上，这个数字可以相应地反映技术人员对查询优化的效果。当然，在实际情况下，这些测试可以在预发布环境中进行，这个例子只是为了方便理解。在笔者目前的项目中，并没有使用Throttle。默认的并发限制是1000/s，最常用的Lambda函数的调用频率只有150次/分钟，远远没有超过限制。这个数据对于高并发的应用来说非常重要。除了开箱即用的几个指标，您还可以结合CloudWatch指标API，在相应的功能代码中嵌入点，自定义采集指标。比如一个Lambda函数，代码中有3个子任务，默认提供的Duration只能体现整体运行效率。如果需要统计每个任务的消耗，需要使用AWSCloudWatchmetricsAPI。监控告警监控的意义在于全面了解应用程序的资源使用情况、性能和运行情况。这些数据可以用来帮助团队及时做出调整，保证应用的顺利运行。这通常包括CPU使用率、数据传输、磁盘使用率等。当出现意外情况导致系统不可用时，团队的响应速度往往取决于监控和告警的及时性、全面性和准确性。如果能够根据历史数据的分析合理配置监控系统，团队甚至可以预知坏事的发生，提前未雨绸缪，未雨绸缪。同上，这里仍然以一个SpringBoot应用为例。上一节指标数据收集中提到了Actuator。其实Actuator除了记录上面提到的指标外，还可以用来收集监控数据。这里我们只需要搭建一个SpringBootAdmin应用，在需要监控的应用中添加SpringBootAdmin客户端配置，监控数据就会通过Actuator暴露的API传递给SpringBootAdmin。告警功能一般需要根据实际情况自行实现。Pagerduty、Slack等第三方工具的集成在SpringBootAdmin中实现。如果只需要简单的邮件提醒，实现起来并不复杂，这里就不展开了。随着云上基础设施的普及，上面提到的监控告警早已是各个平台的标配，如何实现和维护已经不是开发者操心的事情了。运营团队可以更专注于配置优化。去工作。AWS默认提供非常完整的监控数据，也允许自定义监控仪表盘。通过在创建的仪表盘中添加一系列重要的指标，应用的运行状态一目了然。如前所述，当出现错误或性能下降时，需要根据某些关键指标的变化来发送警告通知。笔者的项目做法是使用AWSCloudWatch和AWSSNS提供的告警通知功能。您只需要先选择指标，然后设置触发阈值和检查间隔。AWSSNS支持HTTP、SMS、Email等多种订阅方式。下图显示了如何设置在过去5分钟内Lambda出现超过5个错误时发送通知。容灾备份与恢复在系统镜像、构建工具、容器技术越来越普及的今天，容灾备份的意义很大程度上在于有效保护重要数据。通常的做法是设置一些定时任务，将数据传输到异地的灾备中心，以物理抵御不可抗拒的灾难。如果数据量太大，网络传输效率跟不上，可以参考AWS用卡车拉数据的方案。真正需要使用容灾备份的情况在笔者有限的经验中还没有发生过，但如果不注意防范，后果将不堪设想。笔者项目中使用的AWSRDS默认开启了自动备份，周期为7天。此配置可以手动调整或写入构建基础设施的脚本。如果灾难真的发生了，仅仅有数据备份是不够的，还需要能够在应用运行时快速重建基础设施。笔者团队（以下简称团队）分别使用AWSCloudFormation和Serverless框架。CloudFormation用于重建数据库和网络等基础设施，Serverless框架用于重建Lambda函数。重建数据库时，通过持续集成流水线，将环境中最新的数据备份快照的Id作为变量传入，15分钟内即可重建出一个生产环境。总结一下，作者团队10人左右，采用结对编程方式，3对，包括web端、业务层、数据层。从确定产品原型到首次上线（MVP）需要30天，每周至少发布一次新版本。故事的平均交付时间（周期时间，从需求确定到发布）为8天。这个速度可能算不上快，但是如果没有serverless架构在运维端提供的支持，我们想要在交付速度上有更高的突破会困难很多。***让我们谈谈成本。俗话说，不谈商业化只谈技术，就是耍流氓。大多数人看到一个功能强大且易于使用的工具，都会下意识地觉得成本会很高。事实上，情况并非如此。我们粗略算了一下，选择了双核CPU、8G内存的M4服务器。费用是每月72。dev、staging和prod环境都使用相同的配置，即每月216。事实上，包括所有环境在内的Lambda每月费用约为20。需要注意的是，Lambda是按使用量计费的。我们的API访问量约为每月150万次。可以预见，当访问量达到一定数量时，Lambda的成本将等于甚至大于使用服务器的方案，但在访问量较小时优势明显。得益于强大的AWS生态，使用Lambda构建的Serverless应用程序可以以极低的价格获得完整的运维功能和体验，几乎不需要配置。与使用开源工具构建的方式相比，研发团队可以从繁琐的运维工作——尤其是基础工程建设——中解放出来，更专注于产品本身，大大提高软件交付速度、易用性、可靠性并且可扩展性也相当有保证。换来的代价是更高的迁移成本，某些功能的非定制化可能成为瓶颈，底层实现原理的屏蔽也可能对开发者的学习和成长造成影响。【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
