信息系统基础知识（八）：典型信息系统架构模型详解

📝 前言

在前面的九篇文章中，我们逐一学习了信息系统的分类体系------从记录日常交易的TPS，到支持管理决策的MIS，从辅助半结构化决策的DSS，到模拟专家推理的ES，从提升办公效率的OAS，到整合企业资源的ERP。这些系统各自在企业中扮演着不同的角色：TPS处理具体的业务交易，MIS生成管理报表，DSS辅助高层决策，ES模拟领域专家，OAS提升办公效率，ERP整合全企业资源。它们相互协作，共同构成企业信息化的完整图景。

本章要讨论的"典型信息系统架构模型"------不同于单个信息系统的功能探讨，而是从宏观架构层面，讨论如何将信息系统与业务（如政务、商业、工业）深度结合，搭建一个可落地、可扩展、安全可靠的整体系统。实践中，电子政务和电子商务是信息系统架构应用最广泛、最具代表性的两大领域。在系统架构设计师考试中，这两个方向不仅是在选择题中的常客，更是下午论文的独立命题方向。从2011年到2025年的15年间，"企业集成与平台"类别论文题共出现7道，占比约10.9%，热度持续不减。

本文将围绕四项核心内容展开：信息系统物理结构、逻辑结构、一般原理、以及两种典型且具有代表性的架构模型------电子政务架构模型和电子商务架构模型。

一、信息系统的物理结构与逻辑结构

在深入具体模型之前，先建立关于信息系统结构的两个基础概念：物理结构和逻辑结构。理解这两者的演进，是构建大型信息系统的第一步。因为无论在设计电子政务平台还是电子商务系统时，选择什么样的物理布局和逻辑综合方式，都会从根本上影响系统的架构定位。

1.1 信息系统的物理结构

定义：物理结构是指信息系统硬件与网络资源在空间上的拓扑组织形式。物理结构决定了系统的"骨架"------硬件设备如何布局、网络如何连接、数据如何流动，深刻影响着系统的性能、可靠性和可扩展性。

1.1.1 集中式结构：资源聚合的统一管控

概念：指信息系统的所有资源（包括计算机硬件、数据、软件等）在空间上集中配置于一个中心节点，用户通过终端远程访问共享资源。

典型案例：早期的单机系统、通过终端共享资源组成的多用户系统（如银行早期的柜面终端系统）、大型主机带数十个终端的集中式处理模式。即使在如今分布式计算大行其道的时代，物理集中的计算模式在明源云、企业财务共享平台等金融、航天、制造等行业的某些关键业务场景中，依然有着不容忽视的实用价值。

优点：资源集中，便于统一管理维护；硬件和软件资源利用率较高。

缺点：大规模系统中，维修维护困难；不利于发挥用户在信息系统建设过程中的积极性和主动性；系统脆弱，一旦主机出现故障，整个系统就会瘫痪。

1.1.2 分布式结构

概念：通过计算机网络把不同地点的计算机硬件、软件、数据等资源连接在一起，实现资源共享与协同工作。各节点既可以在网络系统的统一管理下工作，也可以利用本地资源独立运作。

分类：物理分布式结构可进一步分为一般分布式（文件服务器模式）和客户机/服务器模式。一般分布式结构下，服务器只提供软件与数据的文件服务，各计算机系统根据权限存取远程文件。而客户机/服务器模式中，客户机用户通过客户机向服务器提出服务请求，服务器根据请求向用户提供经过处理加工后的信息。

优点：可以根据应用需求来灵活配置资源，提高系统对用户需求与外部环境变化的应变能力；系统扩展方便，可横向扩展；安全性好，单个节点故障不会导致整个系统停止运作。

缺点：系统管理标准不统一，协调困难，不利于对整个资源的规划与管理。

