软考 - 系统架构设计师 - 架构风格

高度自动化：批处理作业是无人值守的，可以自动处理一系列的任务，无需人工干预。这大大提高了数据处理的效率和准确性，减少了人为错误。
任务组合与性能优化：批处理作业可以将一系列相关的任务组合在一起，形成一个整体。这样做可以减少任务之间的通信和数据传输，提高系统的性能和效率。
提高系统可靠性：批处理作业在执行过程中会进行错误检查和故障处理，可以及时发现和处理错误，从而提高系统的可靠性。
系统资源利用：批处理模式可以充分利用系统资源，因为作业的调度由系统控制，可以允许几道程序同时投入运行，通过合理搭配不同类型的作业（如计算量大和 I/O 量大的作业），可以实现系统资源的高效利用。

缺点

作业周转时间长：用户向系统提交作业到获得系统的处理信息的时间间隔较长，即作业周转时间较长。这可能导致用户不能及时了解自己程序的运行情况并加以控制，使得用户使用计算机变得不方便
交互能力差：由于批处理作业通常是无人值守的，所以其交互能力相对较差。用户不能实时地与系统进行交互，获取实时反馈或进行实时控制。
运行过程不确定：批处理作业的执行过程可能不是完全透明的，用户难以准确预测和控制作业的执行结果和时间。

总结

批处理架构风格适合处理大量数据且无需实时用户交互的场景，通过明确的处理步骤和顺序，确保数据的完整性和处理的准确性。

管道 - 过滤器架构风格（Pipe and Filter）

每个过滤器（构件）都有一组输入和输出，它们读取输入的数据流，通过内部处理产生输出的数据流，这些过滤器通过管道连接，使得数据可以从一个过滤器流向另一个。前一个过滤器的输出是后一个过滤器的输入

主要特点：过滤器相对独立

主要优点：功能模块复用；可维护性和可扩展性较强；具有并发性；模块独立性高

主要缺点：不适于交互性强的应用，对于存在关系的数据流必须进行协调

优点详情

良好的隐蔽性和高内聚、低耦合：每个过滤器只关注其特定的处理任务，与其他过滤器的交互仅通过输入和输出进行，这有助于保持系统的模块化和清晰性。
支持软件重用：只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来，这增加了系统的灵活性和可扩展性。
方便维护和升级：新的过滤器可以方便地添加到现有系统中，而旧的过滤器也可以被改进或替换，无需对整个系统进行大规模修改。
支持并发执行：由于每个过滤器都是作为一个单独的任务完成，因此它们可以与其他任务并行执行，提高了系统的处理效率。

缺点详情

不适合处理交互的应用：由于数据在过滤器之间是以流的方式传递，这种架构风格在处理需要实时交互的应用时可能不太适用。
系统性能可能受限：如果数据在过滤器之间的转换和传递存在性能瓶颈，或者过滤器的处理速度不一致，可能会影响整个系统的性能。

总结

管道-过滤器架构风格适用于需要渐增式处理数据流的领域，如编译器、UNIX管道、图像处理、信号处理等。系统可划分清晰的模块；模块相对独立；有清晰的模块接口；

调用 / 返回风格（Call-and-Return）

主程序 / 子程序架构风格（Main Program and Subroutine）

这种风格一般采用单线程控制，显示调用，主程序直接调用子程序，将问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成为模块，而过程调用作为交互机制，即充当连接件。这种风格的调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性

优点

结构清晰，易于理解：该风格通过层次化的结构将复杂的问题分解为一系列易于处理和控制的子任务。主程序调用高层次的子程序，子程序再调用低层次的子程序，形成了一个清晰的层次结构。这种结构使得整个系统的执行流程变得清晰明了，便于开发人员理解和维护。
强控制性：由于主程序/子程序风格具有严格的层次分解和控制权转移机制，它对程序的实际执行过程具备很强的控制能力。这种控制性有助于确保程序的正确性和稳定性，降低出现错误的风险。
可维护性和可扩展性：通过将系统划分为相对独立的子程序，主程序/子程序风格提高了系统的可维护性和可扩展性。当需要修改或添加新功能时，只需要针对相应的子程序进行操作，而无需对整个系统进行大规模的修改。

