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

一、计算模式的主要类型

模式

核心特点

处理位置

典型代表

集中式计算模式

所有计算在主机完成，终端仅负责输入/输出

主机

大型机+哑终端

分布式计算模式

多台计算机协同完成，各自承担部分任务

多台计算机

集群计算、网格计算

客户机/服务器模式（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）

结构描述：

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

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

工作流程：

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

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

服务器返回结果给客户机

客户机接收并展示

优点：

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

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

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

缺点：

服务器可能成为瓶颈

服务器单点故障风险

并发量高时性能下降

变体：

两层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服务器提供数据读写服务

工作流程：

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

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

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

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

浏览器解析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）

结构描述：

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

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

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

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

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

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

优点：

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

没有单点故障（纯P2P）

充分利用边缘带宽

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

理解：

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

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

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

缺点：

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

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

版权和监管问题

常见类型：

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

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

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

工作流程：

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

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

你直接去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-至今