简单地说，以API为主导的连接方法可以看作是API设计的分层方法（至少在本文中是这样）。其中，系统API公开了系统的资产数据信息；中间是进程API，与系统API排列组合；顶级体验API公开来自后端数据源的数据，以提供最终用户体验。这种API分层方法适用于细粒度SOA模式，通常，两者可以共存，或者细粒度SOA模式演化为细粒度的基于SOA的分层API模式。API主导的连接方法为细粒度的SOA模式提供了一些层次结构，允许对API或微服务进行一致的管理和治理。但是，基于细粒度SOA的分层API模式也存在一些类似于细粒度SOA模式的深层问题（这是直观的）：在细粒度SOA模式执行单个API调用的地方，分层API模式基于细粒度SOA现在必须通过层执行多个调用。从“网络跳数”的角度来看，此模型可能效率低下。然而，在基于细粒度SOA的分层API模式中，分层结构的存在并不强制每一个API都被跨网络调用。跨层直接调用，而不是通过网络，是完全有效的；分层的目的是增加灵活性，同时以一种提供良好的关注点分离的方式构建体系结构。在细粒度SOA模式管理大量服务的地方，使用分层API将从多个层管理大量细粒度服务。您的管理工具可能不像以前那样有效，因为它们可能无法可视化复杂的微服务视图。最终应用程序的数据存储一致性在分层API模型下实际上得到了提高，因为访问数据的服务被组织起来并集中查询或修改应用程序的状态。（例子：系统API）事实上，对于大多数企业来说，基于细粒度SOA的分层API模式是一个很好的模式，但是，和细粒度SOA模式一样，在实践中也会出现困难。然而，这种困难通常只有在大规模使用时才会显现出来。因此，只有在预期或正在经历大规模使用时，我们才应该为其他模式做准备。问题：没有层次结构的微服务架构很难合理化，因为没有明显的方法来分类和可视化每个微服务的目的。解决方案：通过创建按用途分组的分层API（系统层、流程和领域模型层以及体验层），您可以更轻松地管理微服务架构的复杂性。应用：将微服务架构进行分层。通常，一组具有类似目的的微服务可以标准化并以类似的方式工作，进一步合理化微服务架构的复杂性。影响：1.通过对微服务架构进行标准化和进一步分解，可以提高快速变化的能力。2.由于更专业的层次结构，进程间服务调用的数量可能会增加。3.需要检查服务监控和可视化工具，看它们是否与分层架构一起正常工作。目标：1.快速敏捷的变化。2.可扩展性：理论上，可扩展性可以通过细粒度的基于SOA的分层API模式来提高，但在实践中，除非有支持自动化的基础设施，否则可扩展性往往会降低。主要特点：1.为了实现快速变化，可能存在效率低下的IPC（Inter-ProcessCommunication，进程间通信）。2、数据一致性和状态管理能力较差，但允许高度复用。重用本身会抵消变化的速度。3.由于与现有模型的相似性，存在的问题往往以相同的方式出现。4、基于细粒度SOA的分层API模式在小范围内效果很好，但在大规模情况下会很困难。5.结构化架构方法带来的高内聚性。6.关注的是更细的服务粒度，往往忽略了它的能力。7、基于细粒度SOA的分层API模式是面向集成的，每个微服务都依赖于外部系统。这将减慢变化的速度。基于细粒度SOA的分层API模式如何与SOA或API等现有系统共存？基于细粒度SOA的分层API模式通常是与现有IT资产共存的最佳方式。由于分层缩小了每个微服务的范围并限制了它的使用，这种模式可以实现现有IT系统的最佳连接和利用，而不会显着降低变化速度。然而，通过细粒度和分层设计协调变化可能是一个挑战。您可能需要使用一些技术手段来管理所有不同微服务之间的契约，或者使用完全自动化的测试技术来确保更改不会中断。
