六种常用的微服务架构设计模式
问题：
没有一定层次结构的微服务架构是很难进行合理解释的，因为没有明显的方法来对每个微服务的用途进行分类和可视化。
解决方案：
通过创建按用途分组的分层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系统。然而，通过细粒度和分层的设计来协调变更可能是一个挑战。您可能需要使用一定的技术手段来管理所有不同微服务之间的契约，或者使用完全自动化的测试技术来确保变更不会造成破坏。长按二维码，关注我们
新睿云，让云服务触手可及
云主机｜云存储｜云数据库｜云网络
点击“阅读原文”参与活动