六种经常使用的微服务架构设计模式 第二种模式

基于细粒度SOA的分层API

简单地说，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系统。然而，经过细粒度和分层的设计来协调变动多是一个挑战。您可能须要使用必定的技术手段来管理全部不一样微服务之间的契约，或者使用彻底自动化的测试技术来确保变动不会形成破坏。