简单地说,API主导的连接方法可以被看作是API设计的一种分层方法(至少在本文中是这样)。其中,系统API公开系统的资产数据信息;中间的是流程API,与系统API一起进行编排和组合;顶端的体验API公开来自后端数据源的数据,提供最终用户体验。这种API分层方法与细粒度SOA模式很好地结合在一起,通常,这两者要么可以共存,要么细粒度SOA模式演化成基于细粒度SOA的分层API模式。

API主导的连接方法为细粒度SOA模式提供了一些层次结构,这些层次结构允许对API或微服务进行一致的管理和治理。然而,基于细粒度SOA的分层API模式也存在一些与细粒度SOA 模式类似的深层问题(这很直观):

在细粒度SOA模式执行单个API调用的地方,基于细粒度SOA的分层API模式现在必须通过层执行多个调用。从“网络跳数”的角度来看,这种模式可能是低效的。但是,基于细粒度SOA的分层API模式中,层次结构的存在并不强制跨越网络来调用每个API。直接的跨层调用,而不是通过网络调用是完全有效的;分层的目的是为了增加灵活性,同时以一种很好地分离关注点的方式构建体系架构。

在细粒度SOA模式管理大量服务的地方,使用分层API将会管理来自多个层次的大量细粒度服务。您的管理工具可能不再像以前那样有效,因为它们可能无法可视化复杂的微服务视图。

最终应用程序的数据存储一致性在分层API模式下实际上得到了改善,因为访问数据的服务都是有组织,且集中地查询或修改应用程序的状态。(例如:系统API)

实际上,对于大多数企业来说,基于细粒度SOA的分层API模式是一个很好的模式,但是,就像细粒度SOA模式一样,在实践过程中会出现困难。然而,这种困难通常在大范围使用时才会显现出来。因此,只有在预期或正在经历大规模的使用时,我们才应该准备其他的模式。

问题:

没有一定层次结构的微服务架构是很难进行合理解释的,因为没有明显的方法来对每个微服务的用途进行分类和可视化。

解决方案:

通过创建按用途分组的分层API(系统层、流程及领域模型层,以及体验层),您可以更容易地管理微服务架构的复杂性。

应用:

将微服务架构分为多个层。通常情况下,可以使用标准化,并具有类似用途的一组微服务以类似的方式工作,从而进一步使微服务架构的复杂性合理化。

影响:

1.通过标准化和进一步分解微服务架构,可以提高快速变更的能力。

2.由于更专门化的层次结构,进程间服务调用的数量可能增加。

3.需要对服务监控和可视化工具进行检查,以确定它们是否能够正确地与分层架构一起工作。

目标:

1.快速的敏捷变更。

2.可伸缩性:理论上通过基于细粒度SOA的分层API模式可以提高可伸缩性,但实际上,除非有支持自动化的基础设施,否则可伸缩性往往会降低。

主要特点:

1.为了实现快速变更,可能存在低效的IPC(Inter-Process Communication,进程间通信)。

2.数据一致性和状态管理能力较差,但允许高度重用。重用本身会抵消变更的速度。

3.由于与现存模式的相似性,已有的问题往往同样会出现。

4.基于细粒度SOA的分层API模式在小范围内使用效果很好,在大规模情况下会出现困难。

5.由于采用了结构化的体系架构方法,所以具有很高的内聚性。

6.重点放在服务颗粒度要细,但通常没有考虑其能力。

7.基于细粒度SOA的分层API模式以集成为导向,每个微服务依赖于外部系统。这将会降低变更的速度。

基于细粒度SOA的分层API模式如何与SOA或API等现有系统共存?

基于细粒度SOA的分层API模式往往是与现有IT资产共存的最佳方式。由于分层减少了每个微服务的范围,并约束了其用途,因此该模式能够在不明显降低变更速度的情况下,最好地连接和利用现有IT系统。然而,通过细粒度和分层的设计来协调变更可能是一个挑战。您可能需要使用一定的技术手段来管理所有不同微服务之间的契约,或者使用完全自动化的测试技术来确保变更不会造成破坏。

1.《架构模式 六种常用的微服务架构设计模式》援引自互联网,旨在传递更多网络信息知识,仅代表作者本人观点,与本网站无关,侵删请联系页脚下方联系方式。

2.《架构模式 六种常用的微服务架构设计模式》仅供读者参考,本网站未对该内容进行证实,对其原创性、真实性、完整性、及时性不作任何保证。

3.文章转载时请保留本站内容来源地址,https://www.lu-xu.com/keji/346718.html