都 2021 年了,Serverless 能取代微服务吗?

编译| OrangeJ

作者| Mariliis Retter

“Serverless 能取代微服务吗?” 这是知乎上 Serverless 分类的高热话题。

有人说微服务与 Serverless 是相背离的,虽然我们可以基于 Serverless 后端来构建微服务,但在微服务和 Serverless 之间并不存在直接的路径。

也有人说,因为 Serverless 内含的 Function 可以视为更小的、原子化的服务,天然地契合微服务的一些理念,所以 Serverless 与微服务是天作之合。

马上就要 2021 年了,Serverless 是否终将取代微服务?从微服务到 Serverless 需要经过怎样的路径? 在我们深入探讨细节之前,先别急着“站队”,不妨先基于你团队的实际情况,真实的去思考是否适合使用微服务,千万不要因为 “这是趋势 “而去做选择。

微服务在 Serverless 中的优势

Serverless

1.可选择的可扩展性和并发性

Serverless 让管理并发性和可扩展性变得容易。在微服务架构中,我们最大限度地利用了这一点。每一个微服务都可以根据自己的需求对并发性/可扩展性进行设置。从不同的角度来看这非常有价值:比如减轻 DDoS 攻击可能性,降低云账单失控的财务风险,更好地分配资源……等等。

2.细粒度的资源分配

因为可扩展性和并发性可以自主选择,用户可以细粒度控制资源分配的优先级。在 Lambda functions 中,每个微服务都可以根据其需求,拥有不同级别的内存分配。比如,面向客户的服务可以拥有更高的内存分配,因为这将有助于加快执行时间;而对于延迟不敏感的内部服务,就可以用优化的内存设置来进行部署。

这一特性同样适用于存储机制。比如 DynamoDB 或 Aurora Serverless 数据库就可以根据所服务的特定(微)服务的需求,拥有不同级别的容量分配。

3.松耦合

这是微服务的一般属性,并不是 Serverless 的独有属性,这个特性让系统中不同功能的组件更容易解耦。

4.支持多运行环境

Serverless 功能的配置、部署和执行的简易性,为基于多个运行时的系统提供了可能性。

虽然 Node.js (JavaScript 运行时)是后端 Web 应用最流行的技术之一,但它不可能成为每一项任务的最佳工具。对于数据密集型任务、预测分析和任何类型的机器学习,你可能选择 Python 作为编程语言;像 SageMaker 这样的专用平台更适合大项目。

有了 Serverless 基础架构,你无需在操作方面花费额外的精力就可以直接为常规后端 API 选择 Node.js,为数据密集型工作选择 Python。显然,这可能会给你的团队带来代码维护和团队管理的额外工作。

5.开发团队的独立性

不同的开发者或团队可以在各自的微服务上工作、修复 bug、扩展功能等,做到互不干扰。比如 AWS SAM、Serverless 框架等工具让开发者在操作层面更加独立。而 AWS CDK 构架的出现,可以在不损害高质量和运维标准的前提下,让开发团队拥有更高的独立性。

微服务在 Serverless 中的劣势

Serverless

1.难 以监控和调试

在 Serverless 带来的众多挑战中,监控和调试可能是最有难度的。因为计算和存储系统分散在许多不同的功能和数据库中,更不用说队列、缓存等其他服务了,这些问题都是由微服务本身引起的。不过,目前已经有专业的平台可以解决所有这些问题。那么,专业的开发团队是否要引入这些专业平台也应该基于成本进行考量。

2.可能经历更多冷启动

当 FaaS 平台(如 Lambda)需要启动一个新的虚拟机来运行函数代码时,就会发生冷启动。如果你的函数 Workload 对延迟敏感,就很可能会遇到问题。因为冷启动会在总启动时间中增加几百毫秒到几秒的时间,当一个请求完成后,FaaS 平台通常会让 microVM 空闲一段时间,等待下一个请求,然后在 10-60 分钟后关闭(是的,变化很大)。结果是:你的功能执行的越频繁,microVM 就越有可能为传入的请求而启动并运行(避免冷启动)。

当我们将应用分散在数百个或数千个微服务中时,我们可能在每个服务中分散调用时间,导致每个函数的调用频率降低。注意 “可能会分散调用”。根据业务逻辑和你的系统行为方式,这种负面影响可能很小,或者可以忽略不计。

3.其 他缺点

微服务概念本身还存在其他固有的缺点。这些并不是与 Serverless 有内在联系的。尽管如此,每一个采用这种类型架构的团队都应该谨慎,以降低其潜在的风险和成本。

  • 确定服务边界并非易事,可能会招致架构问题。

  • 更广泛的攻击面

  • 服务编排费用问题

  • 同步计算和存储(在需要的时候)是不容易做到高性能和可扩展

微服务在 Serverless 中的挑战和实践

Serverless

1.Serverless 中微服务应该多大?

人们在理解 Servrless 时,” Function as a Services(FaaS) ” 的概念很容易与编程语言中的函数语句相混淆。目前,我们正在处在一个没有办法划出完美界限的时期,但经验表明,使用非常小的 Serverless 函数并不是一个好主意。

当你决定将一个(微)服务分拆成独立的功能时,你就将不得不面对 Serverless 难题。因此,在此提醒,只要有可能,将相关的逻辑保持在一个函数中会好很多。

当然,决策过程也应该考虑拥有一个独立的微服务的优势

你可以这样设想:“如果我把这个微服务分拆出来……”

  • 它能让不同的团队独立工作吗?

  • 能否从细粒度的资源分配或选择性的扩展能力中获益?

如果不能,你应该考虑将这个服务与另一个需要类似资源、上下文关联并执行相关 Workload 的服务捆绑在一起。

2.松耦合的架构

通过组成 Serverless 函数来协调微服务的方法有很多。

当需要同步通信时,可以直接调用(即 AWS Lambda RequestResponse 调用方法),但这会导致高度耦合的架构。更好的选择是使用 Lambda Layers 或 HTTP API,这样可以让以后的修改或迁移服务对客户端不构成影响。

对于接受异步通信模型,我们有几种选择,如队列(SQS)、主题通知(SNS)、Event Bridge 或者 DynamoDB Streams。

3.跨组件隔离

理想情况下,微服务不应向使用者暴露细节。像 Lambda 这样的 Serverless 平台会提供一个 API 来隔离函数。但这本身就是一种实现细节的泄露,理想情况下,我们会在函数之上添加一个不可知的 HTTP API 层,使其真正隔离。

4.使用并发限制和节流策略的重要性

为了减轻 DDoS 攻击,在使用 AWS API Gateway 等服务时,一定要为每个面向公众的终端设置单独的并发限制和节流策略。这类服务一般在云平台中会为整个区域设置全局并发配额。如果你没有基于端点的限制,攻击者只需要将一个单一的端点作为攻击目标,就可以耗尽你的配额,并让你在该区域的整个系统瘫痪。

译文链接:

https://dzone.com/articles/microservices-and-serverless-winning-strategies-an

Serverless
我还没有学会写个人说明!
上一篇

经典街机麻将名作《上海3》回归 12月31日登陆Switch

下一篇

环球影业官方声明:未转让《速度与激情9》、《侏罗纪世界3》等影片版权

你也可能喜欢

评论已经被关闭。

插入图片