重要演进提示：如今的"物理分布式系统"与"客户机/服务器模式"不完全等同。B/S架构推广后，Web服务器层、中间件层、数据库服务器层的多层分层也属于逻辑上的分布式部署，可以实现"物理与逻辑分离"，进一步增强了架构的灵活性和扩张能力。

1.2 信息系统的逻辑结构

定义：从系统功能的角度，描述一个信息系统由哪些子系统组成，以及子系统之间的数据流和控制流的交互关系。简单理解，物理结构管"硬件在哪"，逻辑结构管"模块如何分工"。在信息系统开发中，必须强调各子系统之间的协调一致性和整体性。

三大综合方式：

• 横向综合：将同一管理层次的各种职能综合在一起。例如，将运行控制层的人事和工资子系统综合在一起，使基层业务处理一体化。

• 纵向综合：把同一职能的各层次业务组织在一起，从而沟通上下级之间的联系。例如，工厂的会计系统和公司总部的会计系统纵贯连接，财务数据直接汇总上报。

• 纵横综合（最理想的综合方式）：从信息模型和处理模型两个方面进行综合，做到信息集中共享，程序尽量模块化，提取通用部分，建立系统公用数据库和统一的信息处理系统。这是大型企业架构（EA）建设的理论参照。

二、信息系统架构的一般原理

定义：信息系统架构包括两个基本部分------组成成分和成分之间的关系。要通过架构设计，分析出相对稳定的组成成分和成分之间的关系，在稳定部分的支持下，对变化较多的部分进行重新组织，以满足各种变化要求。

核心目标 ：使信息系统对环境和业务需求的变化具备一定的适应能力，即具有一定柔性。

打个比方：高速公路的路基和桥墩是相对固定的"稳定成分"（例如数据模型、核心流程），而路面标线、指示牌和临时管控方案则属于可以重组的"变化部分"（例如报表模板、用户界面）。架构设计的核心价值，就是识别出稳定与变化的边界，构建一个既可维稳又能快速迭代的系统。

三、常用信息系统架构模型

教材中介绍了四种常用信息系统架构模型：单机应用模式、客户机/服务器模式、浏览器/服务器模式以及多层架构模式。理解它们的演进脉络，能够帮助架构师在项目初期快速做出正确的技术选型。

3.1 单机应用模式

概念：最原始的架构形态，运行在一台物理机器上的独立应用程序，所有功能都在本地完成。

适用场合：简单的本机工具软件、个人管理软件等。随着信息共享和网络协同需求的增强，这种模式已基本退出主流大型信息系统架构。

3.2 客户机/服务器模式

概念：又被称为胖客户端模式，结构为"前台客户端 + 后台数据库管理系统"。客户端负责界面显示和部分业务逻辑处理，服务器负责数据存储和管理。

优点：资源利用灵活，能够根据应用需求定制配置；安全性较好。

局限：仅适合需求与功能简单的小型系统；客户端过"胖"导致部署维护成本高，系统升级困难。

3.3 浏览器/服务器模式

概念：客户机/服务器模式的深化演进，利用Web浏览器作为通用的前端应用程序，将复杂的业务逻辑从客户端抽离到服务器端处理。

优点：由于浏览器免费且通用，节省了大量客户端软件的开发和维护费用；用户体验得到统一和提升；系统扩展性好，并发连接数可通过中间件层进一步扩展。

中间件层（应用服务器）的作用：①提高系统伸缩性，增加并发性能------Web服务器可处理的并发请求数有限，在中间件层可得到进一步扩展；②提高数据安全性------Web服务器直接暴露给客户，中间件层起到隔离作用，有效保护企业数据库的连接不受外界直接访问。

3.4 多层架构模式（现代主流）

多层结构是目前主流大型应用系统的标准架构，它将前述B/S模式进一步细化为展示层、业务逻辑层、数据访问层和基础设施层等多层结构，实现了更彻底的"关注点分离"。

四层结构的典型划分：

• 展示层（前端）：用户交互界面，通过HTTP/HTTPS调用后端API