缺点

连接件描述复杂：除了调用关系外，对于复杂的连接件难以进行准确的描述。这可能导致在理解和维护系统时存在一定的困难。
不易描述大规模软件：随着软件规模的增大，主程序/子程序风格可能难以有效地描述整个系统的结构和功能。这可能导致在开发大型软件项目时面临挑战。
可复用层次低：在主程序/子程序风格中，子程序的复用性可能受到一定的限制。由于子程序通常与特定的主程序相关联，因此它们可能难以在其他上下文中进行复用。

总结

综上所述，主程序/子程序架构风格在结构清晰、强控制性等方面具有优势，但在连接件描述、描述大规模软件以及可复用性方面存在不足。

面向对象架构风格（Object-Oriented）

面向对象架构风格是一种将数据和基本操作封装在对象中的软件设计方法。这种风格的核心思想是将系统划分为一系列相互协作的对象，每个对象都维护自身的完整性，并通过消息机制进行通信

面向对象架构风格的关键特性包括抽象性、组合性、继承性、封装性、多态性和解耦性。通过调用其他对象的方法或者访问属性来接收和发送信息。这种设计方法使软件更加模块化，代码更加封装和共享，从而提高了软件的可维护性、可扩展性和可重用性。

优点

易维护：由于继承的存在，当需要修改时，通常只需要修改局部模块，降低了维护的复杂性和成本。
可重用：在设计中，可以重复使用现有的、经过测试的类，以满足业务需求并提高软件质量
效率高：根据设计的需要，从现实事物的抽象中产生类，这种接近日常生活和自然的思考方式有助于提高软件的质量和效率。
易扩展：由于封装、继承和多态的特性，面向对象架构风格能够设计出高内聚、低耦合的系统结构，使得系统更加灵活，更容易扩展。

缺点

增加了对象之间的依赖关系。例如调用者必须要知道被调用者的引用，当对象的引用改变以后要通知所有调用它的对象，这可能导致系统内的高耦合

总结

面向对象架构风格是一种强大且灵活的软件设计方法，它适用于各种复杂系统的开发，能够提高软件的可维护性、可重用性和可扩展性。然而，在使用时也需要注意其可能带来的耦合性等问题

层次结构架构风格（Layered）

是一种将系统组织成层次结构的软件设计方法。这种风格中，各个层次的组件形成不同级别的虚拟机，多层相互协议工作，而且实现透明，通过决定层间如何交互的协议来定义连接件

优点

结构简单：系统层次分明，易于理解和维护
易于扩展：可以针对不同的层次进行独立的扩展，提高了系统的可扩展性
易于重用：不同层次的功能可以重复使用，提高了系统的可重用性
支持基于抽象程度递增的系统设计：设计者可以把一个复杂系统按递增的步骤进行分解
支持功能增强：每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层

缺点

性能开销：由于系统需要跨层次通信，会产生一定的性能开销
复杂性：系统需要管理多个层次之间的通信和依赖关系，具有一定的复杂性

总结

层次结构架构风格在多个领域有广泛的应用。例如在信息系统方面，它可以将网络划分为不同的层次，使得网络的实现更加灵活和易于管理。

层次结构架构风格是一种强大且灵活的软件设计方法，它适用于各种复杂系统的开发，能够提高系统的可维护性、可扩展性和可重用性。然而，在使用时也需要注意其可能带来的性能开销和复杂性等问题。

独立构件风格（Independent Components）

进程通信架构风格（Process Communication）

进程通信架构风格是一种实现进程通信时所采用的特定模式和原则，在这种架构风格中，构件被视为独立的过程，而连接件则是消息传递

优点

