被吹得天花乱坠的无服务器架构,究竟是什么?
无服务器 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 的道路走多深。 (编辑:惠州站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |