每个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，其他一切都应该是团队可以提供的好东西。如果 A 团队必须提供客户端，那他们为什么还要提供 api？

鉴于两个团队都是松散耦合的，并且可能使用不同的技术（或者例如不同的 spring 框架版本），向另一个团队提供客户端库被证明带来的问题比解决的问题还要多。例如，在 Java+spring-boot 世界中，您很快就会遇到依赖性问题，特别是如果您包含来自不同服务提供团队的多个客户端，这些客户端在时间上的发展不同。

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

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

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