共计 2970 个字符，预计需要花费 8 分钟才能阅读完成。
起源 | 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
