企业集成两种架构模式

在本文中,我们将探讨一些可用于不同集成项目的架构模式。


在详细介绍集成架构之前,了解集成架构中常用的组件及其应用很有用。

1、集成平台:
这是集成架构的主要组成部分。集成平台执行集成流程并提供一组连接器和协议以与其他系统集成。它们还包括高级数据转换功能,以便在不同系统之间映射数据结构。

2、API 管理:
通过为服务调用提供身份验证、访问控制、速率限制和使用情况监控,将集成服务作为 API 公开。

何时使用:如果集成向外部方或其他业务部门公开。

3、身份和访问管理 (IAM) 系统:
为集成部署提供高级安全功能。

何时使用: API 管理器还提供一定程度的安全功能,例如身份验证和访问控制。如果需要支持更高级的安全功能(例如多因素身份验证、访问控制策略和成熟的用户管理),则可以使用 IAM 系统。

4、注册表:
提供一个用于存储集成工件的集中位置。

何时使用:某些集成工件(例如端点和数据模式)可能在多个集成中重复使用。此外,端点可能会因服务的重新定位而发生变化。在这种情况下,将这些集成工件存储在注册表中并配置所有集成以从注册表中查找这些工件会很有帮助。

5、消息平台:
提供具有消息持久性的发布-订阅和多播消息传递。

何时使用:如果需要频繁更改消息的收件人,并且需要避免消息在处理过程中丢失。

6、可观察性组件:
为部署提供监控和分析功能,例如使用情况仪表板、消息流分析、日志分析、资源消耗指标以及基于预配置阈值的通知。

何时使用:有助于了解部署状态并采取预防措施。

有了关于集成架构组件的知识,现在我们可以探索不同的架构及其用途。

集中集成
在此架构中,中央集成平台用于部署集成。API Manager 和架构的其他组件也部署为中央部署。中央集成平台以及其他组件通常部署为两个或多个实例的集群,以促进可扩展性和高可用性。

何时使用集中式集成
当组织的所有集成都由中央团队管理时,集中式集成非常有用。多个团队仍然可以开发集成。但是,集成的部署要么由中央团队执行,要么由中央团队批准。集成的运营方面也由该中央团队处理。这种架构有助于更好、更简单地管理集成,并且通常对基础设施的要求较低。这种方法的主要缺点是集成开发的灵活性降低,因为集成开发人员必须依赖中央团队进行部署。

微服务式集成(微集成)
在这种架构中,集成以微服务的形式部署。与单个集成任务相关的少量集成(通常由单个团队开发)部署到集成运行时中。根据集成任务和开发团队的数量,部署多个集成运行时。API 管理组件也可以根据微服务风格(即微 API 网关)进行部署。通常,这些集成运行时专门设计为消耗更少的资源并支持在 Kubernetes 等容器化环境中部署。

何时使用微集成
当需要促进大量团队之间更独立的集成开发时,微集成非常有用。由于它减少了集中治理流程带来的瓶颈,因此可以快速将集成投入生产并逐步改进。一些主要缺点是需要使用 Kubernetes 等容器平台来管理集成运行时,并且需要实施复杂的监控解决方案来获取有关集成的整体分析。

混合集中式和微集成
这种架构既有利于集中式集成,也有利于微集成。因此,这种架构的集成层由一个中央集成平台和多个微集成运行时组成。API 层也可以有集中式 API 网关和 API 微网关的组合。

何时使用组合集成架构
大型组织中可能存在两类集成:

  • 1) 连接较低级别服务的集成,这些服务通常由单个业务部门访问;
  • 2) 跨多个业务部门并访问敏感服务的集成。
在这种情况下,第一类集成可以部署为微集成,可以在业务部门内开发并投入生产。第二类集成需要更多的治理,需要多个利益相关者的批准并可以访问多个服务。因此,这些集成可以以集中的方式实施。

结束
本文讨论的架构模式可以作为选择适合集成项目的架构的指南。但是,架构及其组件的选择需要考虑集成的性质、非功能性要求、组织规模、可用基础设施和预算等因素。