• 业务逻辑层（后端）：实现核心业务规则

• 数据访问层（持久层）：封装对数据库的CRUD操作

• 基础设施层：提供公共支撑能力（日志、缓存、安全认证、消息队列等）

各层自上而下单向依赖，严禁反依赖或跨层调用。保证前端单独升级而不影响后端逻辑，而数据库基础设施变更也不必修改业务层的核心代码。层间接口设计直接决定了系统的可维护性。

四、电子政务架构模型

在对信息系统的物理结构、逻辑结构和多层架构的演进有了整体认知之后，来看信息系统架构模型在实际领域中的落地。电子政务模型和上一节中学习的电子商务模型，乃是信息系统架构最典型的两类代表。

电子政务是指政府借助现代信息技术，对管理和服务职能进行集成，在网络上实现组织结构和工作流程的优化重组，实现公务、政务、商务、事务的一体化管理。

4.1 电子政务的五类行为主体

电子政务系统涉及五类行为主体之间的交互：

交互类型	说明	典型内容
G2G（政府对政府）	政府部门之间的信息交换和业务协同	国家和地方信息采集、政府内部管理系统
G2B（政府对企事业单位）	政府向企业提供服务、发布政策和监管信息	工商登记、纳税申报、工程投标
G2C（政府对居民）	政府面向居民提供的公共服务	护照办理、社保查询、户籍登记
B2G（企业对政府）	企业向政府提供信息和服务	缴纳税款、统计报表、政府采购投递投标
C2G（居民对政府）	居民向政府提供信息和反馈	参政议政、投票选举

理清这五类服务对象与交互方向，是设计电子政务系统架构时做功能划定的重要基础。不同交互类型的系统架构设计重点差异很大，例如G2C需要更注重用户体验，G2B需要关注业务合规性和流程自动化，G2G则更加关注数据共享与传输安全。

4.2 电子政务的发展阶段

根据电子政务的建设成熟度，通常分为四个阶段：

1. 起步阶段：政府信息网上静态发布（如政务公告、政策法规）

2. 单向互动阶段：政府向用户单向提供服务（如表单下载）

3. 双向互动阶段：用户可以在线填写申请、提交证照（如网上报税）

4. 网上事务处理阶段：完整的政府业务处理流程

当前省级政务平台已普遍处于第三到第四阶段，主流架构设计从传统的"部门审批处理"模式朝着跨地域协同、统一身份认证和数据共享交换的"大平台模式"演进。

4.3 电子政务的典型技术架构

随着数字政府建设的深入，电子政务的标准化架构框架已经建立。2025年8月，国家标准《数字政府架构框架》系列（GB/T 45963.1-2025至45963.5-2025）正式发布，系统阐释了数字政府顶层设计的方法，涵盖参考模型、架构设计、治理及能力评估。

在行业实践方面，2025年9月华为发布了"R.I.S.E"国家政务云参考架构，其内核包含四大方案：韧性底座（多地容灾高可靠架构）、自主安全（公有云/全栈专属云/华为云Stack等混合部署模式）、数智创新（应用/数据/AI三大使能平台支撑上层应用）、丰富生态（100多家生态伙伴共建公共服务数智化跃迁）。

现代电子政务架构设计的五大核心要点：

1. 分层防护与安全隔离：政务外网与政务内网的逻辑/物理隔离

2. 数据共享与交换：跨部门数据枢纽设计，打破信息孤岛

3. 统一身份认证：支持跨部门单点登录、CA证书互认

4. 业务中台化：提炼共性政务服务能力（如"一件事一次办"的流程引擎化暴露）

5. "一网通办" ：面向百姓、企业的一站式办事门户设计

考试启示：过往论文真题中也出现过电子政务系统架构设计的考题。"论企业集成平台的架构设计"、"论企业集成架构设计及其应用"等题目，本身就属于电子政务与政府信息化的直接关联范畴。构建G2C、G2B服务平台时，建议引入"业务中台+数据中台"双中台架构，以支撑跨部门协同。

