1. 课程导入

大家好，欢迎来到这门课。我是你们这门课的主讲。

先聊个实在的。你想想看，我们天天写代码，到底在写什么？说白了，就是在把现实世界的业务逻辑，翻译成机器能理解的语言。但现实世界很复杂，业务逻辑会变，团队会换人，流量会暴涨。如果没有一套好的组织方式，代码很快就会变成一团乱麻。

我见过太多项目，一开始跑得飞快，半年后改个需求要三天，一年后没人敢动。为什么会这样？因为架构没想清楚。

什么是软件架构？

软件架构不是画几张漂亮的框图。它是一组有意识的、提前做好的设计决策。这些决策决定了系统的结构、行为和演化方向。

我个人习惯把架构理解为「系统的骨架」。骨架搭好了，肌肉（业务逻辑）和皮肤（UI）才能附着上去。骨架歪了，后面再怎么练肌肉也练不出好体型。

举个例子。你设计一个电商系统。架构决策包括：用户模块和订单模块是放在同一个进程里，还是拆成两个服务？数据是存在一个库里，还是分库分表？这些决策一旦做错，后期改造成本极高。

为什么需要分层？

好，那为什么几乎所有成熟的系统都在用分层架构？

原因很简单：控制复杂度。

人类的大脑一次只能处理有限的信息。如果你把数据库连接、SQL语句、业务逻辑、HTTP请求处理、前端渲染全部揉在一个文件里，没人能看懂，更没人敢改。

分层架构的核心思想是：每一层只关心一件事，层与层之间通过定义好的接口通信。

分层的好处	具体说明
关注点分离	每一层只解决一个层面的问题，降低认知负担。
可替换性	只要接口不变，可以随时替换某一层的实现。比如把MySQL换成PostgreSQL，只改数据访问层。
可测试性	可以单独测试每一层，不需要启动整个系统。
并行开发	不同团队可以同时开发不同层，只要接口约定好。

分层架构的演进历史

架构不是凭空产生的。它是随着业务规模和团队规模的变化，一步步演化过来的。我们来看看这条演进路线。

1. 单体架构（Monolithic）

这是最原始的形态。所有代码——UI、业务逻辑、数据访问——全部打包在一个部署单元里。

优点很明显：开发简单、部署简单、调试方便。早期项目用单体完全没问题。

但问题也很快暴露出来。我在2015年参与过一个ERP项目，单体应用，代码量超过50万行。每次发布要编译20分钟，部署后还要重启所有服务。更可怕的是，一个模块的内存泄漏会导致整个系统崩溃。

2. 面向服务架构（SOA）

为了解决单体的问题，SOA出现了。它的核心思想是：把系统拆成多个服务，每个服务提供一组相关的业务功能，服务之间通过ESB（企业服务总线）通信。

SOA比单体进了一大步。它实现了服务的独立部署和复用。

但SOA也有自己的问题。ESB成了新的单点瓶颈，而且ESB本身非常重，配置复杂。我记得有一次，仅仅是因为ESB的某个路由规则配错了，导致整个公司的订单系统瘫痪了整整两个小时。

对比维度	单体架构	SOA
部署粒度	整个应用	单个服务
通信方式	进程内调用	ESB（重量级）
扩展性	垂直扩展	水平扩展（部分）
技术栈	单一	可异构
运维复杂度	低	中

3. 微服务架构（Microservices）

微服务可以看作是SOA的「轻量版」和「进化版」。它把服务拆得更细，每个服务只负责一个非常具体的业务能力。服务之间通过轻量级的HTTP/REST或gRPC通信，不再依赖重量级的ESB。

微服务的优势很明显：

• 独立部署：每个服务可以独立开发、测试、部署、扩容。
• 技术多样性：不同服务可以用不同的技术栈。比如订单服务用Java，推荐服务用Python。
• 故障隔离：一个服务挂了，不会拖垮整个系统。
• 团队自治：每个小团队负责一个或几个服务，决策速度快。

但微服务也不是银弹。它带来了分布式系统的所有复杂性：服务发现、配置管理、链路追踪、数据一致性、网络延迟……

架构演进的核心逻辑

从单体到SOA到微服务，这条演进路线背后有一条清晰的逻辑：随着系统复杂度的增加，我们不断把大问题拆成小问题，然后通过定义清晰的接口来管理这些小问题之间的协作。

分层架构的本质，就是这种「分而治之」思想在代码层面的体现。

这门课你会学到什么？

这门课不是讲理论。我会带着你，从零开始，一步步构建一个完整的、分层合理的软件系统。

• 我们会从需求分析开始，搞清楚到底要做什么。
• 然后做架构设计，画出分层图、模块图、接口定义。
• 接着进入编码实现，每一层怎么写，层与层之间怎么对接。
• 最后是集成测试，确保整个系统能跑起来，并且跑得稳。