【译】Serverless架构 - 5

原文：

https://martinfowler.com/arti...

API网关

我们之前提到的FaaS部分是一个“API网关”。API网关是一个将路由/端点定义在配置中的HTTP服务器，并且每一个路由都与FaaS功能关联。当一个API网关接到请求时他负责找到匹配的路由配置并调用对应的FaaS功能。通常API网管允许将http请求参数映射成FaaS函数功能的入参。API网关将FaaS函数的结果返回到http response，并将其返还给原始调用者。

Amazon Web Services有它自己的API网关，其他的供应商也提供类似的能力。

在路由请求之上API网关一般也会提供验权，输入校验，响应码映射等功能。你的第六感可能会想这是不是个好主意，如果是的话先等等 - 我们会在后面考虑这些。

一个API网关+FaaS的场景就是用Serverless的方式创建一个http前端的为服务，其具有来自FaaS函数功能的扩展，管理和其他优点。

目前API网关的工具不太成熟，所以使用API网关定义的应用是勇敢者的游戏。

工具

上面关于API网关工具不成熟的评论实际适用于所有Serverless FaaS。但是也有例外 - 一个例子是Auth0 Webtask (https://webtask.io/) 在其工具中将Developer UX放在首位。 Tomasz Janczuk (https://twitter.com/tjanczuk) 在最近Serverless的行业会议中做了一个很好的展示。

开源

Serverless FaaS应用的一个主要好处是提供一个透明的生产运行时环境，所以现在开源与这个世界没什么关联，例如Docker和容器。未来我们或许可以看到一个主流的的FaaS/API网关平台实现可以运行在一个开发人员的工作站上。 IBM的OpenWhisk（https://developer.ibm.com/ope...）是个实现的例子，看看它或另一个实现是否能接受是很有趣的。

除了运行时实现，已经有一些开源工具和框架来帮助定义，部署和在运行时进行协助。例如Serverless框架（https://github.com/serverless...）让API网关+Lambda的实现更容易，它比AWS上最初提供的更好。

另一个例子是Apex(https://github.com/apex/apex) - 一个‘轻松构建，部署，管理AWS Lambda功能’的项目。一个有趣的地方是他允许你开发一些Amazon不支持Lambda功能的语言，例如Go。

什么不是Serverless？

到目前为止我将Serverless定义成一个主意的组合 - “Backend as a Servie”和“Function as a Service”。并发掘了一下第二个的能力。

在我们开始进入非常重要的优点和缺点之前，我想花点时间在定义上，或至少定义下什么不是Serverless。我看到有些人（包括前段时间的我）对这些事很困惑，所以我想值得花点时间讨论下。

---

本文来自微信公众号「麦芽面包」，id「darkjune_think」
转载请注明。
长按图片识别二维码关注。