本文通过介绍了 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 类型的插件。如果你对这类插件的应用感兴趣，也欢送在社区中进行更丰盛的实际与探讨。