独立性：每个进程都是独立的，这意味着它们可以单独进行开发、测试、部署和升级，而不影响其他进程。这种独立性有助于降低系统的复杂性和提高可维护性。
灵活性：进程通信架构风格支持多种通信方式，包括同步、异步、点对点等，这使得设计者可以根据实际需求选择合适的通信方式，提高系统的灵活性。
可扩展性：由于进程是独立的，因此可以方便地添加新的进程或删除旧的进程，从而扩展或缩小系统的规模。
并发性：多个进程可以同时运行，处理不同的任务，从而提高系统的并发性能。

缺点

复杂性：进程通信通常需要涉及进程间的同步、互斥和错误处理等机制，这增加了设计的复杂性和实现难度。
开销：进程间的通信通常需要一定的开销，如上下文切换、消息传递等，这可能会影响系统的性能。
安全性问题：进程通信可能涉及敏感数据的传输，如果没有适当的安全措施，可能会导致数据泄露或被篡改。
依赖性问题：进程通信架构风格可能使得系统对特定的通信协议或机制产生依赖，这可能会影响系统的兼容性和可移植性。

总结

进程通信架构风格是一种有效且灵活的设计模式，适用于各种需要实现进程间通信和协作的场景

事件驱动架构风格（隐式调用架构风格）（Event-Driven）

事件驱动架构是一种流行的分布式异步架构风格，用于构建高可扩展和高性能的应用程序。它具有解耦、基于推送通知和消息传输机制

在事件驱动架构中，事件生产者和消费者之间不需要知道对方的具体身份，这使得服务非常松耦合，易于修改、测试和部署。

当事件发生时，订阅了该事件的组件会接收到事件通知并进行处理，这种事件驱动的方式可以更好地体现系统的实时性和灵活性，及时响应和处理各种业务场景下的事件。

优点

松耦合与高度解耦：事件驱动架构实现了组成部分之间的松耦合，因为它们只需要通过事件进行通信，而不需要知道彼此的具体实现。这种松耦合的特性使得各个组件更加独立，易于扩展和维护。
可扩展性与灵活性：事件驱动架构模式可以轻松地添加或删除组成部分，因为它们只需要订阅或取消订阅事件即可。这使得应用程序可以轻松地适应变化，并具有更高的可扩展性。同时，这种架构风格也支持功能的灵活扩展和定制。
实时性与响应性：组件之间通过发布-订阅模式进行通信，事件驱动的方式使得系统能够实时地响应和处理各种业务场景下的事件，提高了系统的实时性和响应性。
容错性与可恢复性：由于事件驱动架构中的组件是相互独立的，某个组件的故障或异常不会影响整个系统的正常运行。此外，通过合理的设计和使用适当的消息队列等机制，可以实现事件的持久化和重放，从而提高系统的容错性和可恢复性。

缺点

复杂性：事件驱动架构涉及异步编程，需要考虑远程通信、失去响应等情况，因此开发相对复杂。同时，由于事件可能涉及多个处理器，实现原子性操作较为困难，很难进行回滚。
测试难度：事件驱动架构的分布式和异步特性导致其测试较为困难。需要设计合适的测试策略和方法，以确保系统的正确性和稳定性。
不适用于顶层架构：尽管事件驱动架构在通信产品等场景中应用广泛，但它可能并不适合作为整个系统的顶层架构。它更适合作为局部实现，与其他架构风格结合使用，以充分利用其优势并避免潜在的缺点。

总结

事件驱动架构风格是一种强大且灵活的架构风格，能够支持高可扩展性和高性能的应用程序构建。然而，在使用时需要考虑到其异步编程的复杂性以及测试的难度。如程序语言的语法高亮，语法错误提示

虚拟机风格（Virtual Machine）

解释器架构风格（Interpreter）

核心思想是通过构建一个解释器来解释并执行特定领域 / 问题领域的语言/规则。该架构风格中的解释器负责仿真硬件的执行过程和一些关键应用

解释器架构风格具有一些明显的特点，它的系统核心是虚拟机，用于仿真硬件的执行过程

优点

