在自适应企业中实现整合

在现代企业中，很难看到统一整个环境的单一整体应用程序。虽然仍然可能存在大型主机或其他系统来保存组织的主要数据和事实来源（SoT），但如今大多数环境都具有满足各种业务功能的中型到大型应用程序。根据企业的规模和复杂程度，这些应用程序可以从少数应用程序到数百种应用程序。

虽然很明显集成成本随着应用程序的数量而增加，但人们也可以争辩说，随着您逐渐远离“一个应用程序完成所有”模型，变更成本会降低。这一论点背后的原因是，每一次变化，无论多小，通常都会导致整体应用程序的完全重新部署，并且必然会导致整个系统的回归测试成本。

但除了成本和应用数量之外，还有一个额外的维度需要考虑 - 时间。并非所有应用都是平等的。任何架构图的问题在于它代表了历史中的单个点 - 它本质上是一个快照。现实是应用程序随时间而变化; 一些已升级，另一些已修改或扩展，其他可能被删除或替换。这些应用程序的变化率各不相同，因为有些系统的变化速度比其他系统慢。这可以在分层视图中表示：

应用程序架构中的层概念并不新鲜;大约十年前，Gartner创建了Pace分层应用战略，以解决业务领导者（他们希望系统灵活并适应业务环境变化）与IT所有者（通常希望系统保持一致）之间的共同脱节。他们运行顺利）。识别这些不同的变化率并相应地对应用程序进行分组有助于应用适当级别的治理，变更控制，测试和DevOps - 使业务能够在需要的地方进行创新，同时保护其关键数据和核心流程。

了解Pace-Layered Architecture

Gartner的Pace-Layered模型由三层组成：

记录系统（SOR） -

这些系统支持组织的核心功能，没有这些功能，企业就无法运行。由于这些通常是整个行业的标准，因此这些功能并非给定品牌或业务所独有（例如，每家银行都需要管理帐户，交易，客户等）。因此，这些系统通常是供应商提供的商业现货（COTS）产品。由于组织的核心能力不会经常发生变化，因此这些系统也不会发生变化 - 变化是递增的，而且速度很慢。

差异化系统 -

虽然核心功能在同一行业中从一个组织到另一个组织的变化不大，但业务流程确实如此。例如，您的银行和我的银行都可以提供贷款，但这两家银行处理贷款的方式可能会有所不同。此层中的应用程序代表使组织独一无二的流程，并且通常不会由供应商提供的记录平台系统开箱即用。业务流程可能不会每天都在变化，但它们确实比核心功能更快地发生变化，例如简化流程和/或整合新技术。

创新系统 -

这一层移动速度最快。这是测试新想法和技术的“沙坑”。这里的实验可能包括特定的概念验证（PoC）应用程序，这些应用程序可以快速开发，然后手动部署和测试。

图片基于Michael Guay（Gartner）的演讲

让我们看一个示例企业，例如银行机构，看看他们的一些应用程序如何映射到速度分层模型。

系统/应用特点记录系统ABC银行有几个关键系统，包括核心银行系统，贷款管理系统和文件库。

  • 这些系统由供应商提供和安装。

  • 预计它们的寿命很长（例如7 - 10年）

  • 变更控制非常严格，数据受到严密保护。

  • 系统受到立法机构的审计。

差异化系统 自动贷款处理功能由定制的集成解决方案管理，该解决方案集成了多个外部SaaS服务，用于房地产估价，标题搜索，信用评分和在线Web表单提供程序。

  • 该解决方案通过大型项目的多个阶段提供。

  • 预计中等寿命（3 - 4年）。

  • 修复和变更请求通过BAU团队进行管理。

创新系统ABC银行希望提供一个基于聊天的界面，用于提供由智能机器人提供支持的贷款申请。

  • 概念验证解决方案采用最少的功能构建并手动部署

  • 它由一小部分客户进行测试。

  • 在解决方案稳定之前，无需正式的变更控制流程即可快速完成调整和错误修复。

  • 经过几个月的试用后，决定是将解决方案推进到完全成熟的应用程序还是取消该计划。

在Pace-Layered架构中集成

现在我们了解了分步模型，我们如何在其中实现集成？让我们看一下API / Services的逻辑模型如何看待它们如何在各层之间组合成应用程序：

