《微服务架构之前：传统架构的演进与特点》
一、单体架构
在微服务架构出现之前，单体架构是一种广泛应用的软件架构模式。
1、结构特点
图片来源于网络，如有侵权联系删除
- 单体架构将一个应用程序构建为一个单一的、可执行的单元，它包含了所有的业务逻辑、数据访问层、用户界面等功能，一个企业级的电商应用，从用户登录注册、商品展示、购物车管理到订单处理、支付等所有功能都集成在一个庞大的代码库中，这个代码库可能由多个模块组成，但最终会被编译和部署为一个整体的应用程序。
- 在技术选型上，单体架构往往使用单一的技术栈，整个应用可能都基于Java EE技术，使用Servlet、JSP等技术构建用户界面，使用EJB（Enterprise JavaBeans）进行业务逻辑处理，使用JDBC（Java Database Connectivity）进行数据访问，这种单一技术栈的优势在于便于开发团队掌握和管理，因为开发人员只需要熟悉一种技术体系就可以对整个应用进行开发和维护。
2、部署与扩展
- 部署方面，单体架构的应用通常作为一个整体进行部署，这意味着每次更新，无论是一个小的功能改进还是一个大的功能模块的添加，都需要重新部署整个应用，一个电商应用如果只是对商品展示页面的样式进行了微调，也需要将包含用户登录、订单处理等所有功能的整个应用重新部署到服务器上。
- 在扩展方面，单体架构只能进行整体的垂直扩展，也就是说，如果应用面临性能问题，只能通过增加服务器的硬件资源，如CPU、内存等来提升整个应用的性能，这种扩展方式不够灵活，因为可能应用中只有某个功能模块（如订单处理模块在促销期间）面临高并发压力，但是由于单体架构的限制，不得不对整个应用进行资源扩充。
3、开发与维护挑战
- 随着应用规模的增大，单体架构的开发变得越来越复杂，由于所有功能都集成在一起，不同功能模块之间的代码耦合度很高，在电商应用中，订单处理模块可能会直接调用商品管理模块中的数据结构和方法，这种紧密的耦合使得在修改一个模块时很容易影响到其他模块，当开发团队规模较大时，多个开发人员同时在一个庞大的代码库上工作，容易产生代码冲突，合并代码的难度也会增加。
- 维护方面，单体架构的应用在出现问题时定位困难，由于所有功能交织在一起，当出现性能问题或者业务逻辑错误时，很难快速定位到问题所在的具体代码段，由于技术栈的单一性，当需要引入新的技术或者框架来提升某个功能的性能或者实现新的业务需求时，可能会受到整个应用技术体系的限制，改造难度较大。
图片来源于网络，如有侵权联系删除
4、局限性示例
- 以一个大型的金融系统为例，它最初采用单体架构构建，随着业务的发展，需要添加新的金融产品和服务，如外汇交易功能，在单体架构下，开发人员需要在原有的庞大代码库中添加新的业务逻辑代码，这不仅可能会影响到原有的储蓄、贷款等业务逻辑，而且由于整个应用的复杂性，新功能的开发和测试周期会很长，当外汇交易功能上线后，如果出现性能问题，很难单独对这个功能进行优化和扩展，因为它与整个金融系统的其他功能紧密耦合在一起。
二、分层架构
分层架构是在单体架构基础上的一种演进，它试图通过将应用按照功能进行分层来解决单体架构中的一些问题。
1、分层原则
- 典型的分层架构包括表示层、业务逻辑层和数据访问层，表示层负责处理用户界面的展示和交互，例如在一个Web应用中，它负责生成HTML页面、接收用户输入等操作，业务逻辑层包含了应用的核心业务逻辑，如电商应用中的商品定价算法、订单处理流程等，数据访问层则负责与数据库等数据存储进行交互，执行数据的查询、插入、更新和删除操作。
- 这种分层的方式使得各层之间有了相对清晰的职责划分，在一个企业资源规划（ERP）系统中，表示层只需要关注如何向用户展示数据和接收用户操作指令，而不需要关心数据是如何存储和业务逻辑是如何处理的，业务逻辑层可以独立于表示层和数据访问层进行开发和测试，它可以根据业务需求的变化进行灵活的调整，而不用担心会直接影响到用户界面或者数据存储。
2、优势与改进
图片来源于网络，如有侵权联系删除
- 相比于单体架构，分层架构在一定程度上降低了代码的耦合度，各层之间通过定义好的接口进行通信，例如业务逻辑层通过接口向数据访问层请求数据，而数据访问层实现这个接口来提供数据，这样，当数据存储方式发生变化时，只要数据访问层的接口不变，业务逻辑层就不需要进行大量的修改。
- 在开发方面，分层架构使得不同的开发团队可以专注于不同的层，前端开发团队可以专注于表示层的开发，后端开发团队可以专注于业务逻辑层和数据访问层的开发，这提高了开发效率，并且可以更好地利用开发人员的专业技能。
3、仍然存在的问题
- 尽管分层架构有一定的改进，但它仍然存在一些局限性，从整体上看，分层架构仍然是一个单体应用，只是内部结构更加清晰，在部署方面，它依然需要将整个应用作为一个整体进行部署，这意味着如果要更新业务逻辑层中的某个小功能，仍然需要重新部署表示层和数据访问层等整个应用。
- 在扩展方面，分层架构也面临与单体架构类似的问题，虽然可以在各层内部进行一定程度的优化，但是对于整个应用的横向扩展能力仍然有限，在一个高并发的电商促销场景下，如果业务逻辑层中的订单处理模块面临巨大的负载压力，分层架构很难单独对这个模块进行水平扩展，仍然需要考虑整个应用的资源扩充。
在微服务架构出现之前，单体架构和分层架构在软件项目开发中占据主导地位，它们为软件的构建和运行提供了一定的解决方案，但也存在着诸多局限性，这些局限性促使了微服务架构的诞生。
评论列表