[架构之路-243]：目标系统 - 纵向分层 - 架构是表面轮廓、内部骨架、未来蓝图，企业组织架构、信息系统架构、软件架构、应用程序就架构

最新推荐文章于 2024-06-18 07:30:00 发布

文火冰糖的硅基工坊

最新推荐文章于 2024-06-18 07:30:00 发布

阅读量1.2k

点赞数

分类专栏：架构之路文章标签： 1024程序员节管理架构系统架构 IT

本文链接：https://blog.csdn.net/HiWangWenBing/article/details/134008791

版权

架构之路专栏收录该内容

277 篇文章 340 订阅

订阅专栏

1.4 架构是数据流、控制流、管理流、同步流

一、什么是架构

1.1 架构是表面轮廓

对于架构的理解可以包含多个层面，其中一个表层面的解释是"轮廓"。

在这个层面上，架构可以被看作是一种描述系统或建筑物结构、布局和组成的框架或轮廓。

在软件开发中，系统架构是指系统的整体结构和组织方式，它描述了系统中各个组件、模块和它们之间的关系。系统架构可以用一系列的抽象、视图和模型来表示，从整个系统的高级视角展示系统的轮廓和基本组成，而不涉及具体实现细节。

同样地，在建筑领域，建筑架构指的是建筑物的整体设计和布局，它描述了建筑物的外观、内部空间、结构和功能等。建筑架构可以通过蓝图、立面图、平面图等方式来展示建筑物的轮廓和组成。

总而言之，"架构是轮廓"的解释强调了架构作为系统或建筑物的高级描述，它揭示了系统或建筑物的整体结构、布局和组成，但并不涉及具体实现的细节。

1.2 架构是内部骨架

“架构是内部骨架” 的解释更侧重于架构的内部结构和组织方式。在这个解释中，架构被视为系统或建筑物的内在骨干，它定义了系统或建筑物的基本框架和支撑结构。

在软件开发中，系统架构描述了系统内部组件的组织方式、模块化和交互方式。它可以包括系统的分层结构、模块之间的依赖关系、数据流和通信方式等。系统架构的设计可以影响系统的可扩展性、性能、可维护性等方面。

在建筑领域，建筑架构涉及建筑物的结构和内在的组织方式。它包括建筑物的骨架结构、支撑柱和梁、楼层布局等。建筑架构的设计要考虑到建筑物的稳定性、空间利用效率以及人员流动等因素。

因此，从 “架构是内部骨架” 的角度来看，架构被视为系统或建筑物的内在骨干，定义了系统或建筑物的基本框架和支撑结构。它是系统或建筑物内部的组织方式和骨架，影响着整体的功能、性能和稳定性。

1.3 架构是蓝图，是愿景

对于架构的理解，可以把它看作是一个系统或者建筑的蓝图，同时也代表了一个愿景。

在软件开发中，架构是系统设计的蓝图，它提供了一个高层次的方案，描述了系统的组织结构、组件和模块之间的关系，以及系统的行为和特性。它为软件开发团队提供了一个共同的愿景，指导他们如何设计、开发和实现系统。

同样地，在建筑领域，架构描述了建筑物的设计理念、空间布局、结构和功能。它不仅仅是一个蓝图，也是建筑师对建筑物的愿景的体现。架构通过创造性的设计和独特的表达方式，将建筑师的愿景转化为实际的建筑作品。

因此，“架构是蓝图，是愿景” 强调了架构作为一个描述系统或建筑物的蓝图和计划，同时也代表了设计者或者团队的愿景和创造力。架构蓝图和愿景一起指导着系统或建筑的设计、实现和发展，实现预期的目标和效果。

1.4 架构是干系人交流的载体

架构作为软件系统设计和开发的基础，可以被视为干系人交流的载体。架构不仅仅关注技术实现方案，更重要的是它携带着各方利益相关者之间的沟通和理解。

通过架构，干系人可以共同理解系统的整体设计和组成部分，包括系统的功能、性能、安全、可扩展性等方面。这有助于干系人就需求和优先级进行有效的讨论和决策。架构还为干系人提供了一个共同的语言和视角，使得各方能够更清晰地表达自己的需求和期望，从而促进沟通和协作。

