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

Question

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

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

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

我认为最好将所有这些POJO和其他客户端代码放入库中以供所有服务使用它，它会为我们节省大量的工作编码，但“他们”说我们不应该这样做微服务。

那么，为什么呢？ 我们最终一遍又一遍地复制和粘贴完全相同的代码，我没有看到差异。

Answer 1

主要问题是耦合。 Sam Newman, author of Building Microservices说得好：

  

总的来说，我不喜欢跨服务的代码重用，因为它很容易   成为耦合的源泉。拥有一个用于序列化的共享库   域对象的反序列化是一个经典的例子   代码重用的驱动程序可能是个问题。添加时会发生什么   字段到域实体？你要问所有的客户吗？   升级他们拥有的共享库的版本？如果你这样做，你   松散的独立可部署性，最重要的原则   微服务（恕我直言）。

     

代码重复确实有一些明显的缺点。但我认为那些   缺点比使用共享代码结束的缺点更好   耦合服务。如果使用共享库，请小心监视   他们的使用，如果你不确定他们是否是一个好人   想法，我强烈建议你倾向于代码之间的重复   相反，服务。

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

Answer 2

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

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

总之，你是对的，亚马逊是支持你观点的最强有力的例子。他们完全按照您的Web服务建议，他们可以说是微服务领域最强大的最强大的玩家。

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

Answer 3

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

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

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