每个MicroService客户端与通用客户端|谁负责微服务客户端？

Question

我有一个microService体系结构和10个microServices，每个都提供一个客户端。在由microService团队管理/控制的客户端内部，我们只收到参数并将它们传递给一个通用的http调用者，该调用者接收端点和N个参数，然后进行调用。 所有microService都使用http和web api（我想技术并不重要）。

对于我来说microService团队提供一个客户端是没有意义的，应该是消费者的责任，如果他们想要创建一些抽象或直接调用它们是他们的问题，而不是微服务问题。我看到一个web API的方式就像一个合同。所以我认为我们应该在microService端删除所有客户端（将责任传递给消费者），并在消费者端创建一个使用泛型调用者到达端点的服务层。

图像下面表示其中红线定义界限，谁负责什么所有组件：

• 网关有适配层
• 适配层引用了微服务客户端软件包
• MicroService客户端包引用通用HTTP调用者包

另一方面是因为我们可能有N个消费者，他们都重复客户端的代码。如果microService提供客户端，我们有一个独特的/中心的地方来控制它。

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

这是一个内部的产品。

Answer 1

我在工作中有一个类似的设置，有几个微服务（〜40）和十几个团队。我被问了几次相同的问题，我的回答是消费者负责消费。如果API按照设计和预期工作，那么让提供团队负责任何事情都没有意义。

提供服务的团队（团队a），可能提供客户，如果他们想（有疑问，没有保修）。消费队（B队）可以使用，如果他们希望客户端（采取一切包括风险）。 唯一的合同应该是API，其他的一切都应该是一个团队可能提供的好东西。如果团队有提供客户端，为什么他们提供一个API？

鉴于两队都松散耦合，并可以使用不同的技术（例如，或不同的弹簧框架的版本），提供客户端库，其他球队证明带来比任何解决更多的问题。在Java + spring-boot世界中，例如您会非常快地陷入依赖性问题，特别是如果您包含来自不同服务提供团队的几个客户，这些客户的时间演变程度各不相同。

而且更糟糕的是什么，如果A队的客户端库，使B队的系统不稳定，并介绍了错误？现在谁负责解决这个问题？

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

以上情况用两个团队来描述，想象一下10.我们有一个由一个团队提供的“客户端库”，由另外4个团队使用。你可以猜测它有多快，它变成了一个完整的混乱，直到它被删除:)