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

Question

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

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

下面的图片代表红线定义边界的所有组件，谁负责什么：

• 网关具有适配层
• 适配器层引用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个团队使用。你可以猜到它被删除之前有多快就会变成一团糟：）