你真的理解什么是架构吗？

你真的理解什么是架构吗？

一名合格的程序员，总绕不开对“架构”这两个字的讨论，一千个人心中有一千个哈姆雷特，每个人对架构都有自己的理解，有人认为架构就是框架，也有人认为架构就是项目的各大组件集合，作为一名工作多年，轻微秃顶的架构师，在工作和生活中经常会有同事和朋友问我，架构是什么？本文将和大家深入探讨以及帮助各位理解架构的核心观念

一、什么是软件架构？

软件架构相当于软件系统的"骨架"，它定义了系统的核心结构、组件间的关系以及设计原则。就像建筑设计中工程师需要规划房屋的承重墙、管道布局和空间，软件架构师同样也需要为系统设计清晰的模块边界、数据流向和技术选型。例如，一个电商平台多采用"微服务架构"，将订单、支付、库存等功能拆分为独立服务，通过API通信实现解耦，想要深入理解架构，首先要争取区分下面的几个概念。

二、核心概念

1. 系统与子系统

​​系统（System）​​：

泛指由一群有==关联==的个体组成，根据某种==规则==运作，==能完成==个别元件不能单独完成的工作的群体。（维基百科）

根据维基百科对系统的解释，我们可以提炼出三个关键词

• 关联：个体与个体之间必须是有关联性的，没有关联性的个体无法组成一个系统。例如，将一台主机和键盘放在一起无法组成一个系统，只有将主机、键盘、鼠标、显示器、电源线等组装在一起才能成为一台完整的电脑（甚至还要插上网线）。
• 规则：系统的每个个体按照规则为系统服务，例如显示器负责展示电脑内容，主机负责任务处理，键盘负责将用户指令键入系统。
• 能力：系统能力远远大于个体能力之和，而是产生了新的能力，电脑让我现在坐在电脑前写博文，然而它这种能力不是单一的显示器、主机、键盘、所能实现的。

子系统（Subsystem）​​： 子系统也是由一群有关联的个体所组成的系统，多半是更大系统中的==一部分==（维基百科）

子系统和系统的定义一致，子系统之外一定存在一个更大的系统并且服务于这个系统

举例：

电商系统 = 用户子系统 + 商品子系统 + 订单子系统 + 支付子系统 操作系统 = 进程管理子系统 + 内存管理子系统 + 文件系统 ​​子系统​​：在Spring Cloud微服务架构中，用户服务子系统可能包含：

• 获取用户信息
• 创建用户
• ...

// 用户服务接口定义
public interface UserService {
    User getUserById(Long id);
    void createUser(User user);
    ...
}

2. 模块与组件

模块和组件的概念不太容易区分，也比较容易混淆，区分二者的关键在于从何种角度拆分。

模块：从功能逻辑上面拆分，得到的单元便是模块，关注功能内聚性，例如我们常见的用户模块、订单模块、支付模块。

举例 Maven项目中的用户模块（user-module）包含： 

​​组件（Component）​​：从物理角度拆分,可独立部署的物理单元，如nginx，rabbitmq，支付组件：

// 支付组件接口
interface PaymentComponent {
  processPayment(amount: number): Promise<PaymentResult>;
}
// 具体实现可以是支付宝组件或微信支付组件

​​区别​​：模块的修改需要重新编译整个系统，而组件可通过热插拔替换（如更换Redis客户端从Jedis改为Lettuce）。

三、架构与框架的本质差异

框架与架构在实际语境中常存在概念交叉，两者虽定义有别但具有强关联性，导致业界使用时存在混用现象，根据维基百科的定义来分析，框架和架构的区别在于框架关注的点是==规范==，而架构关注的是==结构==

1. 软件架构（Architecture）

​设计蓝图​​：定义系统的分层结构（表现层/业务层/数据层） ​​决策集合​​：包括选择RESTful API风格、采用CQRS模式等 ​​质量属性​​：保障可扩展性（通过模块化设计）、可靠性（通过集群部署） 示例：在DDD（领域驱动设计）架构中，通过限界上下文划分核心域与支撑域。

2. 开发框架（Framework）

​​实现工具​​：如Spring框架提供IoC容器、AOP等实现架构 ​​约束性​​：使用Vue框架必须遵循其组件生命周期：

export default {
  created() { /* 组件创建时执行 */ },
  mounted() { /* DOM挂载后执行 */ }
}

​​可替换性​​：一个MVC架构可以用Spring MVC或Express.js实现

3. 对比案例

	架构（MVC）	框架（Spring MVC）
​​关注点	​​ 如何分离业务逻辑与视图	如何实现控制器路由、视图解析
​​变更成本	​​ 重构需要调整多层结构	替换为Struts框架需重写控制器
​​抽象层级	​​ 逻辑分层（Model-View-Controller）	具体类库（DispatcherServlet等）

四、架构设计的核心价值

架构师常做的工作，主要包括：

• ​​复杂度治理​​：将单体系统拆分为微服务，每个服务代码量控制在2万行以内
• ​​质量提升​​：通过读写分离架构将数据库查询性能提升300%
• ​​ 变更隔离​​：修改用户模块时，订单模块无需重新测试（通过API版本控制）
• ​​ 技术决策​​：选择gRPC而非RESTful以实现服务间高效通信

五、总结

软件架构是指导系统构建的顶层设计哲学，它像城市规划一样需要平衡短期需求与长期发展。优秀的架构应该像乐高积木——模块标准化（统一接口规范）、组件可替换（支持灰度发布）、系统可观测（集成Prometheus监控）。 纵观软件发展历史，其实就是与复杂度做斗争的历史，架构的设计的目的主要是为了解决复杂度带来的问题，架构设计的初心是为了高度解耦，很多朋友为了追求高大上和成就感，经常往项目中引入一些不必要的组件，适合自己的架构才是最好的架构。

---

📌 关注 是对原创的最大认可，你的每一个关注 ，都是技术生态圈的+1节点！
🔔 开启通知，下一篇《架构设计原则》内容更新时，你就是技术圈最前沿的「极客」！