编译| 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 中微服务应该多大？

人们在理解 Serverless 时，"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

有道无术，术可成；有术无道，止于术
欢迎大家关注Java之道公众号

好文章，我在看❤️