高度的灵活性和可扩展性：解释器架构风格允许动态地添加、修改或替换解释器，以适应不断变化的需求。当需要支持新的领域特定语言（DSL）或规则时，可以轻松地扩展架构，而不会对现有的解释器产生影响
模块化设计：解释器架构通常包含模块化的解释器，每个解释器负责解释特定部分的DSL或规则。这种模块化设计使得系统的维护和修改变得更加容易。
提高应用程序的移植能力和编程语言的跨平台移植能力：利用解释器，可以更容易地实现硬件仿真和跨平台功能。

缺点

执行效率较低：由于解释器通常需要大量的循环和递归调用，特别是在处理复杂的DSL句子时，其运行速度可能会受到影响，导致执行效率相对较低。
可能导致类膨胀：在解释器模式中，每条规则至少需要定义一个类。当包含的文法规则非常多时，类的数量会急剧增加，导致系统变得难以管理和维护。
调试过程复杂：由于解释器架构的复杂性和特定的执行方式，代码的调试过程可能会相对复杂和困难。

总结

解释器架构风格常用于日志处理，规则引擎，脚本语言实现，编译器设计

规则系统架构风格（Rule-Based）

强调通过定义一套规则来指导系统的构建和运行。这种架构风格的核心在于将业务逻辑或决策逻辑与系统的其他部分相分离，使得规则可以独立地进行管理和修改。

在规则系统架构中，规则通常包括一系列的条件和动作，当满足特定条件时，系统会自动执行相应的动作。这些规则可以存储在规则库中，并通过规则引擎进行管理和执行。规则引擎负责解析规则、匹配条件和执行动作，是规则系统的核心组件。

优点

业务逻辑灵活性：规则系统架构风格将业务逻辑与系统的其他部分相分离，这使得业务规则可以更加容易地进行修改和调整。业务人员或分析师可以在不依赖开发人员的情况下，直接对规则进行修改，从而加速业务响应速度。
规则的可复用性：在规则系统中，规则通常是可复用的。这意味着相同的规则可以在不同的场景或应用中重复使用，减少了重复开发的工作量，提高了代码的重用率。
决策流程透明性：规则系统架构使得系统的决策流程更加清晰和透明。规则的定义和执行过程都是明确的，有助于理解和优化系统的决策过程。
系统可扩展性：由于规则是独立管理的，当需要添加新的业务规则或修改现有规则时，无需对整个系统进行大规模的修改，从而提高了系统的可扩展性。

缺点

规则制定和管理的复杂性：制定和管理规则需要一定的专业知识和经验。如果规则制定不当或管理不善，可能会导致系统出现错误或不一致的决策
性能问题：当规则集变得非常庞大和复杂时，规则引擎在解析、匹配和执行规则时可能会消耗大量的计算资源，导致系统性能下降。
维护成本：虽然规则系统架构提高了业务逻辑的灵活性，但也增加了系统的维护成本。随着业务规则的不断变化和更新，需要定期维护和更新规则库，以确保系统的正常运行。
学习曲线陡峭：对于不熟悉规则系统架构的开发人员或业务人员来说，可能需要一定的时间来学习和掌握这种架构风格的使用方法和技巧。

总结

规则系统架构风格适用于那些需要频繁调整业务规则或决策逻辑的应用场景，如金融风控、电商推荐、智能客服等领域。通过使用规则系统架构，企业可以更加灵活地应对市场变化和业务需求的变化，提高系统的适应性和可扩展性。常用于 DSS ，人工智能，专家系统等领域

仓库风格（Warehouse）

数据共享架构风格（Data Sharing）

主要关注如何有效地处理数据共享和访问的问题，中央数据单元实现了数据的集中，以数据为中心。数据共享架构风格倾向于将数据集中存储在中央存储库中，并提供一套标准的数据访问接口。这种方式确保所有的数据访问都可以通过这些接口进行，而不需要直接访问底层的数据存储。这种设计提高了数据的可访问性和可用性，使用户能够方便地访问和使用数据，无论数据实际存储在哪里。

