两层 / 三层 C/S、B/S 架构详解、分析对比

概念背景：

• C/S（Client/Server）客户端 / 服务器：需要安装专用客户端程序（桌面软件）
• B/S（Browser/Server）浏览器 / 服务器：不需要装客户端，用浏览器访问 分层：把系统拆成若干层，每层职责单一，解耦，便于维护扩展。2 层 = 两层架构，3 层 = 三层架构。

一、C/S 架构（客户端‑服务器）

1. 两层 C/S（传统胖客户端）

结构：客户端层 ↔ 数据库服务器

【客户端(UI+业务逻辑)】 <----> 【数据库服务器】

　　

• 客户端：包含界面 UI + 业务逻辑直接写在客户端程序，直接连接数据库（JDBC/ODBC）执行 SQL。
• 服务端：就只有数据库，只负责数据存储。

流程

用户操作客户端 → 客户端直接发 SQL 给数据库 → 数据库返回数据 → 客户端执行业务计算、渲染界面。

✅优点

1. 架构简单，开发快；本地运算，响应速度快
2. 交互体验好，本地可以做复杂界面、离线操作

❌缺点

1. 胖客户端：业务逻辑在客户端，修改业务就要重新打包、更新所有用户客户端，维护成本极高
2. 数据库连接直接暴露在外，安全差；大量客户端直连数据库，数据库连接压力大
3. 跨平台差，每台机器都要安装部署客户端
4. 业务逻辑分散，很难统一管控

典型老系统：早期桌面进销存、老版财务软件。

---

2. 三层 C/S

为了解决两层 C/S 胖客户端问题，抽离出一层应用服务层。

【客户端(只做UI展示)】 ↔ 【应用服务层(业务逻辑层)】 ↔ 【数据库服务器】

　　

1. 表示层（客户端）：只负责 UI 界面，不再写业务逻辑，不直接访问数据库。调用应用层接口。
2. 业务逻辑层（应用服务层）：中间服务，封装全部业务规则、校验，客户端通过网络接口 (RPC/Socket) 调用它。由这一层访问数据库。
3. 数据层（数据库服务器）：只负责持久化存储。

流程

客户端 UI 发起请求 → 请求发给应用服务层 → 应用层执行业务逻辑，访问数据库 → 拿到结果返回客户端渲染。

✅优点

1. 业务逻辑集中在中间服务，修改业务只更新服务端，不用改客户端
2. 客户端变 “瘦”，安全提升，客户端不能直连数据库
3. 业务层可复用，可负载均衡，适合多用户并发

❌缺点

1. 依然需要安装客户端，版本升级还是要分发客户端程序
2. 需要维护中间应用服务器，架构变复杂
3. 跨平台依然受限

例子：很多桌面 ERP、WinForm/WPF 客户端 + Java/.NET 后台 RPC 服务。

---

二、B/S 架构（浏览器‑服务器，Web 架构）

本质是特殊的 C/S：浏览器就是通用客户端，不需要安装专用软件。

1. 两层 B/S

早期简单 Web，现在很少正式项目使用

【浏览器（表示层）】 <----> 【Web服务器+数据库】

　　

• Web 服务器（Apache/Nginx+PHP）：网页 + 业务逻辑混在一起，脚本直接操作数据库，没有独立业务层。
• 浏览器负责展示页面。

特点：页面代码、业务逻辑全部写在服务端，浏览器只做渲染。 ✅开发简单，适合小网站；无需安装客户端。 ❌业务、数据访问代码混杂，耦合严重，大项目难以维护。

例子：简单 PHP 小网站，页面脚本直接写 SQL。

2. 三层 B/S（Web 最标准架构）

互联网项目主流架构。

【浏览器（表示层）】 ↔ 【Web应用服务层(业务层)】 ↔ 【数据库层】

　　

1. 表示层（浏览器）：HTML/CSS/JS，接收用户输入，发起 HTTP 请求，渲染页面。
2. 业务逻辑层（Web 应用服务）：SpringBoot、Tomcat 等；接收 http 请求，执行业务校验、业务逻辑，访问数据库，返回数据 / 页面。
3. 数据层（数据库）：MySQL/Oracle，数据持久化。

前后端不分时代：服务端返回渲染好的 HTML 页面（JSP/Thymeleaf）； 现在前后端分离 B/S：浏览器端（Vue/React）作为表示层，后端只返回 JSON 接口。

✅优点

1. 零客户端安装，只要浏览器；跨平台
2. 业务全部在服务端，更新只部署服务器，所有用户立刻生效
3. 易维护、便于迭代，适合互联网业务

❌缺点

1. 重度交互、复杂图形、离线场景不如 C/S 体验
2. 全部依赖网络，断网基本不可用
3. 服务器压力大，高并发需要做集群、缓存

绝大多数网站、后台管理系统都是三层 B/S。

---

三、2 层 / 3 层 C/S & B/S 对比总表

 

对比维度	两层 C/S	三层 C/S	两层 B/S	三层 B/S
客户端	专用胖客户端	瘦客户端程序	浏览器	浏览器
业务逻辑位置	客户端本地	中间应用服务层	Web 服务器脚本	Web 应用服务层
数据库访问	客户端直连数据库	中间服务访问数据库	Web 脚本直连数据库	服务层访问数据库
是否需要安装软件	✅安装客户端	✅安装客户端	❌浏览器	❌浏览器
升级维护	差，客户端全部更新	服务端更新；客户端仍需分发	服务端更新	最好，仅更新服务端
网络依赖	可部分离线	依赖网络	强依赖网络	强依赖网络
安全性	差，客户端直连 DB	较好，隔绝数据库	一般	较好
并发扩展	差，大量直连 DB	较好，服务层可集群	差	优秀，易于集群扩容
适用场景	小型桌面软件	企业桌面 ERP、专用客户端	简单小型网站	互联网 Web、管理后台系统

核心通俗总结

1. 两层 C/S：业务写在客户端，客户端直接怼数据库；小软件好用，大系统灾难。
2. 三层 C/S：把业务抽出来放到中间服务，客户端只管界面，但还是要装客户端。
3. 两层 B/S：浏览器访问，业务和数据库代码混在 web 服务，简单小站。
4. 三层 B/S：现在主流，浏览器做界面，服务端处理业务，数据库存数据；不用装软件，更新只改后端。

扩展：现在微服务就是三层架构进一步拆分业务层，把单一业务层拆成多个微服务。

面试常考问题

1. Q：C/S 和 B/S 本质区别？

A：C/S 需要安装专用客户端程序；B/S 客户端就是浏览器，无需安装。B/S 属于 C/S 的一个子集。

2. Q：两层 C/S 最大问题？

A：业务逻辑分布在各个客户端，升级困难；客户端直连数据库，连接数、安全风险高。

3. Q：三层架构的核心思想？

A：职责分层，业务逻辑独立一层，界面层不直接访问数据库，解耦，便于维护、扩展。