关于后端:当-Amazon-Lambda-遇上-Apache-APISIX-可以擦出什么火花

42次阅读

共计 2950 个字符,预计需要花费 8 分钟才能阅读完成。

本文通过介绍了 Serverless 的相干内容,引出了一个好的网关在 Serverless 架构下的重要性。而 APISIX 就是这样的一个网关。

作者程小兰,API7.ai 技术工程师

什么是 Serverless

Serverless 的根底概念是将运行服务所需的基础设施交由云服务提供商治理,以及一些自部署的 Serverless 平台,从而让应用 Serverless 的工程师能够专一于面向客户业务应用层的开发,而不须要在基础设施的构建、治理、扩容等工作上投入过多精力。

目前,很多云服务提供商也在推出 Serverless 相干的产品。比方 Amazon Serverless 的外围是名为 AWS Lambda 的计算服务。

如下图所示,和传统的开发、编译、部署运行形式不同,应用 Amazon Serverless 计算服务 Lambda,仅须要上传源文件,抉择执行环境并执行,便能失去运行后果。在该过程中,服务器部署、runtime 装置、编译等,都由 Amazon Serverless 计算平台治理执行。

对工程师来说,只须要保护源代码和 Amazon Serverless 执行环境的相干配置即可。与此相关的技术还有 BaaS(Backend as a Service,后端即服务),是指咱们无需编写或者治理所有服务端组件,把利用中的各个局部齐全外包进来,而 Serverless 则是一种新的运行代码的托管环境。

为什么须要 Serverless

对于开发人员而言,Serverless 能够对程序执行细节进行形象,让业务开发工程师专一于代码自身。从上图的比照也能够看出,基于 Serverless 的开发,对于开发人员来说更敌对。

从老本角度来看,应用 Serverless 只需依照使用量付费;从服务性能角度来看,Serverless 能够主动响应任何规模的代码执行申请,能够通过调整函数内存大小优化代码执行工夫和响应工夫。

应用 Serverless 时为什么须要一个网关?

尽管 Serverless 对于开发人员提供了十分大的劣势,但 Serverless 服务的应用也存在一些问题。

比方将函数 URL 硬编码到应用程序中;其次利用程序逻辑的受权和身份验证问题也比拟繁琐;再者,更新云服务提供商的过程也是一个比拟艰巨的工程。

而网关能够人造地解决上述问题,通过二者配合的形式,Serverless 能够更好地解决上述问题。如下图所示,形容的是如何应用 Amazon Serverless 的相干服务迅速组装一个简略的 Web Service,网关将在受权等问题中施展重要作用。

这里以 Apache APISIX 为例,它为风行的云服务提供商(AWS、Azure)提供 Serverless 框架反对;能够定义一个路由去启用 Serverless 插件,而不是将函数 URL 硬编码到应用程序中;同时,为开发人员提供了热更新函数 URI 的灵活性,更新不同的 FaaS 云服务提供商也没有什么额定的麻烦;此外,这种办法也加重了利用程序逻辑的受权和身份验证问题。

Apache APISIX 与 Serverless

Apache APISIX 是 Apache 软件基金会下的云原生 API 网关,它兼具动静、实时、高性能等特点,提供了负载平衡、动静上游、灰度公布(金丝雀公布)、服务熔断、身份认证、可观测性等丰盛的流量治理性能。

咱们能够应用 Apache APISIX 来解决传统的南北向流量,也能够解决服务间的东西向流量。同时,它也反对作为 K8s Ingress Controller 来应用。APISIX 通过插件来裁减生态,目前也内置了各类插件,笼罩了 API 网关的各种畛域,如认证鉴权、平安、可观测性、流量治理、多协定接入等,当然,也蕴含很多 Serverless 相干插件。

AWS Lambda 插件

aws-lambda 插件用于将 AWS Lambda 作为动静上游集成至 APISIX,从而实现将拜访指定 URI 的申请代理到 AWS 云。用户应用该插件终止对已配置 URI 的申请,并代表客户端向 AWS Lambda Gateway URI 发动一个新的申请。

这个新申请中携带了之前配置的受权详细信息,包含申请头、申请体和参数(以上参数都是从原始申请中传递的),之后 aws-lambda 插件会将带有响应头、状态码和响应体的响应信息返回给应用 APISIX 发动申请的客户端。该插件反对通过 AWS API key 和 AWS IAM secrets 进行受权。插件细节可参考官网文档或者博客。

Serverless 相干插件汇总

除了 Amazon Lambda,Apache APISIX 目前还反对与 Azure Function、Lua 函数和 Apache OpenWhisk 等 Serverless 相干生态的集成,从而提供了相应的 Serverless 插件,具体如下表所示。

插件名称 形容
serverless 用户能够通过 Serverless 插件上传自定义的 Lua 脚本,并依据配置中的 phase 来指定代码运行阶段。例如在 access 阶段对申请进行访问控制,在 header filter,body filter 阶段,对响应头或响应体进行批改,或者在 log 阶段打印个性化日志等。另外,因为 Serverless 插件是热加载的,因而咱们不须要重新启动 Apache APISIX 便可立刻失效。
Azure Function 用于将 Azure Serverless Function 作为动静上游集成至 APISIX,从而实现将拜访指定 URI 的申请代理到 Microsoft Azure 云服务。启用 azure-functions 插件后,该插件会终止对已配置 URI 的申请,并代表客户端向 Azure Functions 发动一个新的申请。该新申请中携带了之前配置的受权详细信息,包含申请头、申请体和参数(以上参数都是从原始申请中传递的)。之后便会通过 azure-functions 插件,将带有响应头、状态码和响应体的信息返回给应用 APISIX 发动申请的客户端。
OpenWhisk 用于将开源的分布式无服务器平台 Apache OpenWhisk 作为动静上游集成至 APISIX。启用 openwhisk 插件后,该插件会终止对已配置 URI 的申请,并代表客户端向 OpenWhisk 的 API Host 端点发动一个新的申请,而后 openwhisk 插件会将响应信息返回至客户端。
OpenFunction 用于将开源的分布式无服务器平台 CNCF OpenFunction 作为动静上游集成至 APISIX。启用 openfunction 插件后,该插件会终止对已配置 URI 的申请,并代表客户端向 OpenFunction 的 function 发动一个新的申请,而后 openfunction 插件会将响应信息返回至客户端。

总结

近年来,随着微服务架构的呈现,很多企业都开始将业务架构迁徙到云端,不少云服务提供商也在推出 Serverless 相干的产品,基于 Serverless 的开发曾经成为一种非常便当的开发模式。

本文通过介绍了 Serverless 的相干内容,引出了一个好的网关在 Serverless 架构下的重要性。而 APISIX 就是这样的一个网关,当然本文并未在具体应用细节上进行更丰盛的形容,仅仅简略介绍了 APISIX 中的 Serverless 类型的插件。如果你对这类插件的应用感兴趣,也欢送在社区中进行更丰盛的实际与探讨。

正文完
 0