尽管 Serverless 在编写传统的 Web 应用上,有一定的缺点。然而,它的事件驱动及运行时计算,使得它在某些场景上相当的合适。
由我们在上一节中提到的,对于诸如 PUSH Notification、邮件通知接口、短信,这一类服务来说,他们都需要基础设施来搭建。并且,他们对实时性的要求相对没有那么高。
即使在时间上晚来几秒钟,用户还是能接受的。在我们所见到的短信发送的例子里,一般都会假设用户能在 60 秒内收到短信。因此,在这种时间 1s 的误差,用户也不会恼火的。而对于 APP 的消息推送而言,这种要求就更低了,用户反而不太希望能收到这样的推送
当我们没有服务器,又想要一个 Webhook 来触发我们一系列的操作的时候。我们就可以考虑使用 Serverless,我们不需要一直就这么支付一个服务器的费用。通过 Serverless,我们就可以轻松完成这样的工作,并且节省大量的费用。
一个比较明显的例子,就如 GitHub Hooks
GitHub 上的 Webhook 允许我们构建或设置在 http://GitHub.com 上订阅某些事件的 GitHub 应用程序。当触发这些事件之一时,我们将向 webhook 配置的 URL 发送 HTTP POST 有效内容。
比如说,当我们 PUSH 了代码,我们想触发我们的持续集成。这个时候,就可以通过一个 Webhook 来做这样的事情。
Serverless 特别适合于,轻量级快速变化地 API。
其实,我一直没有想到一个合适的例子。在我的假想里,一个 AutoSuggest 的 API 可能就是这样的 API,但是这种 API 在有些时候,往往会伴随着相当复杂的业务。
于是,便想举一个 Featrue Toggle 的例子,尽管有一些不合适。但是,可能是最有价值的部分。
当我们谈及物联网的时候,我们会讨论事件触发、传输协议、海量数据(数据存储、数据分析)。而有了 Serverless,那么再多的数据,处理起来也是相当容易的一件事。
对于一个物联网应用的服务端来说,系统需要收集来自各个地方的数据,并创建一个个 pipeline 来处理、过滤、转换这些数据,并将数据存储到数据库中。
对于硬件开发人员来说,对接不同的硬件,本身就是一种挑战。而直接使用诸如 AWS IoT 这样国,可以在某种程度上,帮助我们更好地开发出写服务端连接的应用。
同时,对于物联网应用的客户端来说,则需要从数据库抽取数据进行展示。这部分,可能算不上是一个挑战点。
数据统计本身只需要很少的计算量,但是生成图表,则可以定期生成。
在接收数据的时候,我们不需要考虑任何延时带来的问题。50~200 ms 的延时,并不会对我们的系统造成什么影响。
对于哪些需要爬虫来抓取和生成的程序来说,Serverless 可能是一个不错的舞台。
尽管,这样的工作也可以由云服务器来做,我们只需要定时的启动一下服务器。通过服务器中的自启动脚本来做相应的事,但是当我们完成了一系列的工作之后。我们需要将数据存储在一个远程的服务器上。而为了让系统中的其它应用,也能直接访问这些数据。那么,我们可能会考虑使用一个云数据库。这个时候,Serverless 应用看上去更具有吸引力。
在那篇《CRON 定时执行 Lambda 任务》中,我们也可以看到 AWS Lambda 可以支持 Lambda 计算,定时启动服务,并计算。
Serverless 的快速上线、开发,意味着它可以快速验证一个想法 MVP。如 Dropbox 在开始的时候,只创造了一个 Landing Page。作为一个想使用这个服务的用户,我们会在其中填上我们的邮箱。
而如果是使用 Serverless 来构建这样的应用,那么我们只需要创建一个静态页面,然后用一个 Serverless 服务来保存用户的邮箱到数据库中,如我在 GitHub 上的 serverless-landingpage 所做的那样。
聊天机器人,也是一个相当好的应用场景。
But,由于国内的条件限制(信息监管),这并不是一件容易的事。因此,从渠道(如微信、blabla)上,都在尽可能地降低这方面的可能性。
但是,我们还可以做一个微信公众号的服务。当用户输入一个关键词时,做出相应的回复,这实质上和聊天机器人是差不多的。只需要结合《基于 Serverless 与 Lambda 的微信公共平台》 就可以轻松实现,并实现快速上线。
网站声明:如果转载,请联系本站管理员。否则一切后果自行承担。
加入交流群
请使用微信扫一扫!