《微服务架构之前：传统架构的演进与特点》
一、单体架构
在微服务架构兴起之前，单体架构是一种广泛应用的软件架构模式。
图片来源于网络，如有侵权联系删除
1、结构特点
- 单体架构将整个应用程序构建为一个单一的、可执行的单元，所有的业务逻辑，包括用户界面、业务逻辑层、数据访问层等，都被打包在一个单一的代码库中，一个简单的企业资源管理（ERP）系统可能将订单管理、库存管理、员工管理等功能的代码都放在一个大的项目中，这个项目可能是一个巨大的Java Web应用，所有的功能模块共享同一个数据库连接、同一个服务器进程。
- 在部署方面，单体应用通常作为一个整体进行部署，这意味着当对应用中的任何一个小功能进行修改时，如对订单管理模块中的一个小功能进行优化，整个应用都需要重新构建和部署，对于大型的单体应用来说，这个构建和部署过程可能会非常耗时，尤其是在需要频繁更新的场景下。
2、技术选型与集成
- 在单体架构中，技术选型往往是统一的，如果选择了Java作为开发语言，那么整个应用的各个功能部分都将使用Java相关技术，使用Spring框架构建业务逻辑层，使用JDBC或者Hibernate来进行数据访问，这种统一的技术选型在一定程度上便于开发团队的管理和协作，因为开发人员只需要熟悉一套技术栈。
- 这种集成方式也存在问题，随着应用功能的不断增加，不同功能模块之间的耦合度会越来越高，库存管理模块可能直接调用订单管理模块中的一些方法来获取订单数量，以调整库存水平，这种紧密的耦合使得当一个模块需要进行重大变更时，很可能会影响到其他模块的正常运行。
3、可扩展性挑战
- 单体架构在应对小规模业务场景时可能表现良好，但随着业务的增长和用户数量的增加，可扩展性成为一个巨大的挑战，当需要对应用进行水平扩展时，由于整个应用是一个整体，只能通过复制整个应用实例来增加处理能力，这可能会导致资源的浪费，因为可能只有应用中的某个功能模块面临高负载，而其他模块的资源使用率较低，在一个电商系统中，促销活动期间订单管理模块可能面临巨大的流量压力，而产品展示模块的负载相对较低，但在单体架构下，为了满足订单管理模块的需求而扩展整个应用实例，会造成产品展示模块所在服务器资源的闲置。
图片来源于网络，如有侵权联系删除
4、开发与维护
- 在开发方面，由于单体架构的高耦合性，大型团队在开发过程中可能会遇到很多冲突，不同的开发人员可能会同时修改同一个代码文件中的不同功能部分，导致代码合并困难，随着代码库的不断增大，代码的可读性和可维护性会逐渐降低，对于新加入团队的开发人员来说，理解整个庞大的单体应用的业务逻辑和代码结构是一个艰巨的任务。
- 在维护方面，当应用出现问题时，定位问题的根源可能会非常困难，由于所有的功能模块交织在一起，一个模块的故障可能会在整个应用中产生连锁反应，很难准确判断是哪个具体的功能或者代码片段导致了问题的发生。
二、分层架构
分层架构是在单体架构基础上的一种演进，旨在一定程度上解决单体架构的耦合问题。
1、分层理念
- 分层架构将应用程序按照功能划分为不同的层次，典型的分层包括表示层、业务逻辑层和数据访问层，表示层负责处理用户界面的展示和交互，如接收用户的输入并将结果展示给用户；业务逻辑层包含了应用的核心业务逻辑，如订单处理、用户认证等；数据访问层则负责与数据库或其他数据源进行交互，如执行SQL查询、存储数据等，这种分层方式使得各层之间的职责相对明确。
- 在一个Web应用中，用户通过浏览器访问表示层，请求登录，表示层将登录请求传递给业务逻辑层，业务逻辑层对用户输入的用户名和密码进行验证逻辑处理，然后通过数据访问层查询数据库中存储的用户信息来判断登录是否成功。
图片来源于网络，如有侵权联系删除
2、解耦与复用
- 分层架构在一定程度上实现了解耦，各层之间通过定义好的接口进行通信，使得某一层的改变不会直接影响到其他层的实现，业务逻辑层可以在不影响表示层和数据访问层的情况下进行内部逻辑的优化，分层架构有利于代码的复用，业务逻辑层的一些通用功能，如数据加密、验证逻辑等，可以被多个表示层的模块所复用。
3、局限性
- 尽管分层架构有一定的解耦效果，但它仍然存在局限性，从宏观上看，整个应用仍然是一个单体，只是内部结构更加清晰，当应用规模进一步扩大时，分层架构可能无法很好地应对，在一个大型企业应用中，业务逻辑层可能会变得非常庞大，包含众多不同业务功能的逻辑，虽然分层但各业务功能之间的耦合仍然难以避免，分层架构在应对分布式场景和多技术栈融合方面存在困难，如果要将部分业务逻辑迁移到新的技术平台或者进行分布式部署，由于整个应用的整体性，操作起来会比较复杂。
在微服务架构出现之前，单体架构和分层架构在不同的业务场景下都发挥了重要的作用，但随着互联网业务的快速发展、应用规模的不断扩大以及对灵活性和可扩展性的更高要求，微服务架构应运而生，以解决传统架构所面临的诸多问题。
评论列表