简介：2021年即将到来，Serverless最终会取代微服务吗？从微服务到无服务器的路径是什么？本文将深入对比Serverless和微服务的优缺点。来源|Serverless公众号编译|OrangeJ作者|MariliisRetter“无服务器能否取代微服务？”这是知乎上Serverless类的热门话题。有人说微服务和serverless是对立的。虽然我们可以基于无服务器后端构建微服务，但微服务和无服务器之间没有直接路径。也有人说，因为serverless包含的功能可以看作是更小的原子服务，自然符合微服务的一些概念，所以serverless和微服务是天作之合。2021年即将到来，Serverless最终会取代微服务吗？从微服务到无服务器的路径是什么？本文将深入对比Serverless和微服务的优缺点。从概念上讲，微服务完全符合Serverless的功能结构，微服务可以轻松实现不同服务的部署和运行时隔离。在存储方面，DynamoDB等服务允许每个微服务拥有自己的数据库并独立扩展。在我们深入细节之前，不要急于“排队”。大家不妨先根据自己团队的实际情况考虑一下是否适合使用微服务。不要因为“这是趋势”而选择它。无服务器环境中微服务的优势可选的可扩展性和并发性无服务器使得管理并发性和可扩展性变得容易。在微服务架构中，我们最大限度地利用了这一点。每个微服务都可以根据自己的需要设置并发/可扩展性。这从不同的角度来看都是非常有价值的：比如降低DDoS攻击的可能性、降低云账单失控的财务风险、更好地分配资源等。由于可扩展性和并发性，可以自主选择细粒度的资源分配，用户可以细粒度地控制资源分配的优先级。在Lambda函数中，每个微服务都可以根据其需要进行不同级别的内存分配。例如，面向客户的服务可以分配更高的内存，因为这有助于加快执行时间，而对延迟不敏感的内部服务可以使用优化的内存设置进行部署。此功能也适用于存储机制。例如，DynamoDB或AuroraServerless数据库可以根据所服务的特定（微）服务的需求进行不同级别的容量分配。松耦合是微服务的通用属性，而不是Serverless独有的属性。此功能可以更轻松地解耦系统中具有不同功能的组件。支持多个运行时环境的无服务器功能的配置、部署和执行的简便性为基于多个运行时的系统提供了可能性。虽然Node.js（JavaScript运行时）是后端Web应用程序最流行的技术之一，但它不可能是所有任务的最佳工具。对于任何类型的数据密集型任务、预测分析和机器学习，您可以选择Python作为您的编程语言；SageMaker等专用平台更适合大型项目。借助无服务器基础架构，您可以选择Node.js用于常规后端API，选择Python用于数据密集型工作，而无需任何额外的操作工作。显然，这可能会给您的团队带来代码维护和团队管理方面的额外工作。开发团队的独立性不同的开发者或团队可以在各自的微服务上工作，修复bug，扩展功能等，互不干扰。例如，AWSSAM和Serverless框架等工具可以让开发人员在操作层面更加独立。AWSCDK框架的出现，可以让开发团队拥有更高的独立性，同时又不影响高质量和运维标准。无服务器中微服务的缺点难以监控和调试在无服务器带来的众多挑战中，监控和调试可能是最困难的。因为计算和存储系统分布在许多不同的功能和数据库中，更不用说队列和缓存等其他服务，这些问题都是微服务本身造成的。但是，已经有专业的平台可以解决所有这些问题。那么，专业的开发团队是否应该引入这些专业的平台，也要根据成本来考虑。可能经历更多的冷启动当FaaS平台（例如Lambda）需要启动一个新的虚拟机来运行功能代码时，就会发生冷启动。如果您的函数工作负载对延迟敏感，您很可能会遇到问题。因为冷启动会使总启动时间增加数百毫秒到几秒，FaaS平台通常让microVM在请求完成后闲置一段时间，等待下一个请求，然后在10-60分钟后关闭（是的,变化很大）。结果：您的函数执行得越频繁，microVM就越有可能为传入请求启动并运行（避免冷启动）。当我们将应用程序分布在成百上千个微服务中时，我们可能会将调用时间分散到每个服务中，从而导致每个函数的调用频率降低。注意“可能会分散呼叫”。根据业务逻辑和系统行为方式，这种负面影响可能很小或可以忽略不计。其他缺点微服务概念本身还有其他固有缺点。这些与Serverless没有本质关系。尽管如此，每个采用这种架构的团队都应该谨慎行事，以降低其潜在的风险和成本。确定服务边界并不容易，并且会导致架构问题。更广泛的攻击面服务编排成本问题同步计算和存储（在需要时）并不容易高性能和可扩展性微服务在无服务器中的挑战和最佳实践微服务在无服务器中应该有多大？人们在理解Serverless时，很容易将“函数即服务（FaaS）”的概念与编程语言中的函数语句混淆。我们目前处于无法划清界限的时期，但经验表明，使用非常小的无服务器函数并不是一个好主意。当你决定将一个（微）服务拆分成独立的功能时，你将不得不面对无服务器的困境。因此，提醒一下，只要有可能，最好将相关逻辑放在一个函数中。当然，决策过程中还要考虑拥有独立微服务的优势。你可以这样想：“如果我把这个微服务分拆出来……它会让不同的团队独立工作吗？它可以微调吗？你能从精细的资源分配或选择性的可扩展性中获益吗？如果不能，你应该考虑将此服务与另一个需要类似资源、上下文关联、执行相关Workloads的服务捆绑在一起，通过组合Serverless函数实现松耦合架构，微服务协调的方式有很多种，当需要同步通信时，可以直接调用（即AWSLambdaRequestResponse调用方法），但这会导致架构高度耦合，更好的选择是使用LambdaLayers或HTTPAPI，可以让以后的修改或迁移服务对客户端没有影响。对于接受异步通信模型，我们有几个选项，例如队列(SQS)、主题通知(SNS)、事件桥或DynamoDB流。跨组件隔离理想情况下，微服务不应向消费者公开细节。像Lambda这样的无服务器平台提供了一个API来隔离函数。但这本身就是实现细节的泄漏，理想情况下我们会在函数之上添加一个与HTTPAPI无关的层，使其真正隔离。使用并发限制和节流策略的重要性为了减轻DDoS攻击，在使用AWSAPIGateway等服务时，为每个面向公众的端点设置单独的并发限制和节流策略非常重要。此类服务一般会在云平台中设置一个全局的整个区域的并发配额。如果您没有基于端点的限制，攻击者只需将一个端点作为目标即可耗尽您的配额并在该区域破坏您的整个系统。原文链接本文为阿里云原创内容，未经许可不得转载。