优点

提高数据可访问性和可用性：通过集中存储和提供统一的数据访问接口，用户可以方便地访问和使用数据，无论数据实际存储在哪里。这大大提高了数据的可访问性和可用性，使得数据能够更好地支持业务决策和流程。
降低数据管理成本：通过集中存储数据，这种架构风格有助于避免数据重复存储和管理的问题，从而降低了数据管理的成本。
支持多种数据源：数据共享架构风格能够支持多种不同类型的数据源，包括关系型数据库、NoSQL数据库以及文件系统等。这使得该架构风格具有更强的灵活性和适应性，可以满足不同业务场景的需求。

缺点

数据安全隐患：如果数据泄露或被攻击，可能导致严重的后果，尤其对于个人隐私数据和企业敏感信息，这种风险更为严重。
数据一致性问题：在多个用户共享数据的情况下，数据一致性可能会受到影响。如果没有有效的管理和控制措施，可能会导致数据的混乱和错误，影响工作和决策的准确性。
依赖网络稳定性：数据共享架构风格的应用需要依赖互联网的稳定性和带宽。如果网络出现故障或带宽不足，将影响用户对数据的访问和共享，进而影响工作效率。

总结

数据共享架构风格提供了一种有效的框架来处理数据共享和访问的问题。适用于人工智能，专家系统等领域。

超文本架构风格（Hypertext）

是一种基于超文本和链接的架构风格，它允许用户通过点击链接在文档或网页之间自由导航。这种架构风格的核心思想是提供一种非线性的、灵活的、关联性的信息访问方式。这种架构风格在数字世界中非常普遍，特别是在网页设计和内容管理中。

优点

非线性导航：超文本架构提供了非线性的浏览体验，用户可以根据兴趣自由跳转，不必按照固定的顺序阅读或浏览内容。
灵活性和可扩展性：超文本结构可以很容易地添加、删除或修改内容，而不影响整个系统的结构。这种灵活性使得网站或应用程序能够随着时间和需求的变化而发展。
媒体集成：超文本架构可以轻松集成文本、图像、音频、视频等多种媒体类型，为用户提供丰富的多媒体体验。
搜索和索引：超链接可以被搜索引擎有效索引，使得用户能够更容易地找到相关信息。同时，内部链接也帮助用户更好地理解内容的结构和关系。

缺点

信息过载：由于超文本架构的非线性特性，用户可能会迷失在大量的链接和信息中，难以找到真正需要的内容。
设计复杂性：设计和维护一个结构清晰、易于理解的超文本架构可能需要较高的技能和经验。如果设计不当，可能会导致用户体验下降或导航困难。
技术依赖：超文本架构依赖于特定的技术标准和协议（如HTTP、HTML等）。如果这些技术发生变化或被替代，可能需要对架构进行更新或重构。
安全性问题：超链接可能会被用于恶意目的，如传播恶意软件或进行网络钓鱼攻击。因此，需要采取适当的安全措施来保护用户免受潜在威胁。

总结

超文本架构风格广泛应用于互联网和移动应用等领域，例如，在网页设计中，通过使用超链接将不同页面连接起来，用户可以方便地浏览网站内容

黑板架构风格（Blackboard）

黑板架构风格是一种分布式的问题求解架构，它通过共享的工作内存。即“黑板”，来存储问题的状态和求解过程。在黑板架构中，多个处理元素或知识源可以独立地访问和修改黑板上的数据，从而实现信息的交流和共享。

优点

可扩充性强：黑板架构允许方便地添加新的知识源代理和扩展共享的黑板数据结构，这使得系统具有很高的灵活性。
支持多客户共享大量数据：在黑板架构中，多个客户可以共享黑板上的数据，而无需关心数据的产生、提供方式和时间。
知识源可重用：由于知识源是独立的，因此可以在不同的场景和任务中重用。
支持容错性和健壮性：黑板架构能够处理部分知识源的失效，保证系统的整体稳定性和可靠性。

