每个微服务的客户端与一般客户端谁负责微服务客户端？
我有一个包含10个微服务的微服务架构，每个微服务提供一个客户端。在由微服务团队管理/控制的客户机内部，我们只接收参数并将它们传递给一个通用http调用程序，该调用程序接收endpoint和N个params，然后进行调用。所有微服务都使用http和web api（我猜技术并不重要）。
对于我来说，作为微服务团队提供一个客户是没有意义的，应该是消费者的责任，如果他们想创建一些抽象或者直接调用它是他们的问题，而不是微服务的问题。我认为web API是一个契约。因此，我认为我们应该删除微服务端的所有客户机（将责任传递给消费者），并在消费者端创建一个使用通用调用程序到达endpoint的服务层。
下图表示红线定义边界的所有组件，谁负责什么：
- 网关具有适配器层
- 适配器层引用微服务客户端包
- 微服务客户端包引用通用HTTP调用程序包
另一方面是因为我们可能有N个消费者，他们都在重复客户机的代码。如果微服务提供了一个客户机，我们就有一个独特的/中心的位置来控制它。
这是一个内部产品。
共有1个答案
我在工作中也有类似的设置，有几个微服务(~40)和十几个团队。我被问过几次同样的问题，我的回答是消费者对消费负责。如果API按照设计和预期的方式工作，那么就没有必要让提供团队对任何事情负责。
提供服务的团队（团队a）可以提供客户，如果他们愿意（有疑问，没有保证）。消费团队（团队B）可以使用客户，如果他们愿意（承担包括的所有风险）。唯一的合同应该是API，其他一切都应该是一个团队可能提供的好东西。如果团队a必须提供客户机，那么他们为什么还要提供api呢？
鉴于两个团队都是松散耦合的，并且可能使用不同的技术（或者例如不同的spring framework版本），向另一个团队提供客户机库会带来比解决任何问题都多的问题。例如，在Java+Spring-Boot的世界中，您很快就会遇到依赖问题，尤其是如果您包括来自不同服务提供团队的几个客户机，这些客户机的发展时间不同。
上面的案例是用两个团队描述的，想象一下用10个团队。我们有一个由一个团队提供的“客户机库”，由其他4个团队使用。你可以猜到它有多快变得一团糟，直到它刚刚被删除：）
-
Lazy 微服务客户端 Sometimes you have to load initial data before you can create your @Client(). In this case, you can use ClientProxyFactory, which provides create() method. 有时候在创建@Client()之前你需要加载原始数据。这时，你可
-
我想在一些计算机之间建立点对点连接，这样用户就可以在没有外部服务器的情况下聊天和交换文件。我最初的想法如下： 我在服务器上制作了一个中央服务器插座，所有应用程序都可以连接到该插座。此ServerSocket跟踪已连接的套接字（客户端），并将新连接的客户端的IP和端口提供给所有其他客户端。每个客户端都会创建一个新的ServerSocket，所有客户端都可以连接到它。 换句话说：每个客户端都有一个Se
-
我有两个用Jhipster创建的微服务。(ms1和ms2) ms1有一些DTO类，用作REST API的输入和输出类。 从ms2我需要调用ms1的一些API，因此我需要那些DTO类来输入和输出数据。 MS2中显然没有这些DTO类。 所以我现在有两个选择： 1）将DTO类从ms1复制到ms2 2）将ms1导入为ms2中的maven依赖项 方法2-ms1和ms2都被打包为war文件，而不是jar文件。
-
前面的章节介绍了所有 Redis 的重要功能组件： 数据结构、数据类型、事务、Lua 环境、事件处理、数据库、持久化， 等等， 但是我们还没有对 Redis 服务器本身做任何介绍。 不过， 服务器本身并没有多少需要介绍的新东西， 因为服务器除了维持服务器状态之外， 最重要的就是将前面介绍过的各个功能模块组合起来， 而这些功能模块在前面的章节里已经介绍过了， 所以本章将焦点放在服务器的初始化过程，
-
问题内容： 我正在使用RMI编写密码系统的原型。 我有一个问题，因为当我启动两个客户端时，它们从OneTimePad类的服务器中的一个对象获得了响应。 因此客户端A获取为客户端b保留的密钥，由于特定的算法，这种情况不会发生。 服务器仅向客户端发送E和N变量（例如在RSA中），因此我无法序列化OneTimePad对象并通过网络发送它（因为它将具有所有密钥）。 如何为每个客户端创建OneTimePad
-
我到处都读到微服务中的服务对服务调用应该是异步的。当请求必须通过2个或多个异步服务时，我们如何进行客户端确认？ 这是我的实时场景。我们正在我们的组织中开发电子邮件发送功能。我们计划按以下顺序为此提供4个API服务。 公共API-将电子邮件功能公开给公共 验证API-验证电子邮件和其他字段的真实性 模板获取API-从数据库/CMS中获取电子邮件模板并准备要发送的最终内容 电子邮件发送API-将接收收