在架构设计过程中，与干系人的交流是至关重要的。架构师需要与业务方、开发团队、测试团队、运维团队等各方进行密切合作，了解他们的需求、约束和优先级，从而设计出符合各方期望的系统架构。通过有效的沟通，能够减少信息不对称、减少误解和冲突，提高开发过程的效率和质量。

此外，架构也可以作为沟通的可视化工具。通过绘制架构图、流程图、时序图等，可以直观地展示系统组件之间的关系和交互，帮助干系人更好地理解和评估系统设计方案。架构图像可视化了复杂的技术细节，使得非技术人员也能够更好地参与和理解系统开发。

因此，架构作为干系人交流的载体，不仅仅是技术工具，更是一种协作和共识的工具，帮助各方在软件开发过程中保持一致性和高效性。

1.5 架构是数据流、控制流、管理流、同步流

“架构是数据流、控制流、管理流” 描述了架构的几个重要方面，这些方面涉及到系统或软件的核心运作机制。

数据流（业务流动）：涉及系统中信息或数据的传递方式和路径。在系统架构中，数据流描述了数据从一个模块、组件或子系统到另一个模块、组件或子系统的流动。它关注的是数据的输入、输出和处理过程，帮助设计者理解系统内各个组成部分之间的数据传递和处理关系。数据数据处理是业务处理，是系统的核心和内核。

控制流（项目管理、系统内协同）：涉及系统中指令、操作或流程的流动方式。在软件架构中，控制流描述了软件的行为逻辑和执行顺序。它包括条件判断、循环、函数调用等程序控制结构，定义了系统的控制逻辑和程序执行路径。

管理流（人力资源管理）：涉及系统中的管理和调度机制。在系统架构中，管理流描述了系统中资源、任务或进程的分配和管理方式。它关注的是系统中资源的调度、状态管理和协调，确保系统的有效运行和资源的合理利用。

同步流（系统外协同）：是指系统中不同组件之间的同步机制和协作方式。在软件系统中，多个组件或线程可能需要协同工作，以完成特定的任务或实现某种功能。同步流的设计和实现旨在确保各个组件之间的协作和同步，以避免竞态条件和数据不一致问题。

因此，“架构是数据流、控制流、管理流” 强调了架构涉及到系统或软件的数据传递、行为逻辑和管理机制。考虑数据流、控制流和管理流有助于设计者理解和规划系统的核心运作方式，从而实现系统的功能和预期的行为。

1.6 数据、控制、同步、管理的比较

数据、控制、同步、管理是软件系统架构中的四个重要方面，它们在系统设计和运行中起着不同的作用和功能。

数据：数据是系统中的信息和内容，它是软件系统的核心。数据包括系统所处理的输入、输出、中间结果和持久化存储的数据。数据流描述了数据在系统中的传递和转换过程，关注数据的输入、输出、转换和存储等。
控制：控制关注系统中的行为逻辑和流程控制。控制流描述了系统中不同模块或组件之间的行为和交互方式。它涵盖了系统中的条件语句、循环、函数调用和事件处理等，以控制系统的执行顺序和流程。
同步：同步关注系统中不同组件或线程之间的协同和同步机制。同步流描述了系统中各个组件之间的交互和通信方式。它涉及并发和并行处理、线程间的通信、锁机制、消息传递、事件驱动等，以确保正确的协同和同步。
管理：管理涉及系统中各种资源的管理和分配，例如内存、存储、网络等。管理流描述了系统中资源的管理方式和策略，包括资源的分配、回收、优化和监控等。它涵盖了系统的配置管理、性能管理、安全管理和故障管理等。

总结起来，数据关注系统中的信息和内容（业务），控制关注系统的行为逻辑（软件工程与项目管理），同步关注组件之间的协同和通信（同步与协同），管理关注资源的管理和分配（资源管理）。在系统设计中，这四个方面是密切相关的，它们共同构成了系统的架构和运行机制，以实现系统的功能、性能、可靠性和可维护性。

架构的本质：就是清晰描述和定义一个系统中上述几个重要的方面。

二、架构的层级

2.1 企业组织架构

企业组织架构是指企业内部的组织形式和层级关系，以及各个部门、职能和角色之间的协作关系。下面是一般的企业组织架构的常见要素：

