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

Question

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

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

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

我认为最好将所有这些POJO和其余客户端代码放到一个库中，以便所有服务使用它，这将为我们节省很多工作代码，但是“他们”说我们不应该对微服务这样做。

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

Answer 1

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

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

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

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

Answer 2

主要问题是耦合。Building Microservices的作者Sam Newman很好地指出：

通常，我不喜欢跨服务的代码重用，因为它很容易成为耦合的源头。具有用于域对象的序列化和反序列化的共享库是一个经典示例，该示例说明了代码重用驱动程序可能会出现的问题。将字段添加到域实体时会发生什么？您是否必须要求所有客户端升级他们拥有的共享库的版本？如果这样做，您将失去独立部署能力，这是微服务（IMHO）的最重要原则。

代码重复确实有一些明显的缺点。但是我认为这些缺点要比使用最终导致耦合服务的共享代码的缺​​点更好。如果使用共享库，请注意监视它们的使用，如果不确定它们是否是个好主意，我强烈建议您改用服务之间的代码复制。

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