Java 在微服务体系结构中，为什么他们说共享REST客户端库不好？

我们有15个使用JavaSpring构建的服务，它们使用REST相互通信

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

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

我认为最好将所有这些POJO和rest客户机代码放在一个库中，以便所有服务使用它，这将为我们节省大量的编码工作，但“他们”说我们不应该用微服务这样做

那为什么呢？

---

我们一次又一次地复制和粘贴完全相同的代码，我看不出有什么区别。

主要问题是耦合。说得好：

一般来说，我不喜欢跨服务重用代码，因为它可以很容易地实现 成为耦合源。拥有用于序列化的共享库 域对象的反序列化是其中的一个经典示例 代码重用的驱动程序可能是一个问题。当您添加一个 域实体的字段？你必须要求你所有的客户 是否升级他们拥有的共享库的版本？如果你这样做了，你就会 松散独立的可展开性，这是 微服务（IMHO）

代码复制确实有一些明显的缺点。但我认为 使用共享代码的缺点要比使用共享代码的缺点好 上耦合服务。如果使用共享库，请小心监视 他们的用途，如果你不确定他们是否是一个好的 我强烈建议您倾向于在 而是服务

我会说“他们”错了，而你是对的。复制和粘贴客户端代码时存在几个问题：

• 如果客户机代码中存在错误，则必须在15个位置修复该错误，而不是仅修复1个
• 这会减慢速度。您现在必须测试和维护同一代码的多个副本
• 创建客户端库并通过标准依赖关系管理器（如maven）分发它们是常见的做法。亚马逊几乎和其他所有人都是这样做的

总之，你是对的，亚马逊是支持你观点的最有力的例子。他们完全按照您对其web服务的建议行事，而且可以说他们是微服务领域中最大、最强大的参与者

---

另外，在另一个答案中，也要解决紧耦合的问题。好的api是向后兼容的，因此对api的更改不需要升级所有客户端，即使它们使用相同的客户端库。

我同意关于耦合的说法。我被迫在重用场景中使用一组特定的Maven依赖项，不允许任何人更新它们。结果是，创建新服务变得更加困难，因为框架和文档都过时了

另一方面，代码重用可以节省大量的时间和金钱，特别是在服务中使用的样板代码，如果它构造良好并且有适当的测试

---

我认为这里有一个中间地带，涉及版本控制和一定量的日常维护。

因为从概念上讲，每个微服务代表一个域，域之间共享类型通常不是好的设计。如果在一个域中类型发生更改怎么办？这不应该影响其他人，这叫做服务版本控制。一方面，有人可能会问

如果某个域中的类型发生了变化，该怎么办

，但服务需要相互交谈或与客户交谈。因此，我认为拥有一个通用的域客户机/库是可以的，但请记住它的版本和互操作性。您不应该复制代码。这个问题不是基于意见，而是可能与您的评论重复。我完全同意您的意见。我还创建了许多客户端库，以便在项目中的微服务之间共享。最重要的是向后兼容，当你升级新版本时，它只影响一些服务，而不是所有服务，其他服务将调用旧的api。我们在创建lib以在服务之间共享方面有一些约定。例如：没有数据库实体，没有存储库……使用抽象类，让服务以自己的方式实现它。我也同意你的看法。耦合将存在，无论它是否明确。如果你对你的API引入了一个不向后兼容的变更，它无论如何都会破坏它的客户端。但我相信客户端库应该只是一种方便，而不是使用API的唯一方式。关键点是“使用共享代码最终耦合服务的缺点”。若您的共享代码并没有耦合服务，那个么将其保存在共享库中似乎是可以的。