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

前面已经提到过，在出现错误，或性能底下时，根据某些关键指标的变动情况发送警告通知非常必要。笔者所在的项目的做法是使用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构建的无服务器应用经过少量甚至无需任何配置，即可以极低的价格获得完整的运维功能和体验。与自己利用开源工具进行搭建的方式相比，研发团队可以从繁琐的运维工作——特别是基础工程搭建——中解脱出来，更加专注于产品本身，极大的提高软件交付速度，可用性、可靠性和可扩展性也相当有保障。换来的代价是更高的迁移成本，某些功能的不可定制化可能成为瓶颈，以及对底层实现原理的屏蔽也可能对开发者的学习和成长有影响。

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!