现在开始：五种可能的serverless框架应用场景一、serverless其实有点用词不当，当然有server元素，但你不用自己维护。您需要做的就是上传代码片段，让托管服务处理剩下的事情。但是哪些应用程序适合这种类型的部署？答案基本上与您在处理AWS或Azure时相同；这些系统旨在通过特定操作触发代码块。以下是五个值得考虑的常见无服务器框架选项。API是Serverless架构最简单直接的应用之一。我们可以通过服务或单页应用创建RESTAPI来返回要消费的数据。RESTAPI并不难构建。一般来说，你只需要一套基本的Web框架，一套渲染数据返回格式（如JSON）的库，以及与数据后端交互的胶水代码。使用无服务器架构，开发人员可以专注于编写和部署支持API所需的代码，将其他任务抛在脑后。RESTAPI中大部分需要手动调优的功能，比如自动伸缩，都可以在Serverless框架中自动完成。此外，其按资源付费的使用模式意味着您可以拥有一套访问成本极低的轻量级API，几乎不需要任何部署工作。创建Webhook这种广泛使用的HTTP回调机制，可以轻松实现推送、管道、插件等功能，从而提高Web应用的实用性。Serverless框架特别适用于webhook场景，相关优势类似于创建API：低运营成本、低维护需求、自动伸缩。您可以使用Node.js在AzureFunctions上实现Webhook，以处理Twilio服务中的短信或电话。更重要的是，大多数类似webhook的活动不需要大量代码。因此，它非常适合实现lambda风格的无服务器设计提供的面向功能的解决方案，从而显着简化整个交付过程。提供静态内容无服务器架构还提供了一种简单的方法来提供静态内容，包括图像、音频或应用程序不会修改的HTML页面。静态资产可以存储在多个后端，包括AmazonS3存储桶，并通过Cloudflare等地理缓存进行加速。（如果你使用S3，你可以选择AmazonRoute53将URL映射到特定的资源；在基本场景下，你甚至根本不需要涉及AWSLambda。)同样，serverless模型的优势在于自动连接各个组件来满足需求。我们还能够在必要时以相对简单的方式添加动态功能。但是，在这种情况下，该功能可能会在启动时对性能产生影响，因此需要相应地引入地理缓存机制。像单页应用程序这样的用例可以被认为是上述方法的组合。单个页面的基础资源可视为静态内容；前端数据由API调用提供。前端数据渲染是通过JavaScript框架完成的。优点：应用程序的每个元素都可以独立实现并独立扩展。缺点：应用必须是独立功能的集合，而不是一个单一的统一项目。这意味着我们无法使用现代源代码控制和项目管理技术对其进行全面管理。此外，您还需要引入React、Angular或Vue.js等前端框架——但这对于有经验的Web开发人员来说应该不是问题。在后台运行的事件驱动应用程序无服务器应用程序可以响应事件，但这并不意味着这些事件必须是HTTP请求。它可以是云服务中的事件或消息管道，也可以由运行计划触发——您可以使用它轻松执行被动或低优先级功能。例如，上传到S3存储桶的图像可以使用旨在根据图像识别或分析API的反馈为图像提供相应的元数据标签、调整大小和裁剪的函数来处理。无服务器框架的显着特征是它的各个组件是松散耦合的——或者，如您所描述的，以微服务的形式。如果你不想采用这种组合的方式，或者你面临的是单体应用的移植，那serverless架构可能不太合适。但另一方面，它显然更适合支持元素数量较少且每个组件需要独立扩展的新型应用。原文链接：http://www.infoworld.com/article/3165484/cloud-computing/build-em-now-5-uses-for-serverless-frameworks.html原标题：Build'emnow！无服务器框架的5种用途原作者：SerdarYegulalp
