什么是基于组件的架构？
可以将组件想象成乐高积木。
用乐高积木搭建结构时，您可以选择各种形状、大小和颜色。有些积木是专门用来做门、窗和其他结构元素的。每个积木都具有连接其他积木所需的所有功能，并且添加或减去积木通常对结构的影响很小。
软件组件比小块塑料复杂得多，但概念是相似的。
每个元素都以架构定义的方式执行任务。为简单起见，组件存储在库中，由开发人员组装，并通过 API 相互通信。
对象请求代理（有时称为“软件总线”）通过提供所有组件使用的单一通信平面来促进通信。通信可以通过多种方式进行，例如 异步、通过广播、通过消息驱动系统或作为正在进行的数据流的一部分。
基于组件的架构概念并不新鲜，早在 1960 世纪 XNUMX 年代末的学术论文中就提到过它。
IBM 推出了 系统对象模型 1990 世纪 XNUMX 年代初，第一个定义用组件构建软件的方法的商业尝试。微软的 组件对象模型 和 对象链接和嵌入大约在同一时间推出，提供了第一个用于商业部署的框架。
组件的 5 个特点
软件组件有五个共同的特征；
1.可重用性
组件可插入各种应用程序，无需修改或特殊调整。
2.可扩展性
组件与其他组件相结合可以创建新的行为。
3.可替代性
具有类似功能的组件可以互换。
4。 封装形式
组件是独立的，通过接口公开功能，同时隐藏内部流程的细节。
5。 独立
组件对其他组件的依赖性最小，并且可以在不同的环境和上下文中运行。
组件示例
组件是面向服务和微服务架构的构建块，它由松散耦合和离散的服务组装成应用程序。
微服务是 DevOps 中使用的主要架构，并且 云原生开发. 它的价值在于其生产力优势，因为开发人员可以组装大部分应用程序，而不是从头开始构建。
组件的一个例子是 Microsoft PowerPoint 中的电子表格功能。用户在编辑图表或图形下的数据时，使用的电子表格的外观和功能与 Microsoft Excel 类似。虽然它不是 Excel 的完整版本，但电子表格小部件具有足够的功能来支持基本功能。
其他组件示例包括在电子商务交易中计算税额的功能或要求用户在登录时回答问题的功能。
与组件的权衡
基于组件的架构可能存在缺点，因为它并不适合所有场景。
首先，应用程序必须分解为模块化且功能独立的部分，当应用程序规模较大时，这可能是一个挑战。此外，对组件可重用性的需求可能会限制其自定义选项。
找到完全符合应用程序要求的组件也很有挑战性。给定应用程序中可能需要监控许多组件，而组件库的更新和维护可能很复杂。
组件的替代品
基于组件的开发和架构有许多替代方案。其中包括：
- 微内核架构 由核心处理组件和具有特定功能的独立插件模块组成。组件之间不进行通信，只与微内核进行通信。
- 客户端-服务器架构 有两个组件交换数据、服务和内容请求：客户端和服务器。否则，它们大多独立运行。
- 事件驱动架构 由解耦的专用软件模块组成，这些模块会响应事件（例如刷信用卡或使用传感器生成警报）而采取行动。
组件已成为现代软件的基本组成部分。尽管这个术语已有 20 多年历史，但这个概念是合理的，并且已被证明能够适应不断变化的技术格局。