信息系统架构information system architecture。就是把信息系统的各个部分,像硬件、软件、数据这些,整合在一起的方法和规划。它能让系统更高效地运行,也方便后续的升级和维护。就好比建房子得先有设计图,信息系统架构就是这个系统的 “设计图”。
信息系统架构设计的一个核心问题是能否使用重复的信息系统架构模式及能否达到架构级别的软件重用,也就是说能否在不同的软件系统中使用同一架构。
信息系统架构风格
信息系统架构风格是描述某一特定应用领域中系统组织的惯用模式。架构风格定义了一个系统家族及一个架构,定义一个词汇表和一组约束。词汇表中包含一些构件和连接件的类型,而这组约束则指出系统如何我将这些构件和连接界组合起来的。
架构风格反映了领域中众多系统中所共有的结构和语义特性,并指导这些如何将将各个模块和子系统有效地组织成一个完整的系统。所以按这种方式理解信息系统,架构风格定义了用于描述系统的术语表和一组既指导构建系统的。
信息系统架构风格分类
1. 数据流风格(Data Flow Styles)
-
定义:以数据流动为核心,系统由数据处理组件构成,数据按固定路径流动。
-
子类:
-
批处理序列(Batch Sequential):数据以整体形式按顺序处理,前一步输出为下一步输入。
-
特点:高延迟、高吞吐,适合离线任务。
-
应用:银行对账、日志分析。
-
-
管道-过滤器(Pipes and Filters):数据流经多个独立过滤器(组件),每个过滤器处理并传递数据。
-
特点:组件松耦合、可复用。
-
应用:编译器(词法分析→语法分析→代码生成)、Unix命令行工具(
grep | sort
)。
-
-
-
修正说明:用户提到的“旅”应为“管道”,属于管道-过滤器架构的一部分。
2. 调用-返回风格(Call-and-Return Styles)
-
定义:通过显式调用机制控制程序执行流程,强调模块化与层次化。
-
子类:
-
主程序-子程序(Main Program and Subroutine):主程序调用子程序完成功能。
-
特点:单线程控制流,适用于简单任务。
-
应用:小型计算工具(如科学计算脚本)。
-
-
面向对象风格(Object-Oriented):封装、继承、多态驱动,对象间通过消息传递交互。
-
特点:高内聚、低耦合,易扩展。
-
应用:GUI框架(如Java Swing)、企业应用(ERP系统)。
-
-
分层架构(Layered Architecture):系统划分为多层,每层仅依赖下层服务。
-
特点:职责分离,便于维护。
-
应用:网络协议栈(TCP/IP模型)、操作系统内核。
-
-
-
修正说明:用户提到的“杠子程序”应为“子程序”,“层次结构”即分层架构。
3. 独立构件风格(Independent Components Styles)
-
定义:组件独立运行,通过通信或事件机制协作。
-
子类:
-
进程通信(Process Communication):多个进程通过消息传递(如RPC、消息队列)交互。
-
特点:适用于分布式系统。
-
应用:微服务架构(Kafka消息队列)、分布式计算(Hadoop)。
-
-
事件驱动系统(Event-Driven):组件通过发布/订阅事件响应变化。
-
特点:异步、松耦合,实时性强。
-
应用:GUI事件处理(如JavaScript DOM事件)、实时交易系统(股票交易平台)。
-
-
-
修正说明:用户提到的“事件系统”应归类为事件驱动风格,属于独立构件的一种。
4. 虚拟机风格(Virtual Machine Styles)
-
定义:通过虚拟层(如解释器、规则引擎)执行自定义逻辑。
-
子类:
-
解释器(Interpreter):解释并执行用户定义的指令或脚本。
-
应用:编程语言解释器(Python解释器)、领域特定语言(DSL)。
-
-
基于规则的系统(Rule-Based Systems):通过预定义规则库驱动决策。
-
应用:专家系统(医疗诊断)、业务规则引擎(Drools)。
-
-
-
修正说明:用户提到的“基于规则的系统”属于虚拟机风格,但需补充解释器等其他子类。
5. 仓库风格(Repository Styles)
-
定义:以中央数据存储为核心,组件通过读写仓库数据交互。
-
子类:
-
数据库系统(Database Systems):数据集中存储,通过SQL或事务接口操作。
-
应用:银行核心系统、电商订单管理。
-
-
超文本系统(Hypertext Systems):通过链接组织非结构化数据。
-
应用:维基百科、Web内容管理系统。
-
-
黑板系统(Blackboard Systems):多个独立组件协作解决复杂问题,共享黑板数据。
-
应用:语音识别(如早期IBM ViaVoice)、自动驾驶决策模块。
-
-
-
修正说明:用户分类正确,需补充黑板系统的协作机制。
架构风格对比与典型场景
风格 | 核心思想 | 典型应用场景 | 优势 | 挑战 |
---|---|---|---|---|
数据流 | 数据流动驱动处理 | 编译器、ETL工具 | 组件复用、流程清晰 | 实时性差,灵活性低 |
调用-返回 | 模块化分层调用 | 操作系统、企业应用 | 结构清晰,易维护 | 层级过深可能影响性能 |
独立构件 | 组件通过事件/消息交互 | 微服务、实时监控系统 | 高并发、松耦合 | 调试复杂,需处理分布式一致性 |
虚拟机 | 自定义逻辑解释执行 | 规则引擎、脚本解释器 | 灵活适应业务变化 | 性能开销大,规则冲突风险 |
仓库 | 中央数据存储与共享 | 数据库、协作式AI系统 | 数据集中管理,协作性强 | 单点故障风险, |
信息系统架构分类
信息系统架构分类可分为物理结构与逻辑结构两种。物理结构更关注硬件实际怎么摆放、部署,像服务器放在哪个机房这些。逻辑结构呢,重点就在功能模块之间的关系上.
物理结构:硬件部署视角
物理结构关注系统硬件、网络、服务器等基础设施的实际布局与连接方式,直接影响性能、可靠性和扩展性。
1. 集中式架构(Centralized Architecture)
-
定义:所有计算、存储资源集中在单一或少数几个节点(如大型服务器)。
-
特点:
-
高可控性:数据与业务集中管理,维护简单。
-
单点依赖:中心节点故障将导致系统瘫痪。
-
扩展性差:硬件升级依赖垂直扩展(如增加CPU、内存)。
-
-
应用场景:
-
传统银行核心系统(如IBM大型机);
-
小型企业ERP系统(早期SAP部署)。
-
-
典型案例:
-
大型机(Mainframe):如IBM Z系列,承担金融交易处理。
-
2. 分布式架构(Distributed Architecture)
-
定义:资源分散在多个地理或逻辑节点,通过网络协作完成任务。
-
子类:
-
客户端-服务器(C/S):客户端请求,服务端响应(如Web应用)。
-
对等网络(P2P):节点平等,共享资源(如BitTorrent)。
-
云计算架构:虚拟化资源池(如AWS EC2、Kubernetes集群)。
-
-
特点:
-
高可用性:节点冗余,单点故障影响小。
-
水平扩展:通过增加节点提升性能。
-
网络依赖:延迟和带宽可能成为瓶颈。
-
-
应用场景:
-
电商平台(如淘宝分布式微服务);
-
区块链网络(比特币节点分布式账本)。
-
逻辑结构:功能模块视角
逻辑结构关注系统功能模块的组织方式与交互关系,抽象于物理实现,决定系统的灵活性和可维护性。
1. 横向综合(Horizontal Integration)
-
定义:整合同一层级或相似功能的模块,实现跨部门或业务线的协作。
-
特点:
-
功能复用:例如统一用户认证中心服务多个子系统。
-
接口标准化:通过API或中间件(如ESB)连接。
-
-
应用场景:
-
企业服务总线(ESB)整合财务、HR、CRM系统;
-
微服务架构中的通用服务(如支付网关)。
-
2. 纵向综合(Vertical Integration)
-
定义:整合不同层级的功能模块,形成端到端业务流程。
-
特点:
-
垂直闭环:从数据采集(如IoT设备)→处理(边缘计算)→展示(BI看板)全链路打通。
-
紧耦合:层级间依赖性强,修改可能影响整体。
-
-
应用场景:
-
智能制造系统(传感器→MES→ERP);
-
自动驾驶系统(感知→决策→控制)。
-
3. 纵横综合(Hybrid Integration)
-
定义:横向与纵向综合的结合,形成矩阵式架构。
-
特点:
-
灵活性:既有跨业务协作,又有垂直领域深度。
-
复杂度高:需平衡模块自治与全局一致性。
-
-
应用场景:
-
智慧城市平台(横向整合交通、安防;纵向贯通数据采集到决策);
-
大型电商平台(横向:商品、订单、物流;纵向:用户行为分析→推荐引擎)。
-