全球云服务器

马上开始：五种具备可行性的无服务器框架应用方案

发布时间：2023-05-05 21:18:02 作者：l8566 阅读量：7979

很多朋友搞不清“无服务器”与“功能即服务”架构之间的区别。其一，无服务器其实有点用词不当，其中当然存在服务器元素，只是大家不必亲自维护。您需要做的只是上传代码片段并由托管服务处理其余工作。

　　很多朋友搞不清“无服务器”与“功能即服务”架构之间的区别。其一，无服务器其实有点用词不当，其中当然存在服务器元素，只是大家不必亲自维护。您需要做的只是上传代码片段并由托管服务处理其余工作。

　　不过哪些应用程序适合这种部署方式?答案与您面对AWS或者Azure时基本相同; 这些系统的设计目标都是通过具体操作触发代码块。以下五种常见的无服务器框架可行方案相信值得您加以参考。

c004c5cb4edf12a49559b9c35b828528.jpg (33.73 KB, 下载次数: 7)

下载附件

昨天 23:30 上传

　　API

　　作为无服务器架构最简单也最直接的应用之一，我们可以通过服务或者单页面应用创建REST API以返回待消费数据。

　　REST API并不难构建。一般来讲，大家只需要一套基本Web框架、一套用于渲染数据返回格式的库(例如JSON)以及用于同数据后端进行交互的粘接代码即可。利用无服务器架构，开发者能够专注于编写并部署支持该API所需要的代码，其它任务则不再需要费心。

　　REST API当中多数需要手动调节的功能，例如自动规模伸缩，皆可在无服务器框架中自动完成。另外，其按资源使用量付费的模式意味着您能够拥有一套轻量化且访问成本极低的API，且几乎无需任何部署工作。

　　创建webhook

　　这种被广泛使用的HTTP上回调机制能够轻松实现推送、管道与插件等功能，从而提升Web应用的实用性。无服务器框架特别适用于webhook场景，且相关优势与创建API类似：低运营成本、低维护要求、可自动规模伸缩。大家完全可以在Azure Functions上利用Node.js实现webhook以处理Twilio服务中的短信消息或电话呼叫。

　　更重要的是，大部分webhook类活动并不需要大量代码。因此，其非常适合由lambda式无服务器设计提供的面向功能方案实现，从而显著简化整个交付流程。

　　提供静态内容

　　无服务器架构还提供一种简单方法以支撑静态内容，包括图片、音频或者HTML页面等不会被应用修改的内容。静态资产可存储在多个后端当中，包括Amazon S3存储桶，并通过地理化缓存(例如Cloudflare)实现加速。(如果您使用S3，则可选择Amazon Route 53以将URL映射至特定资源; 在基本场景下甚至完全无需涉及AWS Lambda。)

　　同样的，无服务器模式的优势在于自动接着各项组件以契合需求。我们也能够在必要时以相对简单的方式添加动态功能。不过在这种情况下，功能在启动时间可能对性能造成影响，因此需要对应引入地理缓存机制。

　　单页面应用

　　这类用例可以视为上述方法的集合体。单一页面的基础资产可视为静态内容; 前端数据提供由API调用实现。前端的数据渲染则通过JavaScript框架完成。

　　优势：应用的每项元素皆可独立实现并进行独立扩展。弊端：应用必须作为多项独立功能的集合，而非单一统一项目。这意味着我们无法利用现代源代码控制与项目管理技术对其进行全面打理。另外，大家还需要引入React、Angular或者Vue.js等前端框架——不过这对于有经验的Web开发者来说应该不是什么问题。

　　运行在后台的事件驱动型应用

　　无服务器应用可响应事件，但并不是说这些事件就必须属于HTTP请求。其可以为云服务中的事件或消息管道，也可以由运行计划负责触发——大家可以借此方便地执行被动或者低优先级功能。例如被上传至S3存储桶的图像可解决对应功能，旨在为该图像提供对应的元数据标签、大小调整并根据图像识别或分析API的反馈进行裁剪。

　　无服务器框架的突出特性在于，其中的各个组件采取松散耦合模式——或者可以将其形容为微服务形式。如果大家不希望采取这样的组合方式或者面对的是整体式应用的移植工作，那么无服务器架构可能并不合适。但在另一方面，其显然更适合支持新型、元素数量较少且各组件需要独立扩展的应用。

　　

我要评论