用于云中应用程序开发的微服务架构是一种将软件应用程序构建为小型(“微”)松散耦合服务集合的架构方法。
架构中的每个服务代表特定的业务能力或功能,例如将库存项目添加到数据库或检查新客户的信用。
它们通常作为单独的进程运行,通过 API 或轻量级协议与其他服务进行通信。
微服务源于面向服务的架构和构建更好的应用程序的需求。
由于一些充分的理由,它是构建全新应用程序的最受欢迎的方法。喜欢使用微服务架构,因为它提供松散耦合和隔离。
优点
服务被设计为松散耦合。它们可以独立运行,而不直接依赖于其他服务中的内部实现细节。
它们允许团队单独开发、部署和扩展服务,从而提高敏捷性。额外的好处是增强弹性,因为它们独立运行。
这说明了独立性和隔离性的好处,这与松耦合直接相关。每个服务都可以独立开发、测试、部署和扩展。
说实话,这在出现时并不具有革命性。它更多的是架构最佳实践的演变,始于 20 世纪 70 年代的结构化开发,然后是面向对象的开发、基于组件的开发、服务的使用和微服务。
缺点
当然,开发过程中没有免费的午餐。每种方法、工具、语言和架构都有必须考虑的优缺点。这有时会在炒作中被忽视。
让我们探讨一下微服务架构的一些缺点。
最大的一个是复杂性。与更单一的架构相比,微服务引入了更高级别的复杂性。系统被分解为众多的服务;架构变得更加复杂,理解不同服务之间的交互可能具有挑战性。
当您考虑到我们还要处理复杂的分布式系统作为部署微服务的平台时,这就变得更加困难。这是几乎所有企业内构建和部署多云的副产品。
分配是另一个考虑因素。对于微服务,服务之间的通信通常通过网络进行,从而导致延迟、网络故障和压力增加。
出于这个原因,必须在部署基于微服务的应用程序后升级网络,它并不便宜。
数据管理也比较复杂。微服务可能有自己的数据库或数据存储,使各种服务之间的数据一致性变得复杂。通常需要付出额外的努力来维护数据完整性,而企业在遭受损失之前并不了解这一点。
这是可以解决的,但需要的资源比大多数人理解的要多得多。
服务依赖可能会很痛苦。当微服务通过 API 进行交互时,一项服务的更改可能会对其他服务产生影响。
结果版本控制挑战和潜在的兼容性问题,尤其是在升级或服务更改期间。
最后是资源开销。对于大多数已部署的应用程序来说,运行多个微服务实例将比单个整体应用程序消耗更多的资源。
这可能会增加基础设施成本,特别是如果管理不当的话。
云开发人员和架构师以近乎宗教般的热情对待微服务架构。
当然,它们并不是适合所有应用的正确方法,并且在许多情况下,它们会成为强制配合。
当对已经迁移到云或正在迁移到云的应用程序进行现代化改造时,它们需要的资源比应有的要多得多。这是由于提到的许多缺点造成的。
也就是说,它们通常是可以使用的示例性架构。
但是,您在做出决定之前必须考虑许多权衡,并且必须关注核心应用程序要求。
不幸的是,我们没有考虑很多我们应该考虑的事情,并且由于核心应用程序需求的方法不匹配而导致效率低下。
与任何其他方法一样,微服务应该只在上下文中考虑,同时牢记此架构的目的,何时应该使用,何时不应该使用。
原文始发于微信公众号(网络研究院):微服务架构的缺点
- 左青龙
- 微信扫一扫
- 右白虎
- 微信扫一扫
评论