从底层开始，我们看到每个记录系统通常是一个包含多个服务/ API的包。但是，由于与逻辑数据模型，过时协议或其他原因不一致，这些API可能无法由业务直接使用。在这些情况下，最好引入API的“子层”，将SoR与组织内的其他API联系起来。这些抽象API（称为产品适配器）与底层SOR紧密耦合，但以更加可口的格式公开功能。它们还可能引入比SOR本身更严格的访问控制，验证和安全性。API通常代表核心数据实体（客户，产品，订单等），因此它们是粒度的并且是为可重用性而设计的。因为它们与核心系统紧密相连，所以它们以相同的速度移动，因此被认为是记录系统层的一部分。由于数据的重要性以及使用这些API的服务和流程的高度依赖性，治理和变更控制在此级别通常会非常严格。

在差异化系统层中，我们看到的应用程序由源自记录系统层的粒度服务/ API以及可能的外部API组成。这是组织的业务逻辑所在的位置，例如贷款处理或用户供应。应用程序可以在此层中执行的功能包括数据聚合，路由，过滤以及通常编排/编排。由于它们特定于进程，因此它们可能比它们可能使用的底层SOR API更不可重用。在该层中，组织内的大部分集成发生。而且由于业务流程可以（并且将会）随着时间的推移而发生变化，因此这些应用程序也需要进行调整，而且肯定会比SOR应用程序更快地进行调整。治理也应该在这个层面上应用，尽管可能不像SOR层那样严格;组织希望他们的业务流程足够灵活，以适应效率的提高和功能的扩展。

创新系统层还具有同时使用SOR API和外部API的应用程序，以及可能在差异系统层中使用业务流程的应用程序。作为最快的移动层，它将具有更轻的治理，以促进新应用程序和技术的实验。此层中启用的功能通常是业务核心功能的外围设备，因此在发生故障时可以降低组织的风险。此外，为了证明概念而快速创建的应用程序很少会采用自动化测试或成熟的CI / CD管道，因为它们将被手动部署和测试。

最后，我们使用消息总线以便促进层间和层内通信。异步消息传递模式（如发布 - 订阅）可以使系统松散耦合，并提高可扩展性和灵活性。发布者无需了解订阅者的任何信息，您可以随时添加或减少订阅者，而不会破坏现有的集成。消息总线是润滑不同速度变化的应用之间摩擦的关键因素。

此图提供了几个属性的横截面视图以及它们在各个层之间的变化：

Microsoft如何帮助实现Pace-Layered Integration？

Microsoft提供一系列服务和产品，包括本地和云端，以帮助构建功能强大的集成解决方案，以应对企业应用程序层的不同步伐。在这里，我们将仅讨论其中一些产品以及它们如何适应速度分层架构（请注意，有许多可能的解决方案;这些建议只是一种可能的方式来看待这一点）：

记录系统层

以下产品非常适合在SOR应用程序之上构建API层：

技术 场景 考虑

产品

APIs

  • 产品具有粒度API和现代界面

  • API符合业务需求

  • 供应商支持可用

+与记录系统紧密集成

- 更改或定制困难或昂贵

- 可能不适合业务数据模型

Web

服务

/REST

API

  • 公开REST或SOAP接口

  • 实现自定义验证/安全性

  • 映射到规范模型

+主机价格低廉

+易于消费

+可以在本地或Azure（IaaS）托管

- 需要开发工作

API管理

  • 在云中公开API

  • 实施基于策略的安全性和访问控制

  • 利用缓存/审计/分析/等。

+可定制的外观

+开发者门户促进了新的应用创建

- 需要VNet集成 - 没有本地选项

- 如果不使用其他功能，则选择昂贵的选项

Service Fabric

  • 与微服务架构对齐

  • 迎合多种编程语言

  • 自动冗余，负载平衡和

  • 无需停机部署

+可以在任何地方托管

+支持容器

- 需要大量开发工作（不提供OOTB软件组件）

BizTalk Server

  • OOTB适配器可用/适用

  • 需要强大的平台

+ BAM跟踪可用

+单一平台集成

- 昂贵的选择

- 需要专业的开发技能

- 未来的支持模型

差异化系统层(System of Differentiation Layer)

