计算机网络的计算模式

计算模式指的是网络中计算任务（数据处理、存储、运算等）在客户端和服务器之间如何分配与协作。随着技术发展，主要经历了以下几种模式的演变。

一、计算模式的主要类型

模式	核心特点	处理位置	典型代表
集中式计算模式	所有计算在主机完成，终端仅负责输入/输出	主机	大型机+哑终端
分布式计算模式	多台计算机协同完成，各自承担部分任务	多台计算机	集群计算、网格计算
客户机/服务器模式（C/S）	客户机发起请求，服务器提供服务	客户机（部分处理）+ 服务器（核心处理）	Web应用、数据库系统
浏览器/服务器模式（B/S）	浏览器发起HTTP请求，Web服务器响应并返回页面	浏览器（展示交互）+ Web服务器（业务逻辑）+ 数据库服务器（数据存储）	淘宝、知乎、Gmail、企业OA系统
对等计算模式（P2P）	节点既当客户机又当服务器，资源直接共享	所有对等节点	BitTorrent、区块链
云计算模式	按需获取计算资源，弹性伸缩	云端数据中心	AWS、阿里云、腾讯云

需要特别说明：分布式计算是一个广义概念，C/S、P2P、云计算都可以看作是分布式计算的具体实现形式。这里将它们并列是为了更清晰地展示不同架构的特点。

二、各种模式详细讲解

1. 集中式计算模式

结构描述：

• 一台强大的中央主机（大型机、中型机）负责所有运算和存储

• 多个哑终端（只有键盘和显示器，没有处理能力）连接到主机

工作流程：

• 用户在终端输入命令 → 发送给主机 → 主机处理 → 结果返回终端显示

• 终端本身不做任何数据处理

优点：

• 集中管理，易于维护和备份

• 安全性高（数据不离开主机）

• 硬件利用率高

缺点：

• 单点故障：主机故障则所有终端无法工作

• 扩展性差：增加性能需更换整台主机

• 成本极高（大型主机昂贵）

应用场景：银行核心系统（如IBM Z系列大型机）、航空公司订票系统（仍在使用）。

2. 分布式计算模式（广义概念）

定义：将一个大任务分解成多个子任务，由多台计算机（节点）协同完成，对外表现为一台统一的计算机。

核心特征：

• 多台计算机：物理上分散

• 消息传递：通过网络通信协调

• 统一呈现：用户感觉像在使用一台机器

优点：

• 高性价比（用多台普通计算机代替一台超级计算机）

• 高可用性（部分节点故障不影响整体）

• 可扩展性强（增加节点即可提升性能）

缺点：

• 开发复杂度高（任务分解、协调、容错）

• 网络通信开销

• 调试和运维难度大

常见形式：

• 集群计算：同构计算机紧密耦合，如Hadoop集群

• 网格计算：异构、跨地域、偏重科研计算，如SETI@home

术语	含义	举例
同构	多台计算机硬件和操作系统相同或高度一致	一个机房里50台都是戴尔服务器，都装Windows Server
异构	多台计算机硬件或操作系统不同，协同工作	同一个集群里有x86服务器（Linux）、ARM服务器（Android）、IBM Power服务器（AIX）
跨地域	计算机分布在不同地理位置（不同城市、国家）	北京、上海、纽约三地的服务器共同提供服务

• 分布式数据库：如TiDB、Google Spanner

3. 客户机/服务器模式（C/S）

结构描述：

• 服务器：提供服务的进程或计算机，被动等待请求，可服务多个客户端

• 客户机：发起请求的进程或计算机，主动请求服务，通常只服务一个用户

工作流程：

1. 客户机启动，向服务器发送请求

2. 服务器接收请求，处理（可能需要访问数据库）

3. 服务器返回结果给客户机

4. 客户机接收并展示

优点：

• 资源共享集中管理（数据在服务器上）

• 安全性好（可控制访问权限）

• 维护方便（升级服务器即可）

缺点：

• 服务器可能成为瓶颈

• 服务器单点故障风险

• 并发量高时性能下降

变体：

• 两层C/S：客户机直接访问数据库（如早期的PB、Delphi程序）

• 三层C/S：客户机→应用服务器→数据库服务器（如大部分Web应用）

• 多层C/S：增加更多中间层（如缓存层、消息队列层）

术语	结构	说明	举例
两层C/S	客户机 → 数据库服务器	客户机直接连接数据库，客户机里写了SQL语句。问题：数据库连接数有限，客户机多了会撑爆	早期的PowerBuilder、Delphi写的进销存软件
三层C/S	客户机 → 应用服务器 → 数据库服务器	客户机不直连数据库，而是访问应用服务器。应用服务器负责业务逻辑，统一连接数据库。好处：客户机再多，数据库连接数也固定	大部分Web应用（浏览器 → Web服务器 → 数据库）
多层C/S	客户机 → 应用服务器 → 中间层 → 数据库服务器	在三层基础上增加更多中间层，各层职责更细。增加的层：缓存层（如Redis）、消息队列层（如RabbitMQ）、数据访问层等	大型电商系统：浏览器 → Web → 缓存 → 消息队列 → 数据库

