【集成架构】速度分层(pace-layered)的集成架构
在自适应企业中实现整合
在现代企业中，很难看到统一整个环境的单一整体应用程序。 虽然仍然可能存在大型主机或其他系统来保存组织的主要数据和事实来源（SoT），但如今大多数环境都具有满足各种业务功能的中型到大型应用程序。 根据企业的规模和复杂程度，这些应用程序可以从少数应用程序到数百种应用程序。
虽然很明显集成成本随着应用程序的数量而增加，但人们也可以争辩说，随着您逐渐远离“一个应用程序完成所有”模型，变更成本会降低。 这一论点背后的原因是，每一次变化，无论多小，通常都会导致整体应用程序的完全重新部署，并且必然会导致整个系统的回归测试成本。
但除了成本和应用数量之外，还有一个额外的维度需要考虑 - 时间。 并非所有应用都是平等的。 任何架构图的问题在于它代表了历史中的单个点 - 它本质上是一个快照。 现实是应用程序随时间而变化; 一些已升级，另一些已修改或扩展，其他可能被删除或替换。 这些应用程序的变化率各不相同，因为有些系统的变化速度比其他系统慢。 这可以在分层视图中表示：
应用程序架构中的层概念并不新鲜;大约十年前，Gartner创建了Pace分层应用战略，以解决业务领导者（他们希望系统灵活并适应业务环境变化）与IT所有者（通常希望系统保持一致）之间的共同脱节。他们运行顺利）。识别这些不同的变化率并相应地对应用程序进行分组有助于应用适当级别的治理，变更控制，测试和DevOps - 使业务能够在需要的地方进行创新，同时保护其关键数据和核心流程。
了解Pace-Layered Architecture
Gartner的Pace-Layered模型由三层组成：
记录系统（SOR） -
这些系统支持组织的核心功能，没有这些功能，企业就无法运行。由于这些通常是整个行业的标准，因此这些功能并非给定品牌或业务所独有（例如，每家银行都需要管理帐户，交易，客户等）。因此，这些系统通常是供应商提供的商业现货（COTS）产品。由于组织的核心能力不会经常发生变化，因此这些系统也不会发生变化 - 变化是递增的，而且速度很慢。
差异化系统 -
虽然核心功能在同一行业中从一个组织到另一个组织的变化不大，但业务流程确实如此。例如，您的银行和我的银行都可以提供贷款，但这两家银行处理贷款的方式可能会有所不同。此层中的应用程序代表使组织独一无二的流程，并且通常不会由供应商提供的记录平台系统开箱即用。业务流程可能不会每天都在变化，但它们确实比核心功能更快地发生变化，例如简化流程和/或整合新技术。
创新系统 -
这一层移动速度最快。这是测试新想法和技术的“沙坑”。这里的实验可能包括特定的概念验证（PoC）应用程序，这些应用程序可以快速开发，然后手动部署和测试。
图片基于Michael Guay（Gartner）的演讲
让我们看一个示例企业，例如银行机构，看看他们的一些应用程序如何映射到速度分层模型。
| LAYER | SYSTEMS / APPLICATIONS | CHARACTERISTICS |
| Systems of Record | ABC银行有几个关键系统，包括核心银行系统，贷款管理系统和文件库。 |
|
| Systems of Differentiation | 自动贷款处理功能由定制的集成解决方案管理，该解决方案集成了多个外部SaaS服务，用于房地产估价，标题搜索，信用评分和在线Web表单提供程序。 |
|
| Systems of Innovation | 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层：
| TECHNOLOGY（技术) | USE WHEN (场景) | CONSIDERATIONS（考虑) |
| Product APIs |
|
+与记录系统紧密集成 - 更改或定制困难或昂贵 - 可能不适合业务数据模型 |
| Web服务/ REST API （IIS托管在本地或 Azure中托管的应用服务计划） |
|
+主机价格低廉 +易于消费 +可以在本地或Azure（IaaS）托管 - 需要开发工作 |
| API Management |
|
+可定制的外观 +开发者门户促进了新的应用创建 - 需要VNet集成 - 没有本地选项 - 如果不使用其他功能，则选择昂贵的选项 |
| Service Fabric |
|
+可以在任何地方托管 +支持容器 - 需要大量开发工作（不提供OOTB软件组件） |
| BizTalk Server |
|
+ BAM跟踪可用 +单一平台集成 - 昂贵的选择 - 需要专业的开发技能 - 未来的支持模型 |
差异化系统层(System of Differentiation Layer)
这些产品能够实现业务逻辑，提供与内部和外部应用程序和服务的连接，并支持跨云和本地应用程序的混合连接：
| TECHNOLOGY（技术） | USE WHEN（场景) | CONSIDERATIONS(考虑) |
| Logic Apps |
|
+快速发展 +超过200个内置连接器！ - 没有VNet支持（直到ISE可用） - 没有本地选项（尚未） |
| Azure Functions |
|
+良好的CI / CD支持 + VNet支持 +可以在本地运行 - 没有Logic Apps那么多的连接器 |
| Web/Mobile Apps |
|
+良好的CI / CD支持 +众多部署选项 +支持Azure Relay / VNet集成 - 对于长时间运行的过程本身并不理想 - 考虑混合应用程序的安全层 |
| Service Fabric |
|
+可以在任何地方托管 +支持容器 - 需要大量的开发工作 - 基础设施投资（仅限本地） |
| BizTalk Server |
|
+单一平台进行整合 +可以在本地或Azure（IaaS）托管 - 昂贵的选择 - 需要专业的开发技能 - 未来的支持模型 |
创新系统层
在这里，我们需要能够将技术范围扩展到人工智能，预测分析和业务洞察领域，同时实现快速（甚至临时）开发。 这里有很多可能性，因为与使用它的方式相比，它更少涉及您使用的技术。 但这些产品都非常适合创新的解决方案：
| TECHNOLOGY（技术) | USE WHEN(场景) | CONSIDERATIONS(考虑) |
| Microsoft Flow |
|
+快速发展 +可以轻松迁移到Logic Apps *需要Office365 |
| Power Apps |
|
+与Flow / SharePoint /轻松集成 +多平台 *需要Office365 |
| Power BI |
|
*依赖于对数据源的访问 |
| Cognitive Services |
|
+提供多种服务/ API（Vision，Knowledge， *需要编程技能 |
| Machine Learning |
|
*需要数据科学技能 |
| Bots |
|
*需要编程技能 *机器人需要经过良好的训练才能按预期运行 |
消息总线
如果您主要集成本地系统，BizTalk Server的核心是一个功能强大的消息传递引擎，它不仅可以支持全部的消息传递模式，还可以提供几个开箱即用的连接器以实现连接。 强大的业务流程自动化功能 这就是它在很多层中的特征。 然而，当在云中集成时，Azure Service Bus为企业消息传递，大数据流，事件处理和混合连接提供了许多产品：
| TECHNOLOGY（技术) | USE WHEN (场景) | CONSIDERATIONS(考虑） |
| Event Grid |
|
+弹性（重试最多24小时） +推 - 推模型 +易于集成 *小消息大小 |
| Event Hubs |
|
*至少需要一个下游处理器 - 没有本地选项 |
| Relays |
|
+可以使用混合连接或WCF中继 |
| On-Prem Data Gateway |
|
+如果使用Logic Apps，则可以替代VNet - 仅少数Logic App连接器支持 |
| Service Bus Queues |
|
+极具弹性和功能齐全 - 没有本地选项 |
| Service Bus Topics |
|
+极具弹性和功能齐全 - 没有本地选项 |
| BizTalk Server |
|
+单一平台进行整合 - 昂贵的选择 - 需要专业的开发技能 - 未来的支持模型 |
提示和最佳实践
以下是有关如何在步调分层的企业架构中维护自适应集成的一些技巧。
考虑如何使用您正在集成的应用程序。
- 整合任务是否至关重要？那么Logic Apps将是比Microsoft Flow更好的选择。
- 需要考虑哪些安全风险？ API管理层可以提供基于策略的治理，威胁防护和访问控制。
- 解决方案有多快变化？这将影响自动化测试，CI / CD管道等方面的投资。
确保您的系统记录图层是可靠的。
您的API是否足够精细且定义明确？请记住，这些将构成其他层中应用程序的可组合单元。
是否强制执行安全性和数据验证？不要依赖消费者;保护您的关键数据靠近源！
限制每个记录系统中的自定义。
如果您自定义SOR，下一次供应商升级会发生什么？
尽可能地使用差分系统层进行自定义，或者至少在每个SOR的API层中进行自定义。
考虑使用规范数据模型来避免与供应商系统紧密耦合。
这通常需要声音信息架构来定义业务数据实体。
信息架构师可以构建独立于软件实现的逻辑模型;投资于此。
松散地耦合层间通信。
垂直依赖性很难维护 - 除非您是整个堆栈的所有者。
尽可能选择发布 - 订阅消息传递模型，以最大化松散耦合和可扩展性。
留出创新空间！
在每一层采用适当的治理级别。避免严格的变更控制政策，实验既必要又安全。
使业务负责人能够创建自己的解决方案（例如，使用Microsoft Flow自动化普通流程）。
鼓励实验！使用Microsoft iPaaS功能实现“以业务速度进行集成”（Jim Harrer，Microsoft）。
原文： https://platform.deloitte.com.au/articles/a-pace-layered-integration-architecture
- 1753 次浏览