无服务器架构的基本概念及运维
前言
在介绍运维之前，大家先来快速了解一下无服务器(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。
监控&报警
监控的意义在于全面了解应用的资源使用率，性能和运行情况，这些数据可以用来帮助团队及时作出调整，保证应用程序顺畅运行。这通常包括cpu使用率，数据传输，磁盘使用等。在突发状况导致系统不可用的时候，团队的响应速度，往往取决于监控和报警的及时性，全面性和准确度。如果能在对历史数据的分析之上对监控系统进行合理的配置，团队甚至能预测不好的事情将要发生，提前做好防范，未雨绸缪。
同上，这里还是以一个spring boot应用为例，在上一小节指标数据的采集中提到过actuator，事实上actuator除了可以记录上面提到的指标，还可以用来收集监控数据。这里我们只需要设置一个spring boot admin应用，给需要进行监控的应用加上spring boot admin client配置，监控数据就会通过actuator暴露的api传递给spring boot admin。
报警功能一般则要根据实际情况自行实现。spring boot admin中实现了对pagerduty，slack等第三方工具的集成，如果只是需要简单的邮件提醒，实现起来也不复杂，这里就不展开了。
随着云上基础设施的普及，上面提到的监控和报警早已是各个平台的标准配置，根本轮不到开发者去操心如何实现及维护，运营团队可以把更多的精力放在配置优化的工作中去。
aws默认提供了非常完备的监控数据，也允许自定义监控dashboard，通过把一系列重要的指标添加到创建好的dashboard中，应用的运行状况一目了然。
前面已经提到过，在出现错误，或性能底下时，根据某些关键指标的变动情况发送警告通知非常必要。笔者所在的项目的做法是使用aws cloudwatch和aws sns提供的告警通知功能，只需要先选择指标然后设定触发阈值和检查间隔时间即可，aws sns支持http、sms、email等多种订阅方式。下图展示了如何设定当某个lambda在过去5分钟内发生了5次以上错误的时候发送通知。
灾难备份&恢复
在系统镜像，构建工具还有容器技术越来越普及的今天，灾难备份的意义很大程度上是为了有效保护重要数据。通常的做法是设定一些定期任务，将数据传输到远端的灾备中心，从物理上抵御不可抗灾难。如果数据量过大，出现网络传输效率跟不上的情况，可以参考aws用卡车拉数据的解决办法。
真正需要用到灾难备份的情况在笔者有限的经历中还没有发生过，但是如果不未雨绸缪，真正发生时的后果将难以设想。笔者项目中用到的aws rds默认启用了以7天为周期的自动备份，这个配置可以手动调整也可以将配置写入构建基础设施的脚本中去。 如果灾难真的发生，光有数据备份是不够的，还需要能够快速重建应用运行时的基础设施。笔者所在的团队(下文简称团队)分别使用了aws cloudformation和serverless framework，cloudformation用来重建数据库、网络等基础设施，serverless framework用来重建lambda function，在重建数据库的时候，通过持续集成流水线，以环境变量的方式传入最近一次数据备份快照的id，15分钟以内即可重建一套产品环境。
总结
笔者所在的团队是10个人左右的配置，采用结对编程的方式，3对pair，包含web端、业务层、数据层。从产品原型确定到第一次上线(mvp)耗时30天，每周至少发布一次新版本，story的平均交付时间(cycle time，从需求确定到上线)为8天。这样的速度也许不能算快，但是如果没有serverless架构在运维端提供的支持，我们想要在交付速度上有更高的突破会困难得多。
最后来谈一下成本，俗话说抛开商业化谈技术都是耍流氓，大部分人看到一个强大易用的工具都会下意识里觉得开销会很大。实际上并不是这样，我们做了一个粗算，选用双核cpu，8g内存的m4型服务器，开销是$72每月。dev，staging，prod三个环境都用同样的配置就是$216每月，而实际上lambda每个月的开销包含所有环境在$20左右，需要注意的是lambda的计费是根据使用量来的，我们的api访问大约在150万每月的量级。可以预见到当访问达到一定数量的时候lambda的开销会和使用服务器的方案持平甚至更大，但是在量小的时候优势明显。
得益于强大的aws生态，利用lambda构建的无服务器应用经过少量甚至无需任何配置，即可以极低的价格获得完整的运维功能和体验。与自己利用开源工具进行搭建的方式相比，研发团队可以从繁琐的运维工作——特别是基础工程搭建——中解脱出来，更加专注于产品本身，极大的提高软件交付速度，可用性、可靠性和可扩展性也相当有保障。换来的代价是更高的迁移成本，某些功能的不可定制化可能成为瓶颈，以及对底层实现原理的屏蔽也可能对开发者的学习和成长有影响。
Coherent推出U波段和超宽C波段WaveShaper系列产品
虹科分享 | 虹科Dimetix激光测距传感器如何利用反射来测量？（下）
汇总解读华为麒麟960六大创新之处
佳恩半导体再次完成数千万A轮融资
基于多功能实用遥控插座的设计方案
无服务器架构的基本概念及运维
OpenI启智MindSpore集结号第二期活动正式启动
python中eval的用法和作用
马云：未来城市的发展将取决于谁的数据更丰富
对于消防巡检柜而言，它到底该如何正确的接线
社交媒体营销如何利用好大数据
伺服体系构成原理框图
三星贴片电容怎么测量好坏？出现双倍电压会产生什么影响？
AMETEK程控电源部发布Asterion系列交直流电源的3kVA新型号 ——具有高功率密度和易用触摸屏的新星产品
行业巨头争入智能家居市场 个性化的体验是关键
红外线测温仪设计难点及注意事项
亲见H1智能座机体验 沟通无价
基于FPGA的VHDL语言设计控制器SJA1000的IP软核设计
锂电池测试常见标准汇总
双向晶闸管和双向可控硅的区别
在介绍运维之前，大家先来快速了解一下无服务器(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。
监控&报警
监控的意义在于全面了解应用的资源使用率，性能和运行情况，这些数据可以用来帮助团队及时作出调整，保证应用程序顺畅运行。这通常包括cpu使用率，数据传输，磁盘使用等。在突发状况导致系统不可用的时候，团队的响应速度，往往取决于监控和报警的及时性，全面性和准确度。如果能在对历史数据的分析之上对监控系统进行合理的配置，团队甚至能预测不好的事情将要发生，提前做好防范，未雨绸缪。
同上，这里还是以一个spring boot应用为例，在上一小节指标数据的采集中提到过actuator，事实上actuator除了可以记录上面提到的指标，还可以用来收集监控数据。这里我们只需要设置一个spring boot admin应用，给需要进行监控的应用加上spring boot admin client配置，监控数据就会通过actuator暴露的api传递给spring boot admin。
报警功能一般则要根据实际情况自行实现。spring boot admin中实现了对pagerduty，slack等第三方工具的集成，如果只是需要简单的邮件提醒，实现起来也不复杂，这里就不展开了。
随着云上基础设施的普及，上面提到的监控和报警早已是各个平台的标准配置，根本轮不到开发者去操心如何实现及维护，运营团队可以把更多的精力放在配置优化的工作中去。
aws默认提供了非常完备的监控数据，也允许自定义监控dashboard，通过把一系列重要的指标添加到创建好的dashboard中，应用的运行状况一目了然。
前面已经提到过，在出现错误，或性能底下时，根据某些关键指标的变动情况发送警告通知非常必要。笔者所在的项目的做法是使用aws cloudwatch和aws sns提供的告警通知功能，只需要先选择指标然后设定触发阈值和检查间隔时间即可，aws sns支持http、sms、email等多种订阅方式。下图展示了如何设定当某个lambda在过去5分钟内发生了5次以上错误的时候发送通知。
灾难备份&恢复
在系统镜像，构建工具还有容器技术越来越普及的今天，灾难备份的意义很大程度上是为了有效保护重要数据。通常的做法是设定一些定期任务，将数据传输到远端的灾备中心，从物理上抵御不可抗灾难。如果数据量过大，出现网络传输效率跟不上的情况，可以参考aws用卡车拉数据的解决办法。
真正需要用到灾难备份的情况在笔者有限的经历中还没有发生过，但是如果不未雨绸缪，真正发生时的后果将难以设想。笔者项目中用到的aws rds默认启用了以7天为周期的自动备份，这个配置可以手动调整也可以将配置写入构建基础设施的脚本中去。 如果灾难真的发生，光有数据备份是不够的，还需要能够快速重建应用运行时的基础设施。笔者所在的团队(下文简称团队)分别使用了aws cloudformation和serverless framework，cloudformation用来重建数据库、网络等基础设施，serverless framework用来重建lambda function，在重建数据库的时候，通过持续集成流水线，以环境变量的方式传入最近一次数据备份快照的id，15分钟以内即可重建一套产品环境。
总结
笔者所在的团队是10个人左右的配置，采用结对编程的方式，3对pair，包含web端、业务层、数据层。从产品原型确定到第一次上线(mvp)耗时30天，每周至少发布一次新版本，story的平均交付时间(cycle time，从需求确定到上线)为8天。这样的速度也许不能算快，但是如果没有serverless架构在运维端提供的支持，我们想要在交付速度上有更高的突破会困难得多。
最后来谈一下成本，俗话说抛开商业化谈技术都是耍流氓，大部分人看到一个强大易用的工具都会下意识里觉得开销会很大。实际上并不是这样，我们做了一个粗算，选用双核cpu，8g内存的m4型服务器，开销是$72每月。dev，staging，prod三个环境都用同样的配置就是$216每月，而实际上lambda每个月的开销包含所有环境在$20左右，需要注意的是lambda的计费是根据使用量来的，我们的api访问大约在150万每月的量级。可以预见到当访问达到一定数量的时候lambda的开销会和使用服务器的方案持平甚至更大，但是在量小的时候优势明显。
得益于强大的aws生态，利用lambda构建的无服务器应用经过少量甚至无需任何配置，即可以极低的价格获得完整的运维功能和体验。与自己利用开源工具进行搭建的方式相比，研发团队可以从繁琐的运维工作——特别是基础工程搭建——中解脱出来，更加专注于产品本身，极大的提高软件交付速度，可用性、可靠性和可扩展性也相当有保障。换来的代价是更高的迁移成本，某些功能的不可定制化可能成为瓶颈，以及对底层实现原理的屏蔽也可能对开发者的学习和成长有影响。
Coherent推出U波段和超宽C波段WaveShaper系列产品
虹科分享 | 虹科Dimetix激光测距传感器如何利用反射来测量？（下）
汇总解读华为麒麟960六大创新之处
佳恩半导体再次完成数千万A轮融资
基于多功能实用遥控插座的设计方案
无服务器架构的基本概念及运维
OpenI启智MindSpore集结号第二期活动正式启动
python中eval的用法和作用
马云：未来城市的发展将取决于谁的数据更丰富
对于消防巡检柜而言，它到底该如何正确的接线
社交媒体营销如何利用好大数据
伺服体系构成原理框图
三星贴片电容怎么测量好坏？出现双倍电压会产生什么影响？
AMETEK程控电源部发布Asterion系列交直流电源的3kVA新型号 ——具有高功率密度和易用触摸屏的新星产品
行业巨头争入智能家居市场 个性化的体验是关键
红外线测温仪设计难点及注意事项
亲见H1智能座机体验 沟通无价
基于FPGA的VHDL语言设计控制器SJA1000的IP软核设计
锂电池测试常见标准汇总
双向晶闸管和双向可控硅的区别