转载

3分钟干货之微服务架构的局限性

虽然微服务是降低整体结构的最佳方式。然而，它有其自身的一些缺点。但在得出任何结论之前，让我们来看看其中的一些。

1.开发环境超载

随着应用程序及其数据库的增长，代码库也在不断扩展。随着针对每个微服务的代码扩展，它会使每个加载的应用程序的开发环境过载。这可能导致生产力的重大延迟。

单功能微服务的开发和部署并非易事。使用多种技术并创建API来集中系统是一项挑战。这需要一个经验丰富的DevOps团队。采购这样一个经验丰富的DevOps团队对于维护基于微服务的应用程序的复杂性至关重要。

3.增加资源和网络使用

由于多个组件协同工作，因此在某种程度上彼此进行通信非常重要。此通信将导致网络使用量增加。这需要高速可靠的网络连接。此外，运行这些应用程序的费用也会增加。所有服务都单独运行，增加了运营成本。

4.测试

测试应用程序可能具有挑战性，因为有单独的组件。与单片应用程序相比，微服务需要更长的时间进行测试，并且在出现任何错误时更加复杂。有时，由于测试最终会影响整个应用程序，可能会导致延迟。

5.安全

在Web应用程序方面，安全性至关重要。使用微服务，实现这一点很困难。当存在独立模块的集群时，每个模块都需要遵守为整个系统定义的认证和授权规范。

除此之外，每个模块可能与其他模块通信，跟踪数据流变得非常困难。需要其他措施，例如具有负载平衡的API网关，以确保行为一致。这些额外的步骤导致每个微服务的开销。

6.应用程序的复杂性

由于微服务是独立组件，因此每个微服务通常都有一个最适合其需求的技术堆栈。例如，机器学习模块可能使用python堆栈，而计量服务可能使用Java堆栈，UI服务可能使用MEAN堆栈。这会导致复杂性，因为资源池和管理和构建新功能所需的技能将非常高。

7.高初始投资

微服务独立运行，它们需要独立的容器或资源来运行它们。每个项目可能有很多微服务一起工作，需要更高的投资来设置包括微服务，安全容器，负载平衡器，API网关等的所有集群。

原文 https://segmentfault.com/a/1190000018951622

正文到此结束

所属分类：编程技术软件架构

本站定位：个人技术类博客

本站作用：写博客、记日志、闲聊扯淡鼓捣技术。