缺点

数据结构修改困难：由于不同的知识源代理需要就共享数据结构达成一致，这可能导致对黑板数据结构的修改变得较为困难，需要考虑到各个代理的调用。
需要同步/加锁机制：为了保证数据结构的完整性和一致性，黑板架构需要采用一定的同步或加锁机制，这增加了系统的复杂度和潜在的性能开销。

总结

在实际应用中，黑板架构风格可以通过多种方式实现，例如利用关系数据库或消息队列作为黑板，实现数据的共享和修改。这种架构风格在需要处理复杂且不确定问题的场景中具有广泛的应用价值，如信号处理、模式识别等领域。

闭环风格（Closed-Loop）

过程控制架构风格（Process Control）

过程控制架构是一个复杂且多层面的概念，它涉及连续生产过程的自动控制。

连续生产过程的自动控制：过程控制主要针对连续生产过程，其被控量需要定量控制，并且这种控制应该是连续可调的。这意味着控制系统需要能够实时地、连续地监测和调整生产过程，以确保其按照预设的目标进行。

优点

自动化与高效性：过程控制架构通过自动化控制系统可以大大提高生产效率，减少人为干预和错误，使生产过程更加稳定可靠。
实时性：过程控制架构能够实时地对生产过程进行监测和调整，及时发现问题并采取相应的措施，从而确保产品质量和生产安全。
灵活性：过程控制架构通常具有模块化设计，使得系统可以根据生产需求进行灵活配置和扩展

缺点

初始投资成本较高：过程控制架构的建设需要投入大量的资金，包括硬件设备、软件系统和专业人员培训等方面的费用。
技术复杂性：过程控制架构涉及多个学科领域的知识和技术，如自动控制、计算机科学、通信技术等，因此其设计、实施和维护都需要较高的技术水平。
对人员技能的依赖：虽然过程控制架构可以自动化大部分生产过程，但仍然需要专业人员进行系统的操作和维护。如果人员技能不足或缺乏经验，可能会影响系统的正常运行和效果。

总结

例如汽车巡航定速，空调温度调节，设定参数，并不断调整，会不断的测量被控对象，调整被控对象

c2 架构风格

C2架构风格是一种基于组件和消息的架构风格。旨在创建灵活且可扩展的软件系统。C2架构的核心在于其组件化设计，系统中的每个构件都可以实现特定的应用需求，并将任意复杂度的功能封装在一起。构件之间的通讯完全依赖于消息传递机制，通过连接件（如消息路由设备）进行异步消息交换。这种设计方式使得构件相对独立，构件之间的依赖性较少

优点

灵活性：C2架构风格通过组件化和消息传递机制，使得系统更加灵活。每个组件都可以独立地进行开发、测试和替换，而不需要对整个系统进行重构。这种灵活性有助于快速响应业务变化和技术更新。
可扩展性：C2架构允许通过添加新的组件和连接件来扩展系统的功能。由于组件之间的松耦合设计，新的组件可以很容易地集成到现有系统中，从而实现系统的平滑扩展。
可维护性：由于C2架构中的组件相对独立，因此当某个组件出现故障或需要升级时，可以单独对其进行处理，而不会影响整个系统的运行。这降低了系统的维护成本，提高了系统的稳定性。
易于理解：C2架构具有清晰的分层和组件化设计，使得系统结构更加直观和易于理解。这对于开发人员来说，可以降低学习成本，提高开发效率。

缺点

性能开销：C2架构中的消息传递机制可能会引入额外的性能开销。特别是在高并发或实时性要求较高的场景下，消息传递的延迟和开销可能会对系统性能产生较大影响。
学习成本：对于不熟悉C2架构的开发人员来说，可能需要一定的时间来学习和掌握其设计原则和实现方式。这可能会增加项目的初期投入成本。

总结

C2架构风格适用于创建灵活且可扩展的软件系统，它通过将系统划分为独立的构件和连接件，降低了系统的耦合度，提高了系统的可维护性和可扩展性