Loading...
墨滴

我的小碗汤

2022/01/08  阅读:32  主题:山吹

PaaS 与 FaaS 我应该选择在哪一个上运行我的微服务?

PaaS vs FaaS,运行微服务应该选择哪个?

我们都知道微服务是分布式进程,必须独立发布、部署和扩展。乍一看,平台即服务(PaaS)函数即服务(FaaS),又称无服务器。这两种云计算模型也能够在软件开发过程中,提供非常短的交付时间[1],从而促进创新和持续研究[2]

然而,当深入研究它们的技术细节时,会很快意识到它们并不总是适用在相同的场景。

PaaS

Platform-as-a-Service(平台即服务)是一种云模型,你提供源代码,平台将打包、发布、供给、部署、运行、监控和扩缩微服务。我能想到的最好的例子是Cloud Foundry[3]Heroku[4]谷歌App Engine[5]

你的应用程序在PaaS上至少有一个实例在运行。当需要通过SSE (Server-Sent-Events)WebsocketsRSocket[6]实现通知推送时,这很方便。还有很多其他的好处,例如:及时处理传入的请求,在内存中保存数据(也称为进程内数据缓存),实现断路器模式[7]处理部分故障,或者利用连接池来调节工作负载和减少响应时间。

FaaS

Function-as-a-Service(函数即服务)指的是计算模型,在这个模型中,你的代码将被平台打包,并作为一些可配置事件(如HTTP请求、消息到达、文件上传)的结果,在有限时间内按需运行,之后可能随时被处理。这里的优秀代表有AWS Lambda[8]Azure函数[9]谷歌云函数[10]

我们可以用大量的functions来组装应用程序,但每个functions需要单独配置和部署。这就是为什么FaaS有时被称为纳米服务

  • 如上所述,function生命周期在用户请求激活时开始,在返回时结束。处理时间通常受到平台的限制。

  • FaaS的自动扩展几乎是无限的,它允许我们无缝地处理工作负载峰值。另一方面,大量的函数实例可能会给我们的体系结构带来巨大的压力,直到某个地方出现了问题,我们最终将DDoS[11]作为我们自己的后端,即:数据库、内部服务或第三方API。

  • functions往往比services粒度更细,因此我们最终需要协调、集成和管理大量的部署单元。需要实现的特性越多,成熟的FaaS应用程序就越复杂。

考虑下面的图表,比较了使用无服务器框架(Lambda + API网关)实现的项目和使用纯Node.js实现的项目之间的代码行。对于添加到软件系统中的每一个重要的功能,当使用无服务器架构时,维护项目所需的配置代码行数将以陡峭的线性速度增长。简而言之,从短期来看,无服务器架构的前景似乎不容乐观。

上图摘自:The Real Cost of Serverless Architecture

  • 如果没有用户请求需要处理,function将不会运行。这个特性就是众所周知的scale-to-zero,它是FaaS计算的标志。当工作负载较低时,它可以节省基础设施成本。

  • 另一方面,在稳定的工作负载下,运行functions的成本可能更昂贵。下面的图表比较了AWS LambdasEC2虚拟机每个工作负载的价格。

上图摘自:Economics Of Serverless[12]

注意: 上面的图片比较的是Lambdas和重量级VM,而不是PaaS,后者在Kubernetes出现之前就已经使用了容器。以Cloud Foundry为例,我看到客户在高度规范和非常严格的生产环境中,在每个VM上运行20多个不同的微服务。这意味着之前的收支平衡将发生在平均每秒5个请求由m4.4xlarge VM支撑的平台。

开发者经验

我已经看到一些同事和公司倡导将FaaS作为一种方法,以避免构建和维护大量容器镜像以及跨各种环境协调的痛苦。

我非常同意将管理基础设施的负担,从开发人员身上抽象出来的想法。然而,我们已经看到PaaS和FaaS都能够代表开发人员处理无差别的繁重工作[13],包括打包、部署和自动伸缩应用程序,以及管理安全、路由和日志聚合。

没有必要仅仅为了避免大规模运行容器所带来的复杂性而采用FaaS

如果您的目标仅仅是提高开发人员的体验,那么您可能会发现,与FaaS相比,PaaS以更低的复杂性和更少的侵入性来满足需求。我相信这一理念是数字平台模式[14]越来越多人采用的原因。

数字平台是自助服务API、工具、服务、知识和支持的基础,是一个引人注目的内部产品。自主交付团队可以利用平台以更快的速度交付产品特性,减少协调。

总结

现在炒作Serverless似乎接近尾声,可以查看为何Serverless停滞不前[15]Serverless未实现的潜力[16]

我认为,每一种模式都有各自的优点和缺点。在将我们的工作负载迁移到云上时,似乎总是没有万能的解决方案。混合的方法可能会帮助我们获得最好的结果。

我目前的立场是:

  • 两种云计算模型适用于不同的场景
  • 我发现PaaS和FaaS提供了比Kubernetes更好的开发体验
  • 我不认为FaaS可以取代PaaS
  • 我不认为PaaS已经过时。事实上,我认为数字平台趋势是PaaS的一种重新尝试,但它更侧重于构建而非购买

所以您在做决定之前先考虑自己的需求和环境,无论跟风或是什么原因,甚至可以作一些体验,这是这两种云计算模型提供的最大好处之一。

原文

翻译自PaaS 与 FaaS我应该选择在哪一个上运行我的微服务?[17]

原文

本文首发于微信公众号【我的小碗汤】,扫码关注,了解更多咨询,更有免费资源供您学习

扫码关注,加群学习
扫码关注,加群学习

参考资料

[1]

交付时间: https://www.agilealliance.org/glossary/lead-time

[2]

持续研究: https://books.google.co.uk/books?id=ivixBQAAQBAJ

[3]

Cloud Foundry: https://www.cloudfoundry.org/

[4]

Heroku: https://www.heroku.com/

[5]

谷歌App Engine: https://cloud.google.com/appengine

[6]

RSocket: https://github.com/rsocket/rsocket#rsocket-protocol

[7]

断路器模式: https://spring.io/projects/spring-cloud-circuitbreaker

[8]

AWS Lambda: https://aws.amazon.com/lambda/

[9]

Azure函数: https://azure.microsoft.com/en-gb/services/functions/

[10]

谷歌云函数: https://cloud.google.com/functions/

[11]

DDoS: https://en.wikipedia.org/wiki/Denial-of-service_attack

[12]

Economics Of Serverless: https://www.bbva.com/en/economics-of-serverless/

[13]

无差别的繁重工作: https://aws.amazon.com/blogs/aws/we_build_muck_s/

[14]

数字平台模式: https://www.infoq.com/articles/kubernetes-successful-adoption-foundation/

[15]

为何Serverless停滞不前: https://www.infoq.com/articles/serverless-stalled/

[16]

Serverless未实现的潜力: https://www.jeremydaly.com/the-unfulfilled-potential-of-serverless/

[17]

PaaS 与 FaaS我应该选择在哪一个上运行我的微服务?: https://cloudnative.ly/paas-vs-faas-229919694163

我的小碗汤

2022/01/08  阅读:32  主题:山吹

作者介绍

我的小碗汤

公众号:我的小碗汤