在松散耦合的微服务架构中，如何跟踪依赖关系？

现代程序中流行的高级体系结构选择是基于REST的微服务系统。这具有几个优点，例如松耦合，易于重用，对可用技术的限制有限，高可伸缩性等。

但是我预见到的这种架构中的问题之一是对应用程序依赖项的可见性不佳。例如，假设我有一个应用程序，该应用程序每天使用一组REST调用。该应用程序还使用第二组REST调用，但每季度仅使用一次。如果我要扫描过去一周的日志，我会看到所有的每日校准数据，但可能看不到季度调用。当需要重构时，每季度调用的中断风险很高。

可以使用什么模式或工具来减少这种风险，并提供对松散耦合体系结构的依赖性的更大可见性？

可以使用哪些模式或工具来降低这种风险

使您的API和业务功能向后兼容。

提供对松散耦合体系结构的依赖关系的更大可见性

健康检查。

我的服务是您每月api功能的客户端。但是只要我的服务运行，我的服务就是您api的客户端。因此，我的服务每隔10分钟醒来一次，或连接到您的每月api，并运行协议以确保我的服务所需的功能仍然可用。

因此，您的日志将向您显示其他服务检查您提供的每个特定服务是否仍然可用的频率，就像它向您显示您提供的每个特定服务被实际使用的频率一样。

至少有两个位置可以找到依赖项：

• 组态。访问外部API需要了解有关每个API的大量信息。访问ID，秘密密钥，端点。所有这些都不能用代码编写，因为此类信息将发生变化。例如，我最近开始将所有微服务迁移到SSL。这意味着，每个依赖于要迁移的服务的服务都应重新配置为指向https://版本而不是http://。我很高兴端点处于配置中而不是被硬编码。

• 接口。您不会直接从代码中访问服务，因为API版本会更改，甚至可能决定切换到其他API。相反，您可以创建一个抽象层，并通过接口使用依赖关系。通过在创建这些接口时遵循通用逻辑，可以在以后搜索依赖项时使生活变得更轻松。

当需要重构时，每季度调用的中断风险很高。

这就是回归测试的目的。

您不能只是看代码，对其进行更改，并相信自己没有任何问题。这在微服务架构中不起作用。这在单片应用程序中也不起作用。编译器可以捕获您在修改代码时会引入的一些错误。在某些语言中，例如Haskell，编译器可以非常强大并捕获大多数错误。但是，主流语言的编译器对您没有多大帮助。如果您没有测试，那就太麻烦了。微服务的存在无关紧要。

REST API是松散指定的，因此在某些时候，移至gRPC，google protobufs或Thrift来定义RPC接口然后对其进行版本化可能会很有用。