“Serverless 能取代微服务吗？” 这是知乎上 Serverless 分类的高热话题。java
有人说微服务与 Serverless 是相背离的，虽然咱们能够基于 Serverless 后端来构建微服务，但在微服务和 Serverless 之间并不存在直接的路径。程序员
也有人说，由于 Serverless 内含的 Function 能够视为更小的、原子化的服务，自然地契合微服务的一些理念，因此 Serverless 与微服务是天做之合。数据库
立刻就要 2021 年了，Serverless 是否终将取代微服务？从微服务到 Serverless 须要通过怎样的路径？ 在咱们深刻探讨细节以前，先别急着“站队”，不妨先基于你团队的实际状况，真实的去思考是否适合使用微服务，千万不要由于 "这是趋势 "而去作选择。编程
微服务在 Serverless 中的优点后端
Serverless缓存
1.可选择的可扩展性和并发性
Serverless 让管理并发性和可扩展性变得容易。在微服务架构中，咱们最大限度地利用了这一点。每个微服务均可以根据本身的需求对并发性/可扩展性进行设置。从不一样的角度来看这很是有价值：好比减轻 DDoS 攻击可能性，下降云帐单失控的财务风险，更好地分配资源......等等。架构
2.细粒度的资源分配
由于可扩展性和并发性能够自主选择，用户能够细粒度控制资源分配的优先级。在 Lambda functions 中，每一个微服务均可以根据其需求，拥有不一样级别的内存分配。好比，面向客户的服务能够拥有更高的内存分配，由于这将有助于加快执行时间；而对于延迟不敏感的内部服务，就能够用优化的内存设置来进行部署。并发
这一特性一样适用于存储机制。好比 DynamoDB 或 Aurora Serverless 数据库就能够根据所服务的特定（微）服务的需求，拥有不一样级别的容量分配。框架
3.松耦合
这是微服务的通常属性，并非 Serverless 的独有属性，这个特性让系统中不一样功能的组件更容易解耦。less
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 中微服务应该多大？
人们在理解 Servrless 时，" 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 等服务时，必定要为每一个面向公众的终端设置单独的并发限制和节流策略。这类服务通常在云平台中会为整个区域设置全局并发配额。若是你没有基于端点的限制，攻击者只须要将一个单一的端点做为攻击目标，就能够耗尽你的配额，并让你在该区域的整个系统瘫痪。
推荐阅读
看完三件事❤️
若是你以为这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙：
点赞，转发，有大家的 『点赞和评论』，才是我创造的动力。
关注公众号 『 Java斗帝 』，不按期分享原创知识。
同时能够期待后续文章ing🚀