简单地说，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系统 。然而，通过细粒度和分层的设计来协调变更可能是一个挑战 。您可能需要使用一定的技术手段来管理所有不同微服务之间的契约，或者使用完全自动化的测试技术来确保变更不会造成破坏 。
【六种常用的微服务架构设计模式】
推荐阅读
- SEM如何控制转化成本
- Java常量、变量、数据类型详解
- 一个男人经常换微信头像说明什么 经常换微信头像的人是什么性格
- 注意：喝茶虽养生 喝错会伤肾
- 健身|了解几个减肥基础常识，搞不懂，很难真正瘦下来！
- 老北京麻酱烧饼家常做法，浓浓的芝麻香，几天不吃还真想这口儿
- 家庭常用药必备清单 不舒服不用着急去医院
- 品茶六个常用词语的介绍
- 乐播投屏常见使用问题汇总
- 来看看常喝酸奶对你身体的影响