在上一篇文章如何理解单体架构中,回顾了单体架构的优缺点。很明显,这种架构的问题随着应用程序的增长而出现。为了克服这些挑战,可以使用微服务架构。然而,它不是灵丹妙药。这种类型的架构有其自身的优点和缺点。


微服务架构回顾

#yyds干货盘点#——如何理解微服务架构_应用程序


       一个应用程序被分成多个小服务(用户服务、飞行服务、计费服务等),负责特定的有限范围。它们中的每一个都在自己的数据库上运行,并具有首选特征。UI 通常执行对网关的请求。该网关负责将请求路由到特定的服务。它还可以包含交叉问题,例如身份验证。每个服务都可以单独支持、管理和部署。但是,它们应该以某种方式相互通信。不同的通信方式不在本文讨论范围内,将单独审查。


微服务架构的优势
  • 高内聚,低耦合。除通信点外,每个服务都是独立的。因此,每个组件都可以由不同的团队开发。错误和功能可以在单个服务中修复和部署。由于服务的规模,部署时间很短。
  • 服务范围有限。这些服务通常很小。因此,它们通常更容易理解。调试过程和测试在单个服务范围内很简单。
  • 灵活性。服务可以在其自己的具有所需特征的数据库上运行。它可以是RDBMSNoSQL,两者都可以,也可以都不是。此外,服务可以用不同的编程语言编写。
  • 可扩展性。组件可以独立扩展和优化。性能特性没有限制。例如,一个应用程序可以有两个用户服务实例和十个飞行服务实例。RDBMS数据库可以被替换为用于特定服务的单一用途的NoSQL数据库。因此,微服务对于大型应用程序也具有成本效益。
  • 尖端技术。微服务很小。因此,可以进行实验来验证某些想法或解决方案。它们可以快速重写。此外,迁移到新平台版本可能非常简单。例如,从Java 8迁移到Java 11
  • 高速发展。许多框架都经过优化以用作微服务(例如Spring Boot)。另一个优势与CI/CD 管道有关。服务很小,因此管道很快。


微服务架构的缺点
  • 调试。在单个组件范围内工作时,一切都很简单。然而,整个架构是复杂的。单个请求可以对多个服务进行操作。很难跟踪它并理解系统。数据流通常难以理解,尤其是对于新的团队成员。
  • 测试。由于分布式组件,测试具有挑战性。
  • 部署。服务可以单独部署。然而,他们通常以某种方式交流。必须严格定义服务之间的交互契约。一项服务的更改不应破坏其他服务。
  • 沟通。每个组件都可以由不同的团队开发。因此,必须进行更改。它带来了通信开销。
  • 基础设施开销。另一方面,数据位于不同的地方。另一方面,来自一项服务的业务预期数据应该用于另一项服务。应该以某种方式处理服务之间的交互。它通常是服务之间的数据复制或附加调用。
  • 交叉关注。每个服务都应该实现安全、日志记录、监控、配置等。


总结

      综上所述,微服务架构给小项目带来了额外的复杂性和更高的成本。但是,对于大型应用程序,微服务可以具有成本效益,可以影响高系统性能并加快开发速度。