这些产品能够实现业务逻辑，提供与内部和外部应用程序和服务的连接，并支持跨云和本地应用程序的混合连接：

技术 场景 考虑 Logic Apps

  • 业务逻辑可以是云托管

  • 连接SaaS系统或其他Azure服务

+快速发展

+超过200个内置连接器！

- 没有VNet支持（直到ISE可用）

- 没有本地选项（尚未）

Azure Functions

  • 需要按需运行离散的无状态任意代码片段

  • 与其他Azure服务集成

  • Visual Studio开发是首选

  • 自动化单元测试是必须的

+良好的CI / CD支持

+ VNet支持

+可以在本地运行

- 没有Logic Apps那么多的连接器

Web/Mobile Apps

  • 云托管是理想的

  • 支持多种设备

  • 需要灵活的编程模型

  • 需要接触外部客户

  • 期待 Blue / Green部署插槽

+良好的CI / CD支持

+众多部署选项

+支持Azure Relay / VNet集成

- 对于长时间运行的过程本身并不理想

- 考虑混合应用程序的安全层

Service Fabric

  • 与微服务架构对齐

  • 迎合多种编程语言

  • 需要自动冗余，负载平衡和无停机时间部署

+可以在任何地方托管

+支持容器

- 需要大量的开发工作

- 基础设施投资（仅限本地）

BizTalk Server

  • OOTB适配器可用/适用

  • 需要强大的平台

  • 需要可靠/耐用的工作流程功能

  • 利用业务规则引擎和/或BAM

+单一平台进行整合

+可以在本地或Azure（IaaS）托管

- 昂贵的选择

- 需要专业的开发技能

- 未来的支持模型

创新系统层

在这里，我们需要能够将技术范围扩展到人工智能，预测分析和业务洞察领域，同时实现快速（甚至临时）开发。这里有很多可能性，因为与使用它的方式相比，它更少涉及您使用的技术。但这些产品都非常适合创新的解决方案：

技术 场景 考虑

Microsoft

Flow

  • 自动化简单的流程和任务

  • 使业务用户能够创建自己的集成

  • 现有连接器适合用途

+快速发展

+可以轻松迁移到Logic Apps

*需要Office365

Power

Apps

  • 开发设备的内部应用程序

  • 利用内置连接器

+与Flow / SharePoint /轻松集成
Dynamics 365 /团队/等

+多平台

*需要Office365

Power BI

  • 需要快速构建自定义图表和视觉效果

  • 与多个数据源集成

*依赖于对数据源的访问 Cognitive Services

  • 寻求高级见解和分析能力

+提供多种服务/ API（Vision，Knowledge，
语言，语音，搜索）

*需要编程技能

Machine Learning

  • 通过预测分析寻求见解

*需要数据科学技能 Bots

  • 寻求与客户的更多人际互动

  • 自动化例行信息检索或路由到适当的支持人员

*需要编程技能

*机器人需要经过良好的训练才能按预期运行

消息总线

如果您主要集成本地系统，BizTalk Server的核心是一个功能强大的消息传递引擎，它不仅可以支持全部的消息传递模式，还可以提供几个开箱即用的连接器以实现连接。强大的业务流程自动化功能 这就是它在很多层中的特征。然而，当在云中集成时，Azure Service Bus为企业消息传递，大数据流，事件处理和混合连接提供了许多产品：

技术 场景 考虑 Event Grid

  • 构建事件驱动的应用程序

  • 管理通知

  • 需要高可扩展性和吞吐量

  • 处理Azure（或任何地方）内的事件

+弹性（重试最多24小时）

+推 - 推模型

+易于集成

*小消息大小

Event Hubs

  • 摄取大数据/流数据

  • 需要重播/存档

*至少需要一个下游处理器

- 没有本地选项

Relays

  • 需要混合连接，无需更改防火墙

+可以使用混合连接或WCF中继 On-Prem Data Gateway

  • 将逻辑应用程序连接到本地系统

  • 将SaaS应用程序桥接到LOB系统

+如果使用Logic Apps，则可以替代VNet

- 仅少数Logic App连接器支持

Service Bus Queues

  • 解耦发送方/接收方进程

  • 每条消息只应处理一次

  • 数据可以流经云端

+极具弹性和功能齐全

- 没有本地选项

