都 2021 年了，Serverless 能取代微服务吗？

来源 | Serverless 公众号
编译 | OrangeJ
作者 | Mariliis Retter

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

有人说微服务与 Serverless 是相背离的，虽然我们可以基于 Serverless 后端来构建微服务，但在微服务和 Serverless 之间并不存在直接的路径。也有人说，因为 Serverless 内含的 Function 可以视为更小的、原子化的服务，天然地契合微服务的一些理念，所以 Serverless 与微服务是天作之合。马上就要 2021 年了，Serverless 是否终将取代微服务？从微服务到 Serverless 需要经过怎样的路径？本文将对 Serverless 与微服务在优势劣势上进行深度对比。

从概念上讲，微服务完全符合 Serverless 功能结构，微服务可以轻松实现不同服务的部署和运行时隔离。在存储方面，像 DynamoDB 这样的服务可以让每个微服务拥有独立的数据库，并独立地进行扩展。在我们深入探讨细节之前，先别急着“站队”，不妨先基于你团队的实际情况，真实的去思考是否适合使用微服务，千万不要因为 "这是趋势 "而去选择它。

微服务在 Serverless 环境下的优势

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

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

细粒度的资源分配

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

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

松耦合

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

支持多运行环境

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

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

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

开发团队的独立性

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

微服务在 Serverless 中的劣势

难以监控和调试

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

可能经历更多冷启动

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

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

其他缺点

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

• 确定服务边界并非易事，可能会招致架构问题。
• 更广泛的攻击面
• 服务编排费用问题
• 同步计算和存储（在需要的时候）是不容易做到高性能和可扩展

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

Serverless 中微服务应该多大？

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

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

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

你可以这样设想："如果我把这个微服务分拆出来......

• 它能让不同的团队独立工作吗？
• 能否从细粒度的资源分配或选择性的扩展能力中获益？

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

松耦合的架构

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

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

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

跨组件隔离

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

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

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

翻译：OrangeJ
原文链接：https://dzone.com/articles/microservices-and-serverless-winning-strategies-an