distributed-computing – MicroService与Generic Client的客户端谁负责微服务客户?

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

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

下图表示红线定义边界的所有组件,谁负责:

>网关有适配器层
> Adapter Layer引用microService客户端包
> MicroService客户端软件包引用通用HTTP调用程序包
enter image description here

另一方面是因为我们可能有N个消费者,他们都在重复客户端的代码.如果microService提供了一个客户端,我们就有一个独特的/集中的位置来控制它.

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

这是一个内部产品.

我在工作中有类似的设置,有几个微服务(约40个)和十几个团队.我被问过几次同样的问题,我的回答是消费者负责消费.如果API按设计和预期工作,那么提供团队对任何事情都不负任何责任.

提供服务的团队(团队a)可以提供客户,如果他们想要(有疑问,没有保证).消费团队(团队B)可以根据需要使用客户(包括所有风险).
唯一的合同应该是API,其他一切都应该是团队可能提供的好东西.如果团队a必须提供客户,为什么他们提供api呢?

鉴于两个团队松散耦合并且可能使用不同的技术(或者例如不同的弹簧框架版本),向另一个团队提供客户端库证明带来的问题多于解决任何问题.在Java spring-boot世界中,例如您很快就会遇到依赖性问题,特别是如果您包含来自不同服务的多个客户,这些客户会在不同时间内提供不同的变化.

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

如果你想减少你的消费团队所需的工作,因为重新编写客户端是很多工作,你的API可能很复杂和/或你的微服务可能根本不再是微服务.
想象一下在一个宁静的API上使用HATEOAS – 编写一个客户端只需几行代码,即使包含API-Browser,Documentation等等.参见例如spring-rest-docs,hal-browser,swagger和各种其他技术,使阅读/浏览/记录API和实现客户端变得轻而易举.

以上案例由两个团队描述,想象一下10个.我们有一个由一个团队提供的“客户端库”,由其他4个团队使用.你可以猜到在它被删除之前它变得多么快就会变成一团糟:)

相关文章
相关标签/搜索