六种常用的微服务架构设计模式(建议收藏)
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了六种常用的微服务架构设计模式(建议收藏)相关的知识,希望对你有一定的参考价值。
参考技术A
简单地说,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系统。然而,通过细粒度和分层的设计来协调变更可能是一个挑战。您可能需要使用一定的技术手段来管理所有不同微服务之间的契约,或者使用完全自动化的测试技术来确保变更不会造成破坏。
六种微服务架构的设计模式
聚合器微服务设计模式
这是一种最常用也最简单的设计模式,如下图所示:
聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面,将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务,对检索到的数据增加业务逻辑后进一步发布成一个新的微服务,这符合DRY原则。另外,每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务,那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。
代理微服务设计模式
这是聚合器模式的一个变种,如下图所示:
在这种情况下,客户端并不聚合数据,但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求,也可以进行数据转换工作。
链式微服务设计模式
这种模式在接收到请求后会产生一个经过合并的响应,如下图所示:
在这种情况下,服务A接收到请求后会与服务B进行通信,类似地,服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前,客户端会一直阻塞。因此,服务调用链不宜过长,以免客户端长时间等待。
分支微服务设计模式
这种模式是聚合器模式的扩展,允许同时调用两个微服务链,如下图所示:
数据共享微服务设计模式
自治是微服务的设计原则之一,就是说微服务是全栈式服务。但在重构现有的“单体应用(monolithic application)”时,SQL数据库反规范化可能会导致数据重复和不一致。因此,在单体应用到微服务架构的过渡阶段,可以使用这种设计模式,如下图所示:
在这种情况下,部分微服务可能会共享缓存和数据库存储。不过,这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言,这是一种反模式。
异步消息传递微服务设计模式
虽然REST设计模式非常流行,但它是同步的,会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应,如下图所示:
以上是关于六种常用的微服务架构设计模式(建议收藏)的主要内容,如果未能解决你的问题,请参考以下文章
生产级基于SpringCloud微服务架构性能优化实战,建议收藏