distributed-computing - 每个微服务的客户端 vs 通用客户端 |谁负责微服务客户端？

Question

我有一个包含 10 个微服务的微服务架构，每个微服务都提供一个客户端。在由微服务团队管理/控制的客户端内部，我们只接收参数并将它们传递给通用 http 调用程序，该调用程序接收端点和 N 参数，然后进行调用。
所有微服务都使用 http 和 web api(我猜技术无关紧要)。

对我来说作为微服务团队提供客户端没有意义，应该是消费者的责任，如果他们想创建一些抽象或直接调用它是他们的问题，而不是微服务问题。我将 Web API 视为一种契约。所以我认为我们应该删除微服务端的所有客户端(将责任传递给消费者)，并在消费者端创建一个使用通用调用程序到达端点的服务层。

下图代表所有组件，其中 红线定义 边界，谁负责什么 :

网关有适配器层

适配器层引用微服务客户端包

微服务客户端包引用Generic HTTP invoker包

另一方面是因为我们可能有 N 个消费者，而且他们都在重复客户端的代码。如果微服务提供了一个客户端，我们就有一个独特的/中心位置来控制它。

哪种方法是正确的？客户端是微服务的责任还是消费者的责任？

这是内部产品。

Answer 1

我在工作中也有类似的设置，有几个微服务(约 40 个)和十几个团队。我被问了好几次同样的问题，我的回答是 消费者负责消费 .如果 API 按设计和预期工作，则无需让提供团队负责任何事情。

提供服务的团队(a 团队)， 5 月 提供客户，如果他们愿意(有疑问，没有保证)。消费队(B队) 5 月 如果 使用客户端他们想要(承担所有风险)。
唯一的契约(Contract)应该是 API，其他一切都应该是团队可以提供的好东西。如果团队一个 有 提供一个客户，他们为什么要提供一个api呢？

鉴于两个团队松散耦合并且可能使用不同的技术(或例如不同的 spring 框架版本)，向另一个团队提供客户端库被证明带来的问题比解决任何问题都多。在 Java+spring-boot 世界中，例如你很快就会陷入依赖问题，特别是如果你包括来自不同服务提供团队的几个客户，这些客户随着时间的推移而不同。

更糟糕的是:如果 A 团队的客户端库使 B 团队的系统不稳定并引入错误怎么办？现在谁负责解决这个问题？

如果您想减少消费团队所需的工作，因为重新编码客户端需要大量工作，那么您的 API 可能会很复杂和/或您的微服务可能根本不再是微服务。
想象一下在一个安静的 API 上使用 HATEOAS - 为它编写一个客户端只是几行代码，即使包含 API 浏览器、文档和诸如此类的东西。见例如spring-rest-docs、hal-browser、swagger 和各种其他技术，使阅读/浏览/记录 API 和实现客户端变得轻而易举。

上面的案例是用两个团队描述的，想象一下有 10 个。我们有一个由一个团队提供的“客户端库”，被其他 4 个团队使用。你可以猜到它在被删除之前变成一团糟的速度有多快:)