都 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