高层管理层：包括董事会、首席执行官（CEO）、执行副总裁等。他们负责制定企业的总体战略和决策，并提供指导和监督。
部门和职能：企业通常根据不同的职能和业务需求划分为多个部门，如财务部门、市场部门、人力资源部门、销售部门等。每个部门负责特定的职能和任务，具有相应的管理层和员工。
矩阵式结构：某些企业采用矩阵式组织结构，即在部门和职能之外，还以项目为中心进行组织。这样的组织结构可以促进跨部门合作和项目管理。
岗位和角色：每个部门和职能中都有各种不同的岗位和角色，如部门经理、项目经理、团队领导者、专员等。每个角色对应着不同的职责和职权。
分公司和地区：对于跨地区或跨国企业，可能会设立多个分公司或地区办事处。这些分支机构通常具有自己的管理团队和员工，但仍属于总体的组织结构。
横向和纵向通信：企业组织架构必须提供良好的横向和纵向的沟通和协作渠道。横向通信是指不同部门和职能之间的沟通，纵向通信是指上级和下级层级之间的沟通。

企业组织架构的设计要考虑企业的战略目标、业务需求、工作流程和工作效率。它应适应企业的规模和成长需求，并灵活调整以适应变化的市场环境和业务要求。此外，企业组织架构还应促进团队合作、信息共享和跨部门协作，以实现企业的整体成功。

2.2 企业系统架构

企业系统架构（Enterprise System Architecture）是指企业内部的信息系统整体架构，它涵盖了企业内各种应用系统、数据管理、网络架构、安全策略等方面。下面是企业系统架构的一些关键组成部分：

业务应用系统：包括企业的核心业务系统，如财务管理系统、供应链管理系统、人力资源管理系统等。这些系统支持各种业务流程和功能，帮助企业实现高效的运营。
数据管理和集成：涵盖企业的数据管理策略、数据仓库、数据传输和数据集成机制。企业系统架构需要确保数据的一致性、可靠性和安全性，同时支持不同系统间的数据共享和交互。
技术基础设施：包括企业的硬件设备、网络架构、服务器、存储设备等。这些技术基础设施为企业系统提供支撑和支持，确保系统的稳定性、可靠性和可扩展性。
安全和身份认证：企业系统架构需要考虑安全策略和机制，包括防火墙、访问控制、数据加密等，以保护企业的敏感信息和防止未授权访问。身份认证和访问控制是确保只有合法用户能够访问系统和数据的重要环节。
业务流程和集成：企业系统架构需要考虑业务流程的设计和优化，以确保不同系统之间的良好集成和协作。这涉及到工作流程管理、业务规则引擎、消息传递、服务总线等技术。
用户界面和用户体验：企业系统架构需要提供友好和高效的用户界面，以提升用户体验和工作效率。这包括合理的界面设计、交互设计和用户反馈机制。

企业系统架构是为了支持企业的业务需求、提高工作效率和资源优化而设计的。它需要与企业的战略目标和需求相一致，并随着业务的变化进行持续演化和优化。

2.2 信息系统架构

基于您提供的信息，我认为您可能指的是信息系统的基础架构或骨干结构。信息系统脊骨可以理解为系统的核心组件和基础设施，支撑着整个系统的运行和功能。以下是信息系统脊骨的一些关键组成部分：

网络基础设施：包括计算机网络、服务器、路由器、交换机等，它们构建了系统内部和外部的通信和连接。
数据中心：用于存储和管理系统的数据和信息，包括服务器、存储设备、数据库等。
操作系统：提供基本的系统管理和运行环境，例如Windows、Linux等。
数据库管理系统：用于管理和存储系统的数据，包括关系型数据库系统（如MySQL、Oracle）和非关系型数据库系统（如MongoDB、Redis）。
应用程序和服务：涵盖系统的各种应用程序、服务和服务端组件，如Web应用程序、移动应用程序、API服务等。
安全和身份验证：涵盖系统的安全体系结构、用户身份验证和访问控制机制，以确保系统的安全性和数据保护。
监控和管理工具：用于监控系统的运行状态、性能指标和故障处理，以及进行系统管理和配置。

这些组成部分共同构成了信息系统的脊骨，它们相互协作，为系统提供稳定、安全和高效的运行环境。根据具体的系统需求和规模，信息系统的脊骨可能会有所不同。

2.3 软件架构

软件架构（Software Architecture）指的是软件系统在设计和实现时所采用的组织架构，即系统中各个组件（模块或子系统）之间的关系，以及它们如何协同工作来实现系统的功能和目标。

