什么时候我们才需要 Serverless 架构？

Posted 2021-04-30 phodal

尽管 Serverless 在编写传统的 Web 应用上，有一定的缺点。然而，它的事件驱动及运行时计算，使得它在某些场景上相当的合适。

发送通知

由我们在上一节中提到的，对于诸如 PUSH Notification、邮件通知接口、短信，这一类服务来说，他们都需要基础设施来搭建。并且，他们对实时性的要求相对没有那么高。

即使在时间上晚来几秒钟，用户还是能接受的。在我们所见到的短信发送的例子里，一般都会假设用户能在 60 秒内收到短信。因此，在这种时间 1s 的误差，用户也不会恼火的。而对于 APP 的消息推送而言，这种要求就更低了，用户反而不太希望能收到这样的推送

WebHook

当我们没有服务器，又想要一个 Webhook 来触发我们一系列的操作的时候。我们就可以考虑使用 Serverless，我们不需要一直就这么支付一个服务器的费用。通过 Serverless，我们就可以轻松完成这样的工作，并且节省大量的费用。

一个比较明显的例子，就如 GitHub Hooks

GitHub 上的 Webhook 允许我们构建或设置在 GitHub.com 上订阅某些事件的 GitHub 应用程序。当触发这些事件之一时，我们将向 webhook 配置的 URL 发送 HTTP POST 有效内容。

比如说，当我们 PUSH 了代码，我们想触发我们的持续集成。这个时候，就可以通过一个 Webhook 来做这样的事情。

轻量级 API

Serverless 特别适合于，轻量级快速变化地 API。

其实，我一直没有想到一个合适的例子。在我的假想里，一个 AutoSuggest 的 API 可能就是这样的 API，但是这种 API 在有些时候，往往会伴随着相当复杂的业务。

于是，便想举一个 Featrue Toggle 的例子，尽管有一些不合适。但是，可能是最有价值的部分。

物联网

当我们谈及物联网的时候，我们会讨论事件触发、传输协议、海量数据（数据存储、数据分析）。而有了 Serverless，那么再多的数据，处理起来也是相当容易的一件事。

对于一个物联网应用的服务端来说，系统需要收集来自各个地方的数据，并创建一个个 pipeline 来处理、过滤、转换这些数据，并将数据存储到数据库中。

对于硬件开发人员来说，对接不同的硬件，本身就是一种挑战。而直接使用诸如 AWS IoT 这样国，可以在某种程度上，帮助我们更好地开发出写服务端连接的应用。

同时，对于物联网应用的客户端来说，则需要从数据库抽取数据进行展示。这部分，可能算不上是一个挑战点。

数据统计分析

数据统计本身只需要很少的计算量，但是生成图表，则可以定期生成。

在接收数据的时候，我们不需要考虑任何延时带来的问题。50~200 ms 的延时，并不会对我们的系统造成什么影响。

Trigger 及定时任务

对于哪些需要爬虫来抓取和生成的程序来说，Serverless 可能是一个不错的舞台。

尽管，这样的工作也可以由云服务器来做，我们只需要定时的启动一下服务器。通过服务器中的自启动脚本来做相应的事，但是当我们完成了一系列的工作之后。我们需要将数据存储在一个远程的服务器上。而为了让系统中的其它应用，也能直接访问这些数据。那么，我们可能会考虑使用一个云数据库。这个时候，Serverless 应用看上去更具有吸引力。

在那篇《CRON 定时执行 Lambda 任务》中，我们也可以看到 AWS Lambda 可以支持 Lambda 计算，定时启动服务，并计算。

精益创业

Landing Page

Serverless 的快速上线、开发，意味着它可以快速验证一个想法 MVP。如 Dropbox 在开始的时候，只创造了一个 Landing Page。作为一个想使用这个服务的用户，我们会在其中填上我们的邮箱。

而如果是使用 Serverless 来构建这样的应用，那么我们只需要创建一个静态页面，然后用一个 Serverless 服务来保存用户的邮箱到数据库中，如我在 GitHub 上的 serverless-landingpage 所做的那样。

Chat 机器人

聊天机器人，也是一个相当好的应用场景。

But，由于国内的条件限制（信息监管），这并不是一件容易的事。因此，从渠道（如微信、blabla）上，都在尽可能地降低这方面的可能性。

节选自《Serverless 架构应用开发指南》