当前位置：首页 > news >正文

软件架构：从传统单体到现代微服务的技术演变

news 来源：原创 2025/5/12 1:25:27

1.引言

在软件开发中，架构设计不仅仅是程序员的技术任务，它更是一个项目成功的关键。无论是小型应用还是大型分布式系统，软件架构都直接影响着系统的可维护性、可扩展性、性能和稳定性。理解软件架构的必要性，能够帮助开发人员做出正确的技术决策，从而避免后期出现技术债务、性能瓶颈或是开发效率低下等问题。

对于程序开发人员来说，了解架构模式能够：

优化开发效率：合理的架构模式能够规范开发流程，提高团队协作效率。
降低系统复杂性：随着项目的规模扩大，系统的复杂性也会增加。架构设计的核心就是分解复杂性，使系统更易于维护和扩展。
提高系统灵活性：架构设计可以帮助团队应对需求变化。通过模块化、分层架构等设计，可以确保系统在面对新需求时能够灵活应变。
减少风险：在系统设计初期做出正确的架构决策，能够避免项目后期技术上的重构和返工，降低开发成本。

2.架构类型概述

在现代软件开发中，不同的架构模式适用于不同规模和业务需求的项目。以下是六种常见的架构模式：

1. 单体架构 (Monolithic Architecture)

单体架构是指将所有功能和模块集中在一个应用中运行，通常作为一个单独的进程部署。

特点：

所有模块紧密耦合，通常共享数据库。
开发简单，适合初期小型项目。
随着功能增加，代码会变得难以维护。

2. 垂直架构 (Vertical Architecture)

垂直架构将大型应用按照业务拆分成多个相对独立的小型应用，但每个应用仍然是单体架构，且不直接通信。

特点：

各模块之间没有明确的通信协议。
每个模块可以独立部署，但不具备微服务的灵活性。
适用于快速拆分已有单体架构，减少冗余。

3. SOA架构 (Service-Oriented Architecture)

SOA架构将应用划分为多个独立服务，每个服务负责独立的业务功能，并通过企业服务总线（ESB）进行集成。

特点：

服务之间通过ESB进行通信。
模块化拆分，但可能引入性能瓶颈。
通常适用于较大的企业级系统。

4. 微服务架构 (Microservices Architecture)

微服务架构将应用拆分为多个小型、独立部署的服务，每个服务负责单一业务功能，服务之间通过轻量级协议（如REST、RPC）进行通信。

特点：

每个服务独立部署和扩展。
服务之间的通信相对轻量级。
可以使用不同技术栈，灵活性高。

5. 服务网格架构 (Service Mesh Architecture)

服务网格架构是一种用于微服务架构的解决方案，用于管理和优化服务间的通信、流量控制、监控和安全等。

特点：

通过独立的网格层（如Istio）管理服务间的流量。
支持细粒度的流量控制、熔断和负载均衡。
增强了微服务的可观测性和安全性。

6. 云原生架构 (Cloud-Native Architecture)

云原生架构采用容器化、微服务、服务网格等技术，通过自动化和弹性扩展来管理应用。它专门为云环境优化，支持快速部署和弹性伸缩。

特点：

强调容器化和微服务。
使用持续集成和交付（CI/CD）提高开发效率。
完全依赖云平台，具有自动扩展能力。

3.单体架构概述

在计算机软件工程的早期阶段，单体架构模式普遍应用于应用程序的开发实践中。此模式的特点是将应用程序的各个功能模块集中整合至一个统一的代码库中，并在同一进程环境下进行部署。这种设计理念的根源在于，在技术和业务需求较为简单的背景下，通过减少模块间的复杂交互，旨在简化开发和部署流程。
单体架构意味着代码被部署并作为单个节点上的单个进程运行，即all in one。
接下来以一个电商项目为例，将分析单体架构下系统的组成。
在单体架构中，电商系统会被设计为一个单独的应用，所有的功能模块（如用户管理、商品管理、订单管理以及支付管理）都集中在一起，作为一个单一的进程运行，具体如下图所示：
在这里插入图片描述

