《微服务架构之前：传统架构的演进与特点》
在微服务架构兴起之前，企业应用架构主要经历了从单体架构到分层架构等多种形式的发展。
一、单体架构
1、架构特点
- 单体架构将所有的业务功能集成在一个单一的、大型的应用程序中，这个应用程序通常包含多个模块，例如在一个企业资源规划（ERP）系统中，可能会有财务模块、库存管理模块、人力资源模块等，但它们都被打包成一个可执行的单元，从代码结构上看，所有的功能代码都在一个代码库中，模块之间的调用是通过函数或者类的内部调用实现的。
图片来源于网络，如有侵权联系删除
- 在部署方面，单体应用是作为一个整体进行部署的，这意味着，哪怕只是对其中一个小功能进行修改，例如修改财务模块中的一个报表功能，整个应用都需要重新构建和部署。
- 单体架构在数据存储上通常也采用集中式的数据库，使用一个关系型数据库来存储所有模块相关的数据，各个模块通过数据库的表结构和关联关系来共享和交互数据。
2、存在的问题
- 随着业务的发展，单体架构的应用会变得越来越庞大和复杂，代码库的规模不断增大，导致开发人员在进行功能开发和维护时变得困难重重，一个新加入的开发人员可能需要花费很长时间来熟悉整个代码库的结构和业务逻辑，才能进行有效的开发工作。
- 可伸缩性差，当业务量增加，需要对应用进行扩展时，由于单体架构是整体部署的，无法针对某个特定的功能模块进行单独的扩展，如果库存管理模块的业务量突然增大，需要更多的计算资源，但在单体架构下，只能对整个应用进行扩展，这可能会导致资源的浪费，因为其他模块可能并不需要额外的资源。
- 技术栈的更新换代困难，如果企业想要采用新的技术框架或者编程语言来提升应用的性能或者开发效率，由于整个应用是一个整体，很难在不影响整个应用运行的情况下进行技术的更新，想要将部分模块从传统的Java EE技术转换为Spring Boot微服务框架，在单体架构下几乎是一个非常艰巨的任务。
图片来源于网络，如有侵权联系删除
二、分层架构
1、架构特点
- 分层架构是对单体架构的一种改进，它将应用按照功能的不同进行分层，典型的分层架构包括表示层、业务逻辑层和数据访问层，表示层负责与用户进行交互，展示数据和接收用户的输入，业务逻辑层包含了应用的核心业务逻辑，例如在一个电商应用中，订单处理、商品管理等业务逻辑都在这一层，数据访问层则负责与数据库等数据存储进行交互，执行数据的增删改查操作。
- 各层之间通过接口进行通信，这种分层的设计使得代码结构更加清晰，不同层的开发人员可以专注于自己的任务，表示层的开发人员可以专注于用户界面的设计和交互逻辑，而不必过多关注业务逻辑的实现；业务逻辑层的开发人员可以独立地开发和测试业务逻辑，而不用担心数据的存储和表示层的展示问题。
- 在部署方面，分层架构虽然仍然是作为一个整体进行部署的，但相比于单体架构，它在一定程度上提高了代码的可维护性和可扩展性。
2、局限性
图片来源于网络，如有侵权联系删除
- 尽管分层架构在一定程度上改善了单体架构的一些问题，但它仍然无法从根本上解决可伸缩性的问题，当业务规模扩大时，整个应用还是需要作为一个整体进行扩展或者升级。
- 不同层之间的耦合度虽然通过接口进行了一定的降低，但仍然存在，如果业务逻辑层的某个业务逻辑发生了变化，可能会影响到表示层和数据访问层与之相关的部分，分层架构对于复杂业务场景下的模块复用性提升有限，各个模块仍然紧密地依赖于整个应用的架构体系。
随着互联网业务的快速发展和业务需求的日益复杂，传统架构在应对高并发、快速迭代、灵活部署等方面的局限性愈发明显，这就促使了微服务架构的诞生，以解决传统架构所面临的诸多挑战。
评论列表