看看顶级互联网公司都在研究的无服务器架构，看完收获满满( 三 ) _服务器

不论你是否认为你的应用会受此影响，都应该以生产环境级别的负载测试下实际性能情况。如果目前的情况还不能接受的话，可以几个月后再看看，因为这也是现在的 FaaS 平台供应商们主要集中精力在解决的问题。
API 网关

文章插图

我们前面还碰到过一个 FaaS 的概念：“API 网关” 。API 网关是一个配置了路由的 HTTP 服务器，每个路由对应一个 FaaS 函数，当 API 网关收到请求时它找到匹配请求的路由，调用相应的 FaaS 函数。通常 API 网关还会把请求参数转换成 FaaS 函数的调用参数。最后 API 网关把 FaaS 函数执行的结果返回给请求来源。
AWS 有自己的一套 API 网关，其他平台也大同小异。
除了纯粹的路由请求，API 网关还会负责身份认证、输入参数校验、响应代码映射等，你可能已经敏锐地意识到这是否合理，如果你有这个考虑的话，我们待会儿就谈。
另一个应用 API 网关加 FaaS 的场景是创建无服务器的 http 前端微服务，同时又具备了 FaaS 函数的伸缩性、管理便利等优势。
目前 API 网关的相关工具链还不成熟，尽管这是可行的但也要够大胆才能用。
工具链
前面关于工具链还不成熟的说法是指大体上 FaaS 无服务器架构平台的情况，也有例外，Auth0 Webtask 就很重视改善开发者体验，Tomasz Janczuk 在最近一届的 Serverless Conf 上做了精彩的展示。
无服务器应用的监控和调试还是有点棘手，我们会在本文未来的更新中进一步探讨这方面。
开源
无服务器 FaaS 的一个主要好处就是只需要近乎透明的运行时启动调度，所以这个领域不像 Docker 或者容器领域那么依赖开源实现。未来肯定会有一些流行的 FaaS / API 网关平台实现可以跑在私有服务器或者开发者工作站上，IBM 的 OpenWhisk 就是一个这样的实现，不知道它是否能成为流行选择，接下来的时间里肯定会有更多竞争者出现。
除了运行时的平台实现，还是有不少开源工具用以辅助开发和部署的，例如 Serverless Framework 在 API 网关 + Lambda 的易用性上就比它的原创者 AWS 要好很多，这是一个 JS 为主的项目，如果你在写一个 JS 网关应用一定要去了解下。
再如 Apex——“轻松创建、部署及管理 AWS Lambda 函数” 。Apex 有意思的一点是它允许你用 AWS 平台并不直接支持的语言来实现 Lambda 函数，比如 Go 。
什么不是 Serverless
在前文中我定义了 “Serverless” 是两个概念的组合：“Backend as a Service” 和 “Function as a Service”，并且对后者的特性做了详细解释。
在我们开始探讨它的好处和弊端之前，我想再花点儿时间在它的定义上，或者说：区分开那些容易和 Serverless 混淆的概念。我看到一些人（包括我自己最近）对此都有困惑，我想值得对此做个澄清。

文章插图

对比 PaaS
既然 Serverless FaaS 这么像 12-Factor 应用，那不就是另一种形式的 Platform as a Service 么？就像 Heroku？对此借用 Adrian Cockcroft 一句非常简明的话：
如果你的 PaaS 能在 20ms 内启动一个只运行半秒钟的实例，它就叫 Serverless 。— Adrian Cockcroft
换句话说，大部分 PaaS 应用不会为了每个请求都启动并结束整个应用，而 FaaS 就是这么做的。
好吧，然而假设我是个娴熟的 12-Factor 应用开发者，写代码的方式还是没有区别对么？没错，但是你如何运维是有很大不同的。鉴于我们都是 DevOps 工程师我们会在开发阶段就充分考虑运维，对吧？
FaaS 和 PaaS 在运维方面的关键区别是伸缩性（Scaling）。对于大多数 PaaS 平台而言你需要考虑如何伸缩，例如在 Heroku 上你要用到多少 Dyno 实例？对于 FaaS 应用这一步骤是完全透明的。即便你将 PaaS 配置为自动伸缩，也无法精细到单个请求级别，除非你有一个非常明确稳定的流量曲线可以针对性地配置。所以 FaaS 应用在成本方面要高效得多。
既然如此，何必还用 PaaS？有很多原因，最主要的因素应该是工具链成熟度。另外像Cloud Foundry 能够给混合云和私有云的开发提供一致体验，在写就本文的时候 FaaS 还没有这么成熟的平台。
对比 NoOps
Serverless 并非“零运维”——尽管它可能是“无系统管理员”，也要看你在这个 Serverless 的道路走多深。
“运维”的意义远不止系统管理，它还包括并不限于监控、部署、安全、网络、支持、生产环境调试以及系统伸缩。这些事务同样存在于 Serverless 应用中，你仍旧需要相应的方法处理它们。某些情况下 Serverless 的运维会更难一些，毕竟它还是个崭新的技术。