什么是基于组件的架构？

基于组件的架构是一种基于可重用部件构建软件的框架。每个组件都包含定义明确的二进制功能，这些功能存储在库中，无需修改其他组件即可直接放入应用程序中。

可以将组件想象成乐高积木。

用乐高积木搭建建筑物时，你可以选择各种形状、尺寸和颜色。有些积木专门用来做门、窗和其他结构元素。每个积木都具备连接其他积木所需的所有功能，而且增减积木通常对结构的影响很小。

软件组件比小块塑料复杂得多，但概念是相似的。

每个元素都以架构定义的方式执行任务。为简单起见，组件存储在库中，由开发人员组装，并通过 API 相互通信。

对象请求代理（有时称为“软件总线”）通过提供所有组件使用的单一通信平面来促进通信。通信可以通过多种方式进行，例如 异步、通过广播、通过消息驱动系统或作为正在进行的数据流的一部分。

历史背景

基于组件的架构概念并不新鲜，早在 1960 世纪 XNUMX 年代末的学术论文中就提到过它。

IBM 推出了 系统对象模型 1990 世纪 XNUMX 年代初，第一个定义用组件构建软件的方法的商业尝试。微软的 组件对象模型 和 对象链接和嵌入大约在同一时间推出，提供了第一个用于商业部署的框架。

组件的 5 个特性和优点

软件组件有五个共同的特征。

1.可重复使用

组件无需修改或特殊调整即可插入各种应用程序。它们还可以在应用程序的不同部分甚至不同的项目中重复使用，从而减少代码和工作的重复。

2.可扩展

组件与其他组件组合起来，可以创建新的行为。它们可以 更换或延长 对系统其余部分的影响最小，使升级和定制变得更加容易。

3. 可扩展

各个组件可以根据需求独立扩展。通过添加或修改组件，无需重新设计整个应用程序，即可更轻松地扩展系统。

4.可维护

组件是独立的，通过接口公开功能，同时隐藏内部流程的细节。由于组件封装了特定的功能，因此更容易隔离、更新和修复系统的某些部分，而不会影响其他部分。

5。 独立

组件与其他组件的依赖性极小，并且可以在不同的环境和上下文中运行。每个组件专注于特定的功能，从而促进更简洁、更有条理的代码和更完善的系统结构。

可组合架构与微服务

组件和微服务都提供灵活且可扩展的软件开发和管理，但也存在一些关键区别。

• 微服务 可以成为可组合架构的一部分。但是 可组合架构 与微服务架构相比，它涵盖了更广泛的组件和更大的服务。
• 微服务 以后端为重点。 可组合架构 更全面，适用于全栈（前端、后端、编排）
• 组件 紧密结合，同时 微服务 是解耦的。
• 微服务 比组件更细粒度。每个服务处理一个特定的任务，而 组件 可以包括更广泛的模块或整个应用程序。

微服务是 DevOps 中使用的主要架构，并且 云原生开发. 它们的价值在于其生产力优势，因为开发人员可以组装大部分应用程序，而不是从头开始构建。

组件示例

组件的一个例子是 Microsoft PowerPoint 中的电子表格功能。用户在编辑图表或图形下的数据时，使用的电子表格的外观和功能与 Microsoft Excel 类似。虽然它不是 Excel 的完整版本，但电子表格小部件具有足够的功能来支持基本功能。

其他组件示例包括在电子商务交易中计算税额的功能或要求用户在登录时回答问题的功能。

与组件的权衡

基于组件的架构可能存在缺点，因为它并不适合所有场景。

首先，应用程序必须分解为模块化且功能独立的部分，当应用程序规模较大时，这可能是一个挑战。此外，对组件可重用性的需求可能会限制其自定义选项。

找到完全符合应用程序要求的组件也很有挑战性。给定应用程序中可能需要监控许多组件，而组件库的更新和维护可能很复杂。

组件的替代品

基于组件的开发和架构有许多替代方案。其中包括：

• 微内核架构 由核心处理组件和具有特定功能的独立插件模块组成。组件之间不进行通信，只与微内核进行通信。
• 客户端-服务器架构 有两个组件交换数据、服务和内容请求：客户端和服务器。否则，它们大多独立运行。
• 事件驱动架构 由解耦的专用软件模块组成，这些模块会响应事件（例如刷信用卡或使用传感器生成警报）而采取行动。

基于组件的架构是现代软件开发的流行选择，尤其是在构建复杂、模块化和可维护的系统时。