4.垂直架构概述

单体架构随着业务越来越复杂、团队规模越来越大，Git上提交的代码也越来越多，搞到最后，代码集成十分困难，没办法只能将不同分支上的代码独立运行，因此逐渐出现了业务分化，在时间的推动下，一个大的系统就变成了多个子系统共同运行，系统架构就变成了下图样貌。
在这里插入图片描述
在垂直架构下，电商应用将每个业务模块（例如，用户、商品、订单）拆分为独立的服务，每个模块仍然是单体架构。各模块可以独立部署和扩展，减轻单体架构的压力。
通过这种方式，能够让团队分工更加明确，并且多个子系统之间互不影响，提升了系统的分区容错性，而且使得系统吞吐量进一步身高。

5.SOA架构概述

经过子系统的演变后，整个系统就变成了分布式系统了，每个子系统负责不同的职责，但是这种子系统拆分存在致命的缺陷。即，在多个子系统之间，就好似一个项目里的多个模块，产生了强耦合性，系统之间的配合和通信，完全靠写死对方子系统的IP来完成调用，一旦某个子系统出现故障，依旧存在整个系统全面瘫痪的风险。
而在SOA架构中，将电商系统拆分为多个业务服务，每个服务通过ESB进行通信，具体如下图所示：
在这里插入图片描述

6.微服务架构

虽然ESB可以解决多个子系统之间的通信问题，但是ESB存在性能瓶颈，且服务之间的通信较为复杂，后面就诞生了微服务。
微服务架构通过将单体应用拆分为多个独立的服务，针对不同的业务领域进行划分和优化，可以更加灵活地应对不同服务的并发需求。这种方式不仅提升了系统的可扩展性，还使得各个服务的资源得到了更加合理的利用。
此外，微服务架构还带来了更高的灵活性和可维护性。每个服务独立开发、测试、部署和维护，可以大大降低单个服务出现故障时对整个系统的影响。而且，服务之间的解耦使得在未来的业务发展中，可以根据不同的业务需求和并发量动态调整各个服务的部署和资源分配，进而实现更高效的性能优化和负载均衡。具体针对电商系统的微服务架构图如下所示：
在这里插入图片描述

7.服务网格架构

在微服务架构中，随着服务的增加，服务间的通信变得越来越复杂，服务发现与注册、负载均衡、服务熔断和降级、安全与故障恢复等代码和业务逻辑耦合在一起，并且每个微服务都要实现相同的服务注册与发现，熔断等基础设施层代码，同时也增加了维护的成本。因此便出现了服务网格架构。
服务网格是一种基础设施层，用于管理和优化微服务之间的通信、流量控制、负载均衡、监控、安全和故障恢复。它通过在微服务和它们之间的通信渠道上增加一层抽象，帮助开发者专注于业务逻辑，而将通信和基础设施相关的复杂问题交给服务网格来处理。具体如下图所示：
在这里插入图片描述
服务网格的基本组成包括两个重要组件：

数据面（Data Plane）：
数据面是服务网格的核心，它通过“Sidecar”代理的形式部署在每个微服务实例旁边，用于处理服务间的流量。每个微服务实例都会有一个 sidecar 代理，负责拦截进出服务的所有流量，并在代理中执行如负载均衡、流量管理、熔断、日志记录、指标收集等任务。
- Sidecar Proxy：它是数据面的核心组成部分，作为每个服务的代理，处理所有网络通信。典型的 sidecar 代理是 Envoy，它能够拦截和处理服务之间的所有请求。
控制面（Control Plane）：
控制面负责管理和配置服务网格的数据面。它提供了对流量管理、服务发现、配置和策略执行的控制。控制面协调 sidecar 代理的配置，通常包括健康检查、流量路由、熔断策略等。