• 两层：客户机直连数据库（不安全、连接数爆炸）

• 三层：中间加应用服务器做"调度员"

• 多层：加多个"专业工种"各司其职

应用场景：Web应用、邮件系统、文件服务器、数据库系统。

4.浏览器/服务器模式（B/S）

结构描述：

• 浏览器：作为统一的客户端，只需要安装浏览器软件（如Chrome、Edge、Safari），负责发起请求、渲染展示服务器返回的页面

• Web服务器：接收浏览器发来的HTTP/HTTPS请求，处理业务逻辑，访问数据库，生成HTML/CSS/JavaScript等页面内容返回给浏览器

• 数据库服务器：存储数据，为Web服务器提供数据读写服务

工作流程：

1. 用户在浏览器地址栏输入网址或点击链接，浏览器根据HTTP协议构造请求报文

2. 浏览器通过DNS解析域名得到服务器IP地址，建立TCP连接，发送HTTP请求

3. Web服务器接收请求，解析URL和参数，执行相应业务逻辑（可能需要查询数据库）

4. Web服务器将处理结果（通常是HTML页面或JSON数据）封装成HTTP响应返回给浏览器

5. 浏览器解析HTML，渲染页面，执行其中的JavaScript，展示给用户

优点：

• 无需安装客户端：只要有浏览器和网络即可访问，对用户零部署成本

• 跨平台性好：一次开发，Windows、macOS、Linux、iOS、Android均可使用

• 升级维护方便：只需更新服务器端代码，所有用户立即使用最新版本

• 数据集中管理：所有数据存储在服务器端，便于备份和安全管控

• 防火墙友好：使用标准的80（HTTP）和443（HTTPS）端口，通常不会被防火墙阻拦

缺点：

• 用户体验相对较弱：相比原生应用，页面切换有延迟，复杂交互受限（近年来随着Web技术发展，差距在缩小）

• 严重依赖网络：断网或网络质量差时无法使用或体验极差

• 服务器压力大：所有计算和渲染准备都在服务器端完成，高并发时需要强大的服务器集群

• 浏览器兼容性问题：不同浏览器对同一标准可能有不同的实现，需要额外测试和适配

• 安全性风险：面临XSS（跨站脚本攻击）、CSRF（跨站请求伪造）、SQL注入等Web特有攻击

应用场景：

• 各类管理信息系统（OA、ERP、CRM）

• 电子商务平台（淘宝、京东、亚马逊）

• 社交媒体（微博、知乎、Facebook）

• 企业官网、博客、论坛

• 在线办公套件（Google Docs、腾讯文档）

• 云管理控制台（阿里云、AWS控制台）

补充说明：C/S与B/S的关系

很多人会混淆C/S和B/S（浏览器/服务器）。实际上：

• B/S是C/S的一种特例：浏览器是通用客户端，Web服务器是服务器端

• C/S通常指需要安装专用客户端的架构（如微信PC版、网游客户端）

• B/S只需浏览器即可访问（如淘宝、知乎）

对比项	传统C/S	B/S
客户端	需要安装专用软件	只需浏览器
升级维护	每台客户机需单独升级	只需升级服务器
跨平台	较差	好（只要有浏览器）
用户体验	可以做得更丰富	受浏览器限制
典型例子	魔兽世界、企业ERP客户端	淘宝、知乎、Gmail

5. 对等计算模式（P2P）

结构描述：

• 所有节点地位平等，既是客户机也是服务器

• 没有中心服务器（或中心服务器仅用于发现节点）

工作流程（以文件下载为例）：

1. 加入P2P网络，向追踪服务器获取其他节点列表

2. 从多个节点同时下载文件的不同部分

3. 同时将自己已下载的部分上传给其他节点

优点：

• 可扩展性极好（节点越多，资源越丰富）

• 没有单点故障（纯P2P）

• 充分利用边缘带宽

定义：靠近用户侧的接入网络带宽，而不是骨干网核心的带宽。

理解：

• 骨干带宽：城市之间的高速公路，很宽很通畅

• 边缘带宽：从你家到最近高速入口的这段小路

每个普通用户的上传带宽（通常是边缘带宽）往往闲置。P2P让用户把自己下载过的数据上传给别人，把这些"边缘小路"也用起来，缓解中心服务器的带宽压力。

缺点：

• 安全性难以保证（节点不可信）

• 管理困难（没有中心控制）

• 版权和监管问题

常见类型：

• 纯P2P：无中心服务器，如早期Gnutella

