系统集成项目管理工程师教程(第3版)笔记——第4章:信息系统架构
第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架构交付周期长大促保障难。解决方案引入云原生数据库OLTPOLAP分离。应用容器化Kubernetes解决环境不一致。微服务改造按业务域拆分。架构裸金属服务器 流量接入DNS/Ingress 云原生PaaS平台 应用服务Namespace隔离 运维管理托管版容器服务。效益降低成本按需付费提高稳定性SLA 99.999%提升效率分钟级交付赋能业务开箱即用云组件。