本文介绍了在微服务架构中,为什么他们说共享REST客户端库不好?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们有15个使用Java Spring构建的服务,它们使用REST相互交谈.

We have 15 services build with Java Spring, they talk each other using REST .

每次将新服务添加到池中时,我们都会从头开始创建所有代码,包括将与其他服务对话的其余客户端代码以及用于映射所请求资源的POJO类.

Each time we add a new service to the pool we create from scratch all the code, including rest client code that will talk to other Services and the POJO classes used to map the resource(s) being requested.

我们最终将其他服务的源代码复制并粘贴到新服务中.

We end up copy and pasting from the source code of other services into the new service.

我认为最好将所有这些POJO和其余客户端代码放入一个库中,以供所有服务使用,这将为我们节省很多工作代码,但是他们"说我们不应该这样做微服务.

I think it would be better to put all these POJO's and rest client code into a library for all the services to consume it, it would save us a lot of work coding, but "they" say we should not do that with microservices.

那为什么呢?我们最终复制并一遍又一遍地粘贴完全相同的代码,我看不出有什么区别.

So, why is that?We end up copy and pasting the exactly same code over and over again, I don't see the difference.

推荐答案

主要问题是耦合. Sam Newman,《建筑微服务》的作者很好地说明了这一点:

The main issue is coupling. Sam Newman, author of Building Microservices puts it well:

代码重复确实有一些明显的缺点.但是我认为那些 缺点要比使用共享代码结尾的缺点要好 耦合服务.如果使用共享库,请注意监视 它们的用法,如果您不确定它们是否是一种好 想法,我强烈建议您倾向于在 服务.

Code duplication does have some obvious downsides. But I think those downsides are better than the downsides of using shared code that ends up coupling services. If using shared libraries, be careful to monitor their use, and if you are unsure on whether or not they are a good idea, I'd strongly suggest you lean towards code duplication between services instead.

https://samnewman.io /blog/2015/06/22/answering-questions-from-devoxx-on-microservices/

这篇关于在微服务架构中,为什么他们说共享REST客户端库不好?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

10-12 22:33