具体来说，软件架构包括系统的结构组织、模块划分、接口定义、通信协议、数据流程、处理逻辑、性能优化、安全性等方面，是软件开发的基础和核心之一。一个好的软件架构应该能够提高系统的可维护性、可扩展性、可重用性以及性能和安全性。

常见的软件架构模式包括：

分层架构（Layered Architecture）：系统的逻辑被划分为不同的层次，每一层次负责不同的功能或处理任务。层与层之间的数据交互通过接口进行，支持更好的模块化和可维护性。
MVC架构（Model-View-Controller Architecture）：将系统的结构分成模型层、视图层和控制层三个部分，分别负责数据处理、用户界面和系统控制。该模式支持更好的模块化和可重用性，同时能够提高用户体验和应用性能。
微服务架构（Microservices Architecture）：系统被划分为多个小而独立的服务单元，每个服务单元负责特定的业务功能和数据处理。不同服务单元之间使用轻量级的协议和API进行通信，从而达到更好的可伸缩性和容错性。

其他常见的软件架构模式包括：事件驱动架构（Event-Driven Architecture）、服务导向架构（Service-Oriented Architecture）等。

一个好的软件架构应该能够满足系统设计和实现的要求，并能够适应不同的应用场景和需求。

2.4 应用程序的架构

应用程序的架构是指应用程序的整体结构和组织方式，决定了应用程序的开发、部署和维护方式。常见的应用程序架构包括以下几种：

单层架构（Monolithic Architecture）：应用程序以单一的、统一的程序结构存在，所有的功能模块都集中在一起。这种架构简单直接，适用于小型应用程序，但随着应用程序变得复杂，单层架构会变得不易维护和扩展。
分层架构（Layered Architecture）：应用程序通过分层来组织和划分功能。常见的分层包括表示层、业务逻辑层和数据访问层。分层架构降低了模块间的耦合度，提高了代码的可维护性和可扩展性。
客户端-服务器架构（Client-Server Architecture）：应用程序将系统功能分离到客户端和服务器端。客户端负责提供用户界面，服务器端负责业务逻辑和数据处理。这种架构允许分布式部署，并支持不同类型的客户端。
基于事件的架构（Event-Driven Architecture）：应用程序的处理是基于事件的。系统中的各个组件通过事件进行通信和协同工作。通过事件驱动，可以实现解耦和异步处理，提高系统的扩展性和响应性。
微服务架构（Microservices Architecture）：应用程序被拆分为一组小型、独立的服务。每个服务负责特定的业务功能，可以独立部署和扩展。微服务架构提供了更好的可伸缩性、灵活性和容错性。
无服务器架构（Serverless Architecture）：应用程序的功能由云服务提供商管理和扩展，开发者无需关注底层的服务器和基础设施。这种架构节省了开发和维护的成本，同时可以根据需求自动伸缩。

选择合适的应用程序架构应根据具体的应用需求、性能要求和团队能力等因素进行评估和决策。不同的架构有不同的优缺点，根据实际情况进行选择和折衷是关键。

三、软件架构的风格

常见的软件架构风格指的是在软件系统设计中常用的、具有一定特点和特征的架构模式。

下面列举了一些常见的软件架构风格：

分层架构（Layered Architecture）：将系统划分为逻辑层次结构，每一层次专注于不同的功能。通常包括表示层、业务逻辑层和数据访问层，层次之间通过接口进行通信。这种架构风格具有清晰的分离关注点和模块化的优势。
客户端-服务器架构（Client-Server Architecture）CS：系统将功能分为客户端和服务器端两个部分，客户端负责用户界面和交互，服务器端处理业务逻辑和数据存储。这种架构风格可以支持分布式部署和协作，适用于多用户和远程访问的情况。
浏览器-服务器架构（Browser-Server Architecture）BS：

浏览器-服务器架构（Browser-Server Architecture）是一种常见的软件架构，用于支持 Web 应用程序的开发和运行。该架构将系统划分为两个主要的组件：浏览器（Browser）和服务器（Server）。

浏览器是用户端的组件，负责提供用户界面和与用户的交互。浏览器通过发送请求到服务器来获取所需的数据和资源，并根据服务器返回的响应进行相应的处理。浏览器还负责解析和渲染 HTML、CSS 和 JavaScript，以呈现 Web 页面和处理用户的操作。