五、电子商务架构模型

电子商务模型是信息系统架构应用的另一大主战场。电子政务解决"政府内部协同与公共服务"，电子商务解决"商业交易的数字化转型"。

5.1 电子商务的主要商业模式

电子商务系统首先是一种商业模式的信息化映射，选择恰当的商业模式是架构设计的前提。一张表看清不同模式的业务实质：

模式	英文	说明	典型代表
B2B	Business to Business	企业对企业之间的交易	阿里巴巴1688
B2C	Business to Customer	企业对个人的零售交易	京东、天猫
C2C	Customer to Customer	个人对个人的交易	淘宝、闲鱼
O2O	Online to Offline	线上到线下的商务结合	美团、饿了么
C2B	Customer to Business	个人发起需求，企业响应	尚品宅配
B2B2C	Business to Business to Customer	平台连接商家和消费者	天猫商城、京东

电子商务系统的顶层架构不仅取决于所选业务的商业模式，还要考虑跨终端、跨渠道的无缝销售场景及交易承诺履约能力，同时融入AI智能推荐、数据中台共享用户画像、多渠道客服等核心功能模块。

5.2 传统电子商务的三层架构

传统电子商务平台通常采用经典的三层架构模式：

• 展示层：面向用户的前端界面，支持Web端、移动端（App/小程序）等多端接入

• 业务逻辑层：核心业务模块包括商品管理、订单处理、购物车、促销引擎、支付对接等

• 数据层：数据库存储商品信息、用户数据、订单记录等

5.3 现代电商的云原生架构演进

随着用户规模迈向千万级、交易峰值持续攀升，传统架构无法充分承载高并发、低延迟、持续稳定和弹性扩展的多重需求。近几年电商架构设计向"基于云与微服务"的"面向云原生架构"演变，以应对双11、618等大促场景的流量洪峰与复杂业务链路。

电商系统云化架构的组成结构如下（参考2025年阿里云电商实践解决方案）：

• 边缘层：CDN加速静态资源、多终端适配、接入网关防御

• 接入层：负载均衡、Web应用防火墙、限流熔断

• 业务逻辑层：微服务落地。典型电商微服务拆分会包括用户服务、商品服务、订单服务、购物车服务、促销服务、支付服务、物流服务、库存服务

• 数据层：读写分离、分库分表、数据缓存（Redis）、消息队列（Kafka/RocketMQ）异步"削峰填谷"

• 运维治理层：全链路监控、日志系统、服务网格熔断与弹性伸缩

其中，消息队列的"削峰填谷"作用尤为关键：在秒杀场景瞬时流量激增时，将突发的请求转为队列消息，系统按自身处理能力匀速消费，避免瞬时冲击压垮数据库。在订单创建、库存扣减、支付等高频操作场景中，消息队列的异步化处理还能让主流程响应时间从数百毫秒降至数十毫秒。

考试启示：2017年案例分析真题曾重点考查过"秒杀"等场景的高并发解决方案，其中提到了CDN、镜像站点、负载均衡、缓存服务器、分布式文件系统等方案，并结合大数据容灾等保障设计。因此在撰写相关架构设计论文时，可以重点强调该电商系统引入"消息队列"和"缓存"的技术效果（响应时间优化、高并发抗压能力）。

六、信息系统架构的未来趋势

6.1 企业架构（EA）成为转型核心方法论

中国信通院《企业架构实践与创新观察报告（2025年）》将企业架构定位为转型核心方法论，从"部门架构视图"演进为"治理约束与企业级标准"。TOGAF框架以业务、数据、应用、技术"4A架构"为核心，国内在央国企数字化转型中落地广泛。

当前一线架构师的选型趋势已经逐渐明确：现代信息系统建设的主要矛盾不再是"能不能开发"，而是"能不能对接、扩展、安全合规"；架构设计正从技术细节驱动转向价值驱动。在未来的论文和案例分析中，将集成能力扩展性和数字化平台与整体EA框架融合是提分亮点。

关于EA架构更系统的内容，后续第4章"企业信息化"将进行专项论述，这里点到为止。

6.2 架构与AI的深度融合

人工智能已经成为主流信息系统架构中不可忽视的一环。在电子商务领域，AI向推荐引擎、智能客服、供应链预测渗透；在电子政务等领域，AI能力通过政务智能体实现"办事指南的意图识别与任务自动化"。

华为"数智创新"使能平台通过基础模型加训练平台和政务智能体、数字ID等公共能力，兼顾了数据利用与AI精度，可以在架构设计的更宏观层面实现降本增效与自主可控。

6.3 数据主权与合规架构

随着数据安全法、个人信息保护法及GDPR的监管趋严，架构师必须将合规治理前置------对租户隔离、数据匿名化处理、审计日志完整性设计等实施治理能力。此外将云原生技术、弹性伸缩与高可用保障机制（RPO/RTO设计）纳入预案，确保电商大促和平稳运行周期的系统健康管理。

七、高频考点与论文备考方向

7.1 电子政务的常见考点与真题切入点

今年电子政务在上午选择题中的考点可归纳为五个方向：

1. 五类行为主体的交互区分：识记G2G、G2B、G2C、B2G、C2G，辨析题中用户需求如何影响子系统功能划分

2. 数据处理对象与功能：政务服务流程中标准化或非结构化数据如何跨越部门流转让企业申请一步到位

3. 业务流程重组：电子政务系统上线等于政府工作流程重组、岗位职责与协同机制的优化

4. 安全横切关注点：数据安全、统一认证、政务内外网隔离、安全等保测评要求

5. 数字政府标准架构框架：以GB/T 45963-2025等最新国标为依据，融合云计算与大数据加速数字平台统一承载

下午论文方向：在涉及电子政务服务等公共治理场景时，在论文的结尾部分突出分析业务的跨部门协同数据共享访问与统一身份认证无缝接入效果，显示架构设计的综合优势。

7.2 电子商务的常见考点与真题切入点

1. 商业模式识别：B2B/B2C/C2C/O2O/B2B2C的区别和典型例子

2. 三层架构到微服务的演进：对比单体架构的缺点，阐述拆分的架构价值

3. 高并发策略：缓存、消息队列、读写分离、冗余部署（真题连续出现卖空和秒杀场景）

4. 交易一致性保障：使用分布式事务、最终一致性等细节设计，避免超卖丢单

5. 弹性伸缩与监控告警：针对大促峰值，设计基于容器的自动扩容和降级熔断机制

在下午论文题的论述中，可以坚持技术手段与业务目标结合的方式------先讲清楚电商的商业模式选择与业务定位，再围绕拆分为商品、订单、支付、促销等微服务模块并引入MQ和Redis案例，体现"降本增效"的成果。

八、结语

典型信息系统架构模型是软件工程理论与具体业务场景融合的落地缩影。电子政务和电子商务作为两个最大量的信息系统模型，虽有差异，但其设计逻辑却有相通之处：都需要以多层架构为骨架，以数据共享为血脉，以安全合规为底线，以智能化为翅膀。

系统架构设计师考生在复习3.8节的"典型信息系统架构模型"时，可以按以下"课程理解"路线来加强：

1. 先从物理结构、逻辑结构、一般原理开始建立整体观念

2. 然后对照电子政务和电子商务大量阅读标准框架和典型案例，增强领域知识积累

3. 在论文撰写中，务必结合本人真实经历引出架构设计决策理由、风险点、权衡点，重点阐述：**为什么这样拆分而不是那样？为何选择B/S三层而非C/S？微服务边界是如何界定的？**以这些架构"设计决策"驱动真实应对考试，才能让阅卷老师看到架构师的决策能力。