Service Bus Topics

  • 通过pub / sub解耦系统/进程

  • 支持多个订阅者的消息

  • 数据可以流经云端

+极具弹性和功能齐全

- 没有本地选项

BizTalk Server

  • 需要强大的发布/订阅消息

  • 利用BAM进行跟踪

  • 使用OOTB适配器

  • 仅限于本地解决方案

+单一平台进行整合

- 昂贵的选择

- 需要专业的开发技能

- 未来的支持模型

提示和最佳实践

以下是有关如何在步调分层的企业架构中维护自适应集成的一些技巧。

考虑如何使用您正在集成的应用程序。

  • 整合任务是否至关重要？那么Logic Apps将是比Microsoft Flow更好的选择。

  • 需要考虑哪些安全风险？API管理层可以提供基于策略的治理，威胁防护和访问控制。

  • 解决方案有多快变化？这将影响自动化测试，CI / CD管道等方面的投资。

确保您的系统记录图层是可靠的。

  • 您的API是否足够精细且定义明确？请记住，这些将构成其他层中应用程序的可组合单元。

  • 是否强制执行安全性和数据验证？不要依赖消费者;保护您的关键数据靠近源！

限制每个记录系统中的自定义。

  • 如果您自定义SOR，下一次供应商升级会发生什么？

  • 尽可能地使用差分系统层进行自定义，或者至少在每个SOR的API层中进行自定义。

考虑使用规范数据模型来避免与供应商系统紧密耦合。

  • 这通常需要声音信息架构来定义业务数据实体。

  • 信息架构师可以构建独立于软件实现的逻辑模型;投资于此。

松散地耦合层间通信。

  • 垂直依赖性很难维护 - 除非您是整个堆栈的所有者。

  • 尽可能选择发布 - 订阅消息传递模型，以最大化松散耦合和可扩展性。

留出创新空间！

  • 在每一层采用适当的治理级别。避免严格的变更控制政策，实验既必要又安全。

  • 使业务负责人能够创建自己的解决方案（例如，使用Microsoft Flow自动化普通流程）。

  • 鼓励实验！使用Microsoft iPaaS功能实现“以业务速度进行集成”（Jim Harrer，Microsoft）。

本文：https://architect.pub/pace-layered-integration-architecture 讨论：知识星球【首席架构师圈】或者加微信小号【ca_cto】或者加QQ群【792862318】 公众号

【jiagoushipro】
【架构师酒馆】
精彩图文详解架构方法论，架构实践，技术原理，技术趋势。
我们在等你，赶快扫描关注吧。

打开网易新闻 查看精彩图片

【ca_cea】
50000人社区，讨论：企业架构，云计算，大数据，数据科学，物联网，人工智能，安全，全栈开发，DevOps，数字化.

QQ群

【285069459】深度交流企业架构，业务架构，应用架构，数据架构，技术架构，集成架构，安全架构。以及大数据，云计算，物联网，人工智能等各种新兴技术。
加QQ群，有珍贵的报告和干货资料分享。

视频号 【架构师酒馆】
1分钟快速了解架构相关的基本概念，模型，方法，经验。
每天1分钟，架构心中熟。

知识星球 【首席架构师圈】向大咖提问，近距离接触，或者获得私密资料分享。

喜马拉雅 【超级架构师】路上或者车上了解最新黑科技资讯，架构心得。 知识星球 认识更多朋友，职场和技术闲聊。 微博 【架构师酒馆】 哔哩哔哩 【架构师酒馆】

抖音 【cea_cio】架构师酒馆

快手 【cea_cio_cto】架构师酒馆

小红书 【cea_csa_cto】架构师酒馆

网站 CIO(首席信息官) https://cio.ceo 网站CIO,CTO和CDOhttps://cioctocdo.com网站架构师实战分享https://architect.pub网站程序员云开发分享https://pgmr.cloud官网 行天智能科技咨询公司 https://xingtian.ai 网站开发者闲谈https://blog.developer.chat网站首席隐私官内参https://cpo.work网站首席安全官内参https://cso.pub 网站CIO内参https://cio.cool 网站CDO内参https://cdo.fyi 网站CXO内参https://cxo.pub 网站首席架构师社区https://jiagoushi.pro

谢谢大家关注，转发，点赞和点在看。