所以我读了micorsevrice ae bad中的共享库，因为它们不允许服务的完全自治发展。
示例：
Service A and Service B both talk to Service C to view some data.
我可以在每个服务中创建域对象，并从服务C复制代码。
OR
我可以在服务之间共享一个共享库。
现在，我知道是否需要更改共享库，而不必再次部署这3个服务。
但是
如果我重复执行代码，但发现原始代码中有错误，则在复制代码时仍需要部署所有3个服务，因此仍然会产生连锁反应。
为什么在我的示例中分享如此糟糕？
答案 0 :(得分：1)
您几乎总是会在不同服务之间拥有一些共同的组成部分。
在您的示例中，听起来好像共享库只是Service A和Service B与Service C进行通信的常用方式。这与具有用于处理通信协议的通用代码非常相似
去耦服务是令人希望的，其原因有很多，应该竭尽所能。但是，如果这不切实际，则应由开发人员来决定采取的措施。正如其他人指出的那样，您可能需要考虑重新设计系统，以便删除这些常见的依赖项。但是，由于我不了解上下文，其他人已经对此进行了很好的解释-我将把它放在那儿，集中讨论其余的问题
如果您需要在服务之间共享代码，并且服务是用相同的语言编写的，那么我将使用一个库来实现。是的，您必须将库部署到所有服务器以进行任何更改。但是至少这些改变只会在一个地方发生。
就我个人而言，将其分解为不同的库根本没有任何好处。令人困惑-您必须记住自己的不同实现。如果两者都中断，则需要进行两个修复。如果发生更改，则可以在两个地方进行更改。
两个实现到底如何脱钩？他们都在做相同的事情，都取决于相同的数据，并且都可能由同一个人和对该问题有相同的理解。如果其中一个存在错误，那么另一个中可能也会存在类似的错误。
答案 1 :(得分：0)
如果将服务复制到两个地方，而不是从仍在共享的同一来源直接使用该服务。正如您正确指出的那样，那仍然不允许自治。
您应该重新设计所有3个服务，使其完全不具有 conceptual 依赖性。我怀疑存在这种依赖性，因为您有A和B需要C拥有的一些“数据”。取而代之的是，尝试进行另一种划分，即服务提供功能（而非数据），而服务本身无需其他服务即可实现。
这当然并不总是那么容易，但这就是此“不共享业务逻辑”策略的背后。
答案 2 :(得分：0)
在您的示例中，共享是不好的，因为您正在重新耦合您已解耦的内容。
Service A and Service B both talk to Service C to view some data.
如果服务A和服务B使用共享库，则团队B的更改也会影响团队A的服务。也许A团队不了解这些更改，或者这些更改仅适合服务B。
答案 3 :(得分：0)
微服务的主要目标是创建松散耦合的，可伸缩的服务，这些服务可以独立于其他服务进行更改。共享库或域对象的创建会在项目之间建立耦合。
微服务开发人员需要接受这样一个现实： 微服务之间的代码重复
首先开始设计单核细胞，然后将您的代码分成Bounded上下文。
Bounded Context定义了可能的最大服务的边界：服务内部没有任何冲突的模型，因此Bounded Context是解决方案空间中的投影，用于定义实现域的系统中的边界。
经验法则一个有界上下文=一个具有单一职责的微服务。
始终牢记，微服务的重点不应放在规模上，而应放在 业务功能。
如果您需要在服务之间共享域，那么您已经创建了Nano服务而不是微服务，并且Nano服务是反模式。