服务器是应用程序的后端组件，负责处理客户端请求并进行相应的逻辑处理。服务器接收浏览器发送的请求，执行相应的业务逻辑，访问数据存储（如数据库）并生成响应结果，然后将响应发送回浏览器。

浏览器和服务器之间通过网络进行通信，传输 HTTP 请求和响应。常见的 HTTP 方法包括 GET、POST、PUT、DELETE 等，用于在浏览器和服务器之间传递数据和执行操作。
主从架构（Master-Slave Architecture）：多个从属节点（Slave）通过一个主节点（Master）进行协调和管理。主节点负责分配任务和处理结果，从节点执行任务并将结果发送给主节点。这种架构风格可以提高系统的性能和可伸缩性。
发布-订阅架构（Publish-Subscribe Architecture）：基于事件的架构风格，组件之间通过发布和订阅消息进行通信。发布者将消息发布到特定的主题（Topic），而订阅者订阅感兴趣的主题并接收相应的消息。这种架构风格可以实现松散耦合和异步通信。
微服务架构（Microservices Architecture）：将系统拆分为一组小型、自治的服务单元，每个服务单元负责特定的业务功能。服务之间通过轻量级的通信机制协同工作，每个服务都可以独立部署和扩展。这种架构风格提倡松散耦合和高度可维护性。
领域驱动设计（Domain-Driven Design）：将软件系统分解为多个有界上下文（Bounded Context），每个上下文都有自己的领域模型，并通过明确的界限进行交互。这种架构风格关注于业务领域的建模和划分，有助于理解和设计复杂的业务系统。

以上是常见的软件架构风格，每种风格都有自己的优势和适用场景。在实际应用中，可以根据系统要求、可用技术和团队能力选择合适的架构风格。同时，也可以根据需要采用多种架构风格的组合，以满足系统复杂性和可扩展性的要求。

四、软件架构发展史

软件架构是随着计算机科学和软件开发的发展而演化的，可以追溯到早期的计算机系统。

软件架构的发展史，就是软件规模、复杂度不断增加的历史！！！

独立一体化的程序
单一程序分化成多个相互耦合的模块
单一程序分化成多个独立的对象模块
客户端程序从服务器端程序中分化
服务器进一步分化：一个服务分化成多个低耦合的服务
服务器进一步分化：一个服务分化成多个独立部署的微服务

以下是软件架构的主要发展阶段：

早期阶段 - 一体化阶段：在计算机科学的早期，软件架构概念还不够明确。这个阶段的软件系统通常是单一程序或小型系统，主要关注单一功能的实现。例如，1960年代的批处理系统和操作系统。
结构化-模块化阶段 - 分化阶段：从20世纪60年代中期开始，软件架构逐渐关注模块化和分离关注点的原则。软件系统被划分为多个模块，每个模块负责特定的功能。这种架构形式更容易理解和维护。例如，模块化编程语言如Pascal和C的出现。
面向对象阶段 - 分化封装阶段：20世纪70年代末到80年代初，面向对象编程的兴起对软件架构产生了重大影响。面向对象的思想将软件系统描述为一组对象，每个对象封装了其状态和行为。通过封装、继承和多态等概念，实现了代码的重用和灵活性。这种架构模式被广泛应用于许多语言和开发方法，如C++和Java。
客户端-服务器架构（CS或BS：单一服务、多个请求端） - 服务化启蒙：纪90年代，随着互联网的发展，客户端-服务器架构成为主流。这种架构模式将软件系统划分为客户端和服务器两个部分，客户端处理用户界面和交互，服务器处理业务逻辑和数据存储。这种架构模式支持分布式部署和协作，广泛应用于 Web 应用程序和服务端应用程序。
服务导向架构（SOA）（多个松散耦合的服务）：21世纪初，服务导向架构提出，强调将软件系统划分为一组松散耦合的服务单元。这些服务单元通过标准化的协议进行通信，实现了模块化、可复用和可扩展的架构。SOA 可以通过多个组织和平台之间的服务交互，形成跨组织的业务流程。
微服务架构 - 世界的偏平化的趋势（多个独立部署的服务）：在近年来，微服务架构崛起并成为主流。微服务架构将系统拆分为一组小型、自治的服务单元，每个单元负责特定的业务功能。每个服务可以独立部署（这是微服务的关键），通过轻量级的通信协议以松散耦合的方式协同工作。这种架构风格能够支持快速开发、灵活扩展和持续交付。