每个微服务的客户端与通用客户端 |谁负责微服务客户端？
Client per MicroService vs Generic Client | Who is responsible for microservice client?
我有一个包含 10 个微服务的微服务架构，每个微服务都提供一个客户端。在微服务团队 managed/controlled 的那个客户端内部，我们只接收参数并将它们传递给一个通用的 http 调用程序，该调用程序接收端点和 N 参数，然后进行调用。
所有微服务都使用http和webapi（我猜技术无所谓）。
对我来说微服务团队提供客户端是没有意义的，应该是消费者的责任，如果他们想创建一些抽象或直接调用它是他们的问题，而不是微服务的问题。我看到网络 API 的方式是作为合同。所以我认为我们应该删除微服务端的所有客户端（将责任传递给消费者），并在消费者端创建一个使用通用调用程序到达端点的服务层。
下图表示红线定义边界的所有组件，谁负责什么：
- 网关有适配器层
- 适配器层引用微服务客户端包
- 微服务客户端包引用通用 HTTP 调用程序包
另一方面是因为我们可能有 N 个消费者，他们都在重复客户端的代码。如果微服务提供客户端，我们有一个 unique/central 地方来控制它。
哪种做法是正确的？客户端是微服务的职责还是消费者的职责？
这是一个内部产品。
我在工作中有类似的设置，有几个微服务 (~40) 和十几个团队。我多次被问到同样的问题，我的回答是消费者负责消费。如果 API 按设计和预期工作，那么让提供团队负责任何事情是没有意义的。
提供服务的团队（a 团队），可以 提供客户，如果他们需要（有疑问，无保证）。如果 他们 需要，消费团队（B 团队）可以 使用客户端（承担所有风险）。
唯一的合同应该是 API，其他一切都应该是球队可以提供的好东西。如果团队 a 有 提供客户，那么他们为什么要提供 api？
鉴于两个团队松散耦合并且可能使用不同的技术（或者例如不同的 spring 框架版本），向另一个团队提供客户端库被证明带来的问题多于解决任何问题。在 Java+spring-boot 世界中，例如您很快就会遇到依赖性问题，尤其是当您包括来自不同服务提供团队的多个客户时，这些客户会及时发展。
更糟糕的是：如果 A 队的客户端库导致 B 队的系统不稳定并引入错误怎么办？现在谁负责解决这个问题？
如果您想减少消费团队所需的工作，因为重新编码客户端的工作量太大，您的 API 可能会太复杂 and/or 您的微服务可能不再是微服务根本。
想象一下，在 restful API 上使用 HATEOAS——为此编写客户端只需几行代码，即使包含 API-浏览器、文档和诸如此类的东西。参见例如spring-rest-docs、hal-browser、swagger 和各种其他技术，使 reading/browsing/documenting 成为 API 并轻松实现客户端。
以上案例描述了两个团队，想象一下有 10 个。我们有一个 "client library" 由一个团队提供，由其他 4 个团队使用。你可以猜到它变得一团糟的速度有多快，直到它被删除:)
我有一个包含 10 个微服务的微服务架构，每个微服务都提供一个客户端。在微服务团队 managed/controlled 的那个客户端内部，我们只接收参数并将它们传递给一个通用的 http 调用程序，该调用程序接收端点和 N 参数，然后进行调用。 所有微服务都使用http和webapi（我猜技术无所谓）。
对我来说微服务团队提供客户端是没有意义的，应该是消费者的责任，如果他们想创建一些抽象或直接调用它是他们的问题，而不是微服务的问题。我看到网络 API 的方式是作为合同。所以我认为我们应该删除微服务端的所有客户端（将责任传递给消费者），并在消费者端创建一个使用通用调用程序到达端点的服务层。
下图表示红线定义边界的所有组件，谁负责什么：
- 网关有适配器层
- 适配器层引用微服务客户端包
- 微服务客户端包引用通用 HTTP 调用程序包
另一方面是因为我们可能有 N 个消费者，他们都在重复客户端的代码。如果微服务提供客户端，我们有一个 unique/central 地方来控制它。
哪种做法是正确的？客户端是微服务的职责还是消费者的职责？
这是一个内部产品。
我在工作中有类似的设置，有几个微服务 (~40) 和十几个团队。我多次被问到同样的问题，我的回答是消费者负责消费。如果 API 按设计和预期工作，那么让提供团队负责任何事情是没有意义的。
提供服务的团队（a 团队），可以 提供客户，如果他们需要（有疑问，无保证）。如果 他们 需要，消费团队（B 团队）可以 使用客户端（承担所有风险）。 唯一的合同应该是 API，其他一切都应该是球队可以提供的好东西。如果团队 a 有 提供客户，那么他们为什么要提供 api？
鉴于两个团队松散耦合并且可能使用不同的技术（或者例如不同的 spring 框架版本），向另一个团队提供客户端库被证明带来的问题多于解决任何问题。在 Java+spring-boot 世界中，例如您很快就会遇到依赖性问题，尤其是当您包括来自不同服务提供团队的多个客户时，这些客户会及时发展。
更糟糕的是：如果 A 队的客户端库导致 B 队的系统不稳定并引入错误怎么办？现在谁负责解决这个问题？
如果您想减少消费团队所需的工作，因为重新编码客户端的工作量太大，您的 API 可能会太复杂 and/or 您的微服务可能不再是微服务根本。 想象一下，在 restful API 上使用 HATEOAS——为此编写客户端只需几行代码，即使包含 API-浏览器、文档和诸如此类的东西。参见例如spring-rest-docs、hal-browser、swagger 和各种其他技术，使 reading/browsing/documenting 成为 API 并轻松实现客户端。
以上案例描述了两个团队，想象一下有 10 个。我们有一个 "client library" 由一个团队提供，由其他 4 个团队使用。你可以猜到它变得一团糟的速度有多快，直到它被删除:)