• 混合P2P ：有中心索引服务器，如BitTorrent（Tracker）、Napster

含义 ：P2P网络中有一种中心服务器 ，但它不存储文件内容，只存储"哪个节点有什么文件"的索引信息。

工作流程：

1. 你想下载某文件 → 问中心索引服务器

2. 中心服务器告诉你：用户A、B、C有这个文件

3. 你直接去A、B、C那里下载（不经过中心服务器）

• 结构化P2P ：基于DHT（分布式哈希表），如Kademlia（电驴）

种没有中心服务器的文件定位方法。把文件索引分散存储在所有P2P节点上，每个节点只存一小部分。

简单理解：

• 有中心索引：相当于图书馆有一个总目录卡，你去查总卡

• DHT：没有总目录卡，每个书架旁边放一个小目录。你问A书架，A告诉你"去B书架找"；B告诉你"去C书架找"，直到找到

应用场景：文件分享（BitTorrent）、区块链（比特币、以太坊）、即时通信（早期Skype）。

6. 云计算模式

定义：通过网络按需提供可配置计算资源（网络、服务器、存储、应用服务等），用户只需少量管理即可快速获取和释放资源。

核心特征（NIST定义5大特征）：

• 按需自助服务：用户自己开通资源，无需人工交互

• 广泛网络接入：通过标准网络协议访问

• 资源池化：多租户共享物理资源

• 快速弹性 ：资源可快速扩容或释放

一句话 ：云服务器可以几分钟内从配置低变成配置高，或者从配置高变回配置低。

打个比方：

• 传统方式：你想换更大的房子。要先买房、装修、搬家，花几个月。卖房子也得好几个月。

• 云计算：你在酒店住房。今天想住总统套房，打个电话5分钟换好。明天想省钱换标准间，再打个电话5分钟换好。

核心：不需要自己买硬件，直接在云平台上调整。

• 可计量服务：按使用量计费

服务模式：

模式	提供内容	用户管理范围	示例
IaaS（基础设施即服务）	计算、存储、网络	操作系统、中间件、应用、数据	AWS EC2、阿里云ECS
PaaS（平台即服务）	运行环境（操作系统+中间件）	应用、数据	Google App Engine、Heroku
SaaS（软件即服务）	完整的应用软件	只使用软件	Gmail、钉钉、Salesforce

部署模式：

• 公有云：对公众开放，如AWS、Azure、阿里云

• 私有云：组织内部专用

• 混合云：公有云+私有云组合

• 社区云：特定群体共享

优点：

• 降低IT成本（按需付费，无需提前采购）

• 弹性伸缩（应对业务峰值）

系统根据流量大小自动增加或减少服务器数量，不用人守着操作。

• 高可用性（云厂商保证SLA）

术语	含义
高可用性	系统全年几乎不 downtime（停机），故障时能自动切换到备用设备，用户无感知
SLA（服务等级协议）	云厂商和你签的"承诺书"，写明可用性指标，达不到就赔钱

SLA常见数字：

可用性	俗称	允许的停机时间/年
99%	两个9	3.65天
99.9%	三个9	8.76小时
99.99%	四个9	52.6分钟
99.999%	五个9	5.26分钟

举例：AWS的SLA说"99.99%可用"，如果今年停了2小时，赔你代金券。

"云厂商保证SLA"的意思：你花钱买的是"对方承诺不掉线，掉线赔钱"，而不是"绝对不掉线"。

缺点：

• 数据安全担忧（数据在云端）

• 网络依赖（断网则无法使用）

• 长期成本可能高于自建（高负载场景）

计算模式演变对比表

维度	集中式	C/S	B/S	P2P	云计算
控制中心	单一主机	服务器	Web服务器 + 数据库服务器	无中心	云服务商
节点关系	主从	主从	主从（浏览器请求，服务器响应）	对等	用户与云
客户端形式	哑终端	专用客户端软件	通用浏览器	专用P2P软件	浏览器/API/客户端
客户端职责	仅输入/输出	承担部分业务逻辑	主要负责展示与交互	既下载又上传	弱客户端（thin client）
扩展方式	升级主机	升级服务器 + 增加客户机	扩展服务器端（客户端无需变化）	增加节点	弹性伸缩
单点故障	有（主机）	有（服务器）	有（Web服务器/数据库）	无	有（依赖云厂商）
跨平台性	差	较差	好（浏览器屏蔽差异）	一般	好
升级维护	升级主机	每台客户端单独升级	只需升级服务器	升级自愿	云厂商升级
网络依赖	低（本地连接）	中（部分可离线）	高（断网即不可用）	高	高
典型成本	极高	中	低（开发维护成本低于C/S）	低	按需付费
代表性时期	1960s-1980s	1980s-至今	2000s-至今	2000s-至今	2010s-至今

---