layered的 「集成架构」速度分层的(pace-layered)集成架构

大家好，关于layered的很多朋友都还不太明白，今天小编就来为大家分享关于「集成架构」速度分层的(pace-layered)集成架构的知识，希望对各位有所帮助！

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

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

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

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

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

6、记录系统（SOR）-

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

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

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

10、图片基于MichaelGuay（Gartner）的演讲

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

37、鼓励实验！使用MicrosoftiPaaS功能实现“以业务速度进行集成”（JimHarrer，Microsoft）。

好了，文章到这里就结束啦，如果本次分享的layered的和「集成架构」速度分层的(pace-layered)集成架构问题对您有所帮助，还望关注下本站哦！