在正式展开之前，必须先把术语边界划定清楚。C/S是Client/Server的缩写，中文译为"客户端/服务器"结构，它是分布式计算领域最经典、历史最悠久的一种架构形态。所谓分布式，指的是计算任务不再由单一机器独立完成，而是被拆解到多个节点上协同执行；而C/S架构正是这种"拆分"最早也最直观的组织方式——客户端负责发起请求、承载人与系统之间的交互，服务器负责提供集中的资源、数据与计算能力，两者之间通过网络协议完成通信与协作。
C/S架构最初呈现为"两层结构"（Two-Tier），也就是只有客户端和服务器两个逻辑层次。在这种早期形态下，客户端几乎包揽了全部应用逻辑，界面展示、业务计算、数据访问规则统统堆在客户端一侧，服务器退化为一个纯粹的数据存储容器。这种结构在局域网时代运行尚可，因为网络带宽充足、用户数量有限、业务规则相对简单。然而随着业务规模膨胀，两层结构的先天缺陷开始集中暴露：业务逻辑与界面逻辑高度耦合，任何一处业务规则的调整，都意味着必须对海量客户端进行重新分发、安装与升级；与此同时，数据访问逻辑散布在各客户端中，一旦数据库结构发生变化，所有客户端都要同步修改，维护成本呈几何级数增长。
三层C/S架构（Three-Tier C/S）正是为了克服两层结构的上述痼疾而提出的逻辑分层方案。它的核心思想，是把原本混杂在客户端内部的应用逻辑剥离开来，划分为三个相互独立、职责清晰又彼此协作的逻辑层次：
表示层（Presentation Layer），也称表现层或界面层，是应用的用户接口部分，负责与用户之间的对话功能。它接收用户的输入、发起对功能层的调用，并把处理结果以可视化的形式呈现给用户。表示层唯一关心的是"如何展示"与"如何交互"，不包含任何业务处理规则。
功能层（Function Layer），也称业务逻辑层（Business Logic Layer）或应用层，是应用的本体。它承载系统最核心的业务处理逻辑，负责接收表示层传来的请求、执行相应的业务规则与算法，并在需要时对数据层发起读写操作。功能层是三层架构的中枢，决定了系统"能做什么"。
数据层（Data Layer），也称数据访问层或持久层，负责对数据库的访问与管理，包括数据的存储、检索、更新以及事务管理、并发控制等，向功能层提供统一、规范的数据访问服务。
需要特别强调的一点是，这里的"三层"是逻辑层次（Logical Tier）的概念，而不是物理设备（Physical Machine）的概念。三层可以共同部署在同一台物理服务器上，也可以分别部署在三台乃至更多台物理机器上。能否清晰区分"逻辑分层"与"物理部署"，是判断考生是否真正理解三层架构的试金石，后文会专门展开这一点。
在教材与标准术语体系中，三层C/S架构常被规范表述为"表示层—业务逻辑层—数据层"的三段式划分。与三层架构相伴而生的还有一对极其重要的概念：胖客户端（Fat Client）与瘦客户端（Thin Client）。所谓"胖"与"瘦"，衡量的正是客户端所承载功能的多少。如果客户端承担了大部分业务逻辑与数据处理，只把数据存储这一项交给服务器，就属于胖客户端；反之，如果客户端只保留最薄的界面交互功能，把业务逻辑与数据管理都交到服务器端，就属于瘦客户端。三层C/S架构的提出过程，本质上就是把业务逻辑从客户端剥离出来、向中间的功能层迁移的过程，因此它天然地推动了客户端由"胖"向"瘦"的转变。
三层架构之所以被奉为经典，根本原因不在于"把系统切成三块"这个动作本身，而在于它实现了一种极具工程价值的设计目标——职责分离（Separation of Concerns）。在软件工程中，职责分离意味着把不同性质的关注点安排到不同的模块中，使每个模块只负责一类事务，从而让每一层的内部变化都不会轻易波及其它层。表示层的变化（例如把图形界面换成命令行、把桌面客户端换成网页）不应影响业务逻辑；业务规则的变化（例如折扣策略调整）不应牵动界面代码；数据库的更换（例如从某一种关系型数据库迁移到另一种）也不应迫使业务层重写。这种"变化被隔离在局部"的能力，正是三层架构得以长期流行的底层逻辑。
从软件体系结构的角度看，三层架构实际上是一种特殊的"分层风格"（Layered Style）。分层风格有一条铁律：每一层只能调用它的下一层所提供的服务，层与层之间通过清晰的接口（Interface）进行通信，上层不关心下层的具体实现细节。在三层C/S架构中，这条铁律体现为：表示层只能调用功能层，功能层只能调用数据层，不允许跨层调用，也不允许反向依赖。这样的约束看似刻板，却换来了一系列实实在在的好处：系统结构清晰、易于理解；每一层可以独立开发、独立测试、独立替换；新成员加入团队时，可以快速定位到某一层展开工作。
理解了三层之间的调用约束，还需要理解一次用户请求在三层之间是如何流转的。以一次典型的"用户登录验证"为例：用户通过表示层的界面输入账号与密码并点击登录按钮；表示层不进行任何正确性判断，只是把账号与密码封装成一次调用，递交给功能层；功能层接收到请求后，执行真正的业务逻辑——例如校验账号格式、判断密码是否匹配、记录登录日志、生成会话令牌等，并在需要读取用户信息时向数据层发起查询请求；数据层接到功能层的调用后，向数据库发起实际的读写操作，把查询结果返回给功能层；功能层依据返回结果执行业务判断，最终把"登录成功"或"登录失败"的结论回传给表示层；表示层再把这一结论渲染成用户能看到的界面反馈。整个过程中，数据始终沿着"表示层→功能层→数据层"的方向下行，结果再沿相反方向回溯，形成一条闭合的调用链。
这个看似简单的流程，蕴含着一个关键设计思想：每一层都在做"数据变换"与"职责翻译"。表示层把人机交互产生的原始输入翻译成业务调用；功能层把业务意图翻译成数据访问请求，同时把数据层返回的原始记录翻译成有业务含义的结果对象；数据层则把功能层对数据的抽象需求翻译成具体的数据库操作语句。层与层之间的边界，本质上就是"职责的翻译接口"。正是这种层层翻译的机制，保证了任意一层的内部实现都可以被替换而不影响整体。
胖客户端与瘦客户端的差异，可以归结为一个问题：业务逻辑究竟放在网络的哪一端。在两层C/S结构中，客户端既负责界面又负责业务逻辑，是典型的胖客户端；服务器只提供数据存储，功能上显得"瘦弱"。这种胖客户端结构的好处是服务器负担轻、对网络带宽依赖小，客户端自身即可完成大部分计算；代价则是客户端程序庞大、部署与升级困难、跨平台能力差。
三层架构把业务逻辑从客户端迁移到中间的功能层之后，客户端的负担大幅减轻，逐渐演变为瘦客户端——客户端只保留界面展示与交互，业务计算与数据管理全部交给功能层和数据层。瘦客户端的优势显而易见：客户端轻巧、易于部署与维护、跨平台能力强，业务规则的修改只需在服务器端完成一次，所有客户端即刻生效。当然，瘦客户端也有代价，那就是对网络的依赖更强、对服务器端的性能与可靠性要求更高。胖与瘦并非绝对的好与坏，而是在不同约束条件下的权衡取舍，这恰恰是命题人喜欢考察的深度所在。
要真正把握三层C/S架构在技术谱系中的位置，需要把视野拉长，看清"两层—三层—多层"这条演进线索。两层结构（Two-Tier）是最原始的形态，客户端直接与数据库交互，业务逻辑要么堆在客户端，要么用数据库的存储过程来承担。它的优点是结构简单、开发直接、性能较好；缺点则是耦合严重、扩展困难、安全性差——因为客户端直接访问数据库，数据库的访问口令暴露在客户端程序中，一旦客户端被破解，数据就面临泄露风险。
三层结构（Three-Tier）在两层的客户端与数据库之间插入了一个功能层，把业务逻辑集中起来，从而实现了表示、逻辑、数据三者分离。这是从两层向多层演进的关键一步，也是软考系统架构设计师最常考察的形态。它解决了两层结构的耦合问题，但也引入了新的复杂度——多了一个需要设计、部署与维护的层次，系统整体的调用链变长，对中间层服务器的处理能力提出了要求。
多层结构（N-Tier）则是在三层基础上进一步细分。例如，当企业规模扩大、业务日益复杂时，功能层可以再拆分为"业务外观层、业务规则层、数据访问层"等多个子层，数据层也可能与专门的中间件（如消息队列、缓存、事务管理器）结合，形成更为复杂的分布式体系。三层架构是这条演进路线的分水岭：向前，它是对两层结构的规范化改造；向后，它又是多层架构乃至企业级分布式系统的基础单元。
提到三层C/S架构，几乎绕不开它与B/S（Browser/Server，浏览器/服务器）结构
本篇完！