第4章：信息系统架构
4.1 架构基础
架构的本质是决策，是在权衡方向、结构、关系以及原则等因素后进行的决策。信息系统项目基于指导思想、设计原则和建设目标展开各类架构设计。
4.1.1 指导思想
指导思想是开展工作的总体原则、要求和方针，从宏观角度引导项目进行，确保参与者对关键价值有一致理解，减少冲突。在具体项目中，指导思想通常由项目发起方或高层管理者依据国家宏观政策、行业发展战略及组织的使命愿景来制定，旨在统一认识、明确方向。
例如，某公共服务领域的信息系统建设项目，其指导思想可确立为：紧密围绕国家关于数字政府建设的战略部署，坚持以服务对象为中心，以技术创新和数据驱动为双轮，聚焦关键业务环节，通过统筹规划与协同推进，全面提升治理能力与公共服务水平。
4.1.2 设计原则
设计原则为架构决策提供基础，应面向未来，简洁（通常4~10项），得到高层认可。例如某中心的设计原则：
- 坚持以人为本：以群众满意为目标。
- 坚持创新引领：利用新技术驱动。
- 坚持问题导向：破解痛点难点。
- 坚持整体协同：业务、技术、数据融合。
- 坚持安全可控：平衡创新与安全。
- 坚持科学实施：统筹规划，注重落地。
4.1.3 建设目标
建设目标是最终目的，是高层提出的构想。例如某中心的目标：建成泛连、开放、融合、联动、智能、在线、可视、安全的治理中心，提高经办服务能力、智能监管能力等，创建全国新范式。
4.1.4 总体框架
信息系统体系架构总体参考框架由四层组成，像一座金字塔：
- 战略系统（顶层）：支持高层决策，包括决策支持系统和战略规划体系。它指导业务和应用系统的方向。
- 业务系统（中间层）：完成具体业务功能（如生产、销售、人事等），可进行业务流程重组（BPR）优化。
- 应用系统（中间层）：即软件系统，如事务处理系统（TPS）、管理信息系统（MIS）、决策支持系统（DSS）等，每个应用包含内部功能和外部界面。
- 信息基础设施 （底层）：支撑上层的基础，包括：
- 技术基础设施：计算机、网络、系统软件等。
- 信息资源设施：数据、标准、处理方法等。
- 管理基础设施：IT部门架构、规章制度等。
4.2 系统架构
系统架构是构成系统的基础组织结构，包括组件、组件间关系、系统与环境的关系，以及设计演化原则。
4.2.1 架构定义
从多个角度理解：
- 架构是对系统的抽象，关注元素的外部可见属性。
- 架构由多个结构组成，从功能角度描述关系。
- 任何软件都有架构，但不一定有文档。
- 架构具有基础性，涉及重要决策，变更代价高。
- 架构是设计师基于功能和非功能需求决策的结果。
信息系统架构与系统架构区别不大，但更强调软件部分。架构对组织重要：影响开发组织结构和目标，受干系人、技术环境影响，反过来也影响这些因素。
4.2.2 架构分类
1. 物理架构
按空间拓扑分为：
- 集中式：资源集中配置，如早期单机、多用户系统。优点：便于管理，利用率高；缺点：维护困难，脆弱（单点故障）。
- 分布式：通过网络连接各地资源，可独立运作。优点：应变能力强，扩展方便，安全性好；缺点：管理标准难统一。又分一般分布式和客户端/服务器（C/S）模式。
2. 逻辑架构
按功能划分的子系统综合体。例如生产组织的管理信息系统包括采购、生产、销售、人力资源、财务等子系统，每个子系统完成事务处理、操作管理、管理控制、战略规划等功能。
3. 系统融合
将各子系统统一规划，整体融合：
- 横向融合：同一层次职能融合，如人事和工资系统一体化。
- 纵向融合：同职能不同层次融合，如分支机构会计与总部会计融合。
- 纵横融合：信息模型和处理模型综合，实现信息共享和模块化。
4.2.3 一般原理
信息系统架构比计算机体系架构更复杂，因涉及大量人的因素。架构包含基本部分 （不变）和可变部分。析出相对稳定的组成成分，在稳定部分支持下重新组织变化部分，使系统具有柔性（适应环境变化的能力）。这就是架构的基本原理。
4.2.4 常用架构模型
1. 单机应用模式
运行在单台物理机器上的独立应用程序，如Photoshop、AutoCAD。虽然简单，但可很复杂。
2. 客户端/服务器模式
- 两层C/S：胖客户端 + 后台数据库，如PowerBuilder开发的系统。
- 三层C/S 与 B/S：前台、中间业务逻辑层、数据库层。B/S（浏览器/服务器）是典型三层，浏览器作为通用客户端。
- 多层C/S：四层以上，如浏览器 + Web服务器 + 中间件（应用服务器） + 数据库服务器。中间件提高伸缩性、安全性。
- MVC模式：模型-视图-控制器，将表示层、业务逻辑、数据分离，如J2EE的SSH框架。
3. 面向服务架构（SOA）
将多个应用看作独立服务，通过消息通信。WebService是典型应用。本质是消息机制或RPC。
4. 组织级数据交换总线
大型组织内不同应用系统之间进行信息交换的公共通道，基于中间件或CORBA构建，负责接收和分发数据、请求、响应。
4.2.5 规划与设计
1. 集成架构演进（以工业企业为例）
- 以应用功能为主线：初级阶段，直接采购成套软件，以部门职能为核心，通过软件接口集成。像"拿来主义"，快速实现功能。
- 以平台能力为主线：成熟阶段，企业需要个性化、协同，采用平台化架构，将基础设施、数据、应用开发平层化，实现弹性、敏捷。可"双态IT"并存（稳态+敏态）。
- 以互联网为主线：产业链/生态链阶段，将功能App化（微服务），通过编排组合适配不同成熟度的组织，实现数据共享和敏捷组合。像"乐高积木"，灵活拼装。
2. TOGAF架构开发方法
TOGAF是开放组体系结构框架，核心是架构开发方法（ADM），包含十个阶段，迭代进行：
- 预备阶段
- 需求管理
- 架构愿景
- 业务架构
- 信息系统架构（应用和数据）
- 技术架构
- 机会和解决方案
- 迁移规划
- 实施治理
- 架构变更治理
每个阶段有明确活动，确保架构开发有序、可重用。
4.2.6 价值驱动的体系结构
系统存在的目的是为利益相关方创造价值。价值模型包含：
- 价值期望值：对功能的需求（内容、满意度、实用性）。
- 反作用力：实现期望值的难度（如环境限制）。
- 变革催化剂：导致期望值变化的事件或限制因素。
体系结构挑战由限制因素引起，需要评估重要性、程度、后果、隔离等，确定优先级，制定应对方法，形成体系结构策略，指导组织、操作、可变性和演变。
4.3 应用架构
应用架构规划目标应用的分层分域，描述应用组件如何实现业务需求及交互。
4.3.1 基本原则
- 业务适配性原则：服务和提升业务能力，灵活适应变化。
- 应用聚合化原则：整合部门级应用，推动组织级系统建设。
- 功能专业化原则：按业务功能聚合，专业化发展。
- 风险最小化原则：降低耦合度，提高独立性，规避单点风险。
- 资产复用化原则：提炼重用架构资产，建立标准化体系。
4.3.2 分层分组
- 分层：业务与技术分离，降低耦合，便于故障隔离。例如某城市社会保险智慧治理中心应用分为治理渠道（移动、桌面、大屏）、治理中心系统（业务主题、综合主题、大数据主题）、治理配套系统（数据支撑、联动服务、治理监管、展示交互）、相关系统改造。
- 分组：将紧密关联的应用内聚为一组，实现高内聚、低耦合。
4.4 数据架构
数据架构描述组织的逻辑和物理数据资产及管理资源的结构，关注数据全生命周期。
4.4.1 发展演进
- 单体应用架构时代：早期信息系统，数据简单，满足业务使用即可。
- 数据仓库时代：面向主题的、集成的、用于分析的数据架构，支持OLAP。
- 大数据时代：灵活高效处理海量数据，从批处理到流处理，从大集中到分布式。
4.4.2 基本原则
- 数据分层原则：合理定位各层次（源、交换、整合、主题等）。
- 数据处理效率原则：追求成本合理的效率，减少冗余存储和搬迁。
- 数据一致性原则：减少重复加工和冗余存储，保证数据一致。
- 数据架构可扩展性原则：基于分层定位，考虑模型和技术的扩展。
- 服务于业务原则：最终目标是为业务服务，必要时可牺牲其他原则。
4.4.3 架构举例
某城市社会保险智慧治理中心采用集中式数据资源管理，构建统一数据中心，包含：
- 源数据库：内部和外部原始数据。
- 交换库：同步源端数据，降低影响。
- 过渡库：Hadoop平台，提高处理性能。
- 整合库：清洗转换后统一存储。
- 主题库：按主题抽取数据，支撑应用。
4.5 技术架构
技术架构承载应用和数据架构，描述实现业务应用的技术体系、基础设施和环境。
4.5.1 基本原则
- 成熟度控制原则：优先使用成熟活跃的技术，谨慎采用新技术。
- 技术一致性原则：减少异构，统一版本。
- 局部可替换原则：标记旧技术，考虑替换方案。
- 人才技能覆盖原则：确保人员能驾驭所选技术。
- 创新驱动原则：挖掘技术对业务的创新价值。
4.5.2 架构举例
某城市社会保险智慧治理中心技术架构包括：
- 技术标准：J2EE、HTML5、SQL、HTTP等国际国内标准。
- 基础支撑：5G、物联网、中间件、Hadoop平台、搜索引擎等。
- 应用框架技术：分层设计（接入层、控制层、业务组件层、资源访问层）。
- 应用集成技术：单点登录、ESB、流程引擎、消息队列。
- 数据集成技术：ETL、数据同步、MapReduce/Spark等。
- 数据分析技术：BI引擎、GIS引擎、AI算法包等。
- 运维技术：操作留痕、日志采集、漏洞扫描等。
4.6 网络架构
网络是资源调度和服务传输的枢纽，设计原则强调高可靠性、高安全性、高性能、可管理性、平台化和架构化。
4.6.1 基本原则
- 高可靠性：网络不能断。
- 高安全性：底层身份鉴别、访问控制。
- 高性能：高效资源调度。
- 可管理性：快速部署和调整。
- 平台化和架构化：弹性扩展，适应未来变化。
4.6.2 局域网架构
- 单核心：一台核心交换机，结构简单，但有单点故障。
- 双核心：两台核心交换机，提供网关保护或负载均衡，可靠性高。
- 环形：多台核心设备连成RPR环，自愈能力强，节省光纤。
- 层次局域网：核心层、汇聚层、接入层，易于扩展和维护。
4.6.3 广域网架构
- 单核心：一台核心路由器，结构简单，单点故障。
- 双核心：两台核心路由器，多条路径，可靠性高。
- 环形：多台路由器成环，路径多样，需环路控制。
- 半冗余/全冗余：网状结构，路由灵活，管理复杂。
- 对等子域：划分两个独立子域，路由控制灵活。
- 层次子域：多个子域层次化，扩展性好。
4.6.4 移动通信网架构
以5G为例：
- 5GS与DN互连：UPF作为DN接入点，分透明模式（UE直接上网）和非透明模式（需认证）。
- 5G网络边缘计算：在靠近用户处部署UPF和MEP，实现低时延、高带宽的业务就近分流，提升体验。
4.6.5 软件定义网络
见第2章2.1.2节第5小节（笔记中已有SDN介绍）。
4.7 安全架构
安全保障以风险和策略为基础，包括技术、管理、人员和过程。
4.7.1 安全威胁
常见威胁：信息泄露、破坏完整性、拒绝服务、非法访问、窃听、业务流分析、假冒、旁路控制、授权侵犯、特洛伊木马、陷阱门、抵赖、重放、计算机病毒、人员渎职、媒体废弃、物理侵入、窃取、业务欺骗等。
4.7.2 定义和范围
安全架构分为三道防线：
- 系统安全架构：从源头打造自身安全。
- 安全技术体系架构：构建安全技术基础设施（防火墙、IPS等）。
- 审计架构：独立审计发现风险。
4.7.3 整体架构设计
1. WPDRRC模型
我国提出的信息安全保障体系模型，六个环节：预警、保护、检测、响应、恢复、反击 ；三大要素：人员、策略、技术。比PDRR增加了预警和反击，功能更全面。
2. 架构设计
- 系统安全保障体系：包括安全区域策略、防病毒统一管理、网络信息安全管理。
- 信息安全体系架构：从物理安全、系统安全、网络安全、应用安全、安全管理五个方面设计。
3. 设计要点
- 系统安全：网络结构、操作系统、应用系统安全。
- 网络安全：隔离与访问控制、防火墙、入侵检测、病毒防护。
- 应用安全：资源共享控制、信息存储备份。
- 安全管理：健全体制、管理平台、人员培训。
4. 架构示例
某组织运维管理系统安全架构分为数据层、功能层、展现层，功能层包括可用性监控、服务支持、安全性监控。
4.7.4 网络安全架构设计
1. OSI安全架构
ISO 7498-2定义了五类安全服务：鉴别、访问控制、数据机密性、数据完整性、抗抵赖性。采用分层多点技术防御（多点、分层、支撑性基础设施）。
2. 认证框架
鉴别方式：基于已知（口令）、拥有（IC卡）、不变特性（生物特征）、可信第三方、环境。包括安装、修改、分发、获取、传送、验证、停活、重新激活、取消安装等阶段。
3. 访问控制框架
涉及发起者、AEF（实施功能）、ADF（判决功能）、目标。ADF基于访问请求、ADI（访问控制判决信息）和策略规则做出判决，AEF执行。
4. 机密性框架
通过禁止访问（访问控制、物理保护、路由控制）或加密（对称/非对称）提供机密性。
5. 完整性框架
保护数据不被未授权修改、创建、删除、插入、重放。可通过阻止访问或探测修改（如数字签名、密封）实现。
6. 抗抵赖性框架
提供证据生成、传输/存储、验证、解决纠纷四个阶段，防止实体否认其行为。
4.7.5 数据库系统安全设计
重点关注完整性设计，原则：
- 根据约束类型确定实现层次。
- 实体完整性、引用完整性尽量应用。
- 慎用触发器。
- 命名规范。
- 细致测试。
- 专职设计小组。
- 使用CASE工具。
完整性作用：防止不合语义数据、实现业务规则、提高效能、帮助测试。完整性约束包括非空、唯一、主键、引用、检查、触发器。
设计阶段：需求分析、概念结构设计（ER图）、逻辑结构设计（转换为DBMS支持的模型）。
4.7.6 安全架构设计案例分析
以基于混合云的工业安全架构为例：
- 架构：设备层、控制层、设计管理层、应用层。
- 安全重点：
- 设备安全：维护、保养、检测。
- 网络安全：防火墙、IDS、漏洞扫描。
- 控制安全：冗余、容错、备份、容灾。
- 应用安全：密码策略、访问控制。
- 数据安全：加密、备份、异地容灾。
4.8 云原生架构
云原生是面向云环境设计的应用架构，充分利用云弹性、分布式优势。
4.8.1 发展概述
- 传统"烟囱式"IT建设资源利用率低，上云后IaaS复用，但需统一PaaS层。
- 开发模式从瀑布到敏捷，再到DevOps（开发、运维、质量保障融合），云原生容器、微服务促进DevOps。
- 云原生技术成为生产力工具，帮助企业构建数字孪生体系。
- 开源推动云原生在AI、大数据、边缘计算、高性能计算等领域应用。
4.8.2 架构定义
云原生架构将应用中的非业务代码（如高可用、安全、可观测）剥离，交给云设施。代码结构变化：业务代码 + 三方软件 + 非功能代码，非功能部分大量委托给云（如虚拟机热迁移、容器自愈、云服务高可用）。软件交付高度自动化（容器、IaC、GitOps）。
4.8.3 基本原则
- 服务化原则：拆分为微服务/小服务，面向接口，便于迭代和治理。
- 弹性原则：系统规模随业务量自动伸缩，降本增效。
- 可观测原则：通过日志、链路、度量主动观测分布式系统。
- 韧性原则：抵御异常，提升MTBF，包括重试、限流、熔断、容灾等。
- 所有过程自动化原则：CI/CD流水线，标准化自动化交付。
- 零信任原则：以身份为中心，默认不信任内外部任何实体。
- 架构持续演进原则：架构本身可演进，适应变化。
4.8.4 常用架构模式
- 服务化架构模式：微服务、小服务，模块独立部署，单独扩缩容。
- Mesh化架构模式：将中间件从业务进程分离到Sidecar，实现解耦和透明升级（如Service Mesh）。
- Serverless模式：开发者不关心服务器，事件触发，按需运行，适合事件驱动、短任务。
- 存储计算分离模式：状态数据存于云服务，应用无状态，提高弹性。
- 分布式事务模式：根据场景选择XA、TCC、SAGA、SEATA AT等。
- 可观测架构：Logging、Tracing、Metrics，定义SLO度量。
- 事件驱动架构：异步解耦，适用于CQRS、数据变化通知、开放式接口、事件流处理等。
4.8.5 云原生案例
某快递公司核心业务上云：
- 问题：传统IOE架构，交付周期长，大促保障难。
- 解决方案 ：
- 引入云原生数据库（OLTP+OLAP分离）。
- 应用容器化（Kubernetes），解决环境不一致。
- 微服务改造，按业务域拆分。
- 架构：裸金属服务器 + 流量接入（DNS/Ingress）+ 云原生PaaS平台 + 应用服务（Namespace隔离）+ 运维管理（托管版容器服务）。
- 效益：降低成本（按需付费），提高稳定性（SLA 99.999%），提升效率（分钟级交付），赋能业务（开箱即用云组件）。