转载

不要在微服务之间共享代码

通常来说，构建微服务是为了能够将隔离作为一种应对变化的方法。在服务之间共享代码会增加服务之间的相互耦合，跨越隔离界线，导致隔离有效性和变化应对能力减弱， David Dawson 发表了一系列博文对不要重复劳动（DRY）原则提出质疑。

Simplicity的CEO David认为构建微服务一些常见的原因如下；

独立可扩展
服务隔离
单独的服务生命周期

David声称这些原因都是关于应对环境或代码库中的变化的，同时他也相信变化通常也是切分服务的主要原则。

David发现在开发人员当中跨越微服务共享代码的理由基本上很少，主要包括：

利用现有的技术功能，例如通过共享的库。
共享数据模式，如通过使用相同的类。
共享数据源，如不同的服务使用相同的数据存储。

David强调所有的代码共享都会让你的服务通过共享的代码附着在一起。创建一个单一可信来源，在一个服务内部坚持DRY原则会在具有单一责任的服务内部产生内在耦合但不会出现问题。相反，如果跨越这个界限，即使有些东西表面看来是相同的，它们是也处于不同的上下文之中而且一定是有区别的，由不同的代码实现并且使用不同的数据存储。David极力劝阻无论这些代码看起来有多么相似，我们也要抵住诱惑，不能将这些代码附在一起，因为那意味着耦合跨越了边界和不同的上下文，这将直接导致大泥球出现。

David认为DRY原则已经成为了可与设计模式比肩的软件开发的基石之一，但是它也被曲解成 不要重复任何事（ Don’t Repeat Anything ）和 拷贝粘贴是不好的（ Copy and Paste is bad ）。追溯其来源，在《The Pragmatic Programmer》一书中，DRY的描述如下：

每条知识在一个系统里一定都有一个单一的无歧义的权威表示。

David的批注认为这里的关键术语是知识的概念，而不是拷贝和粘贴。尽管这个原则在某些特定的领域非常实用，他认为这一术语已经超出了其上下文，被应用的过于广泛。当应用于微服务体系架构之上更高的层级时，如共享模式，我们只会剩下维护体系架构的成本而不会有任何收益，他们已经被DRY所毁。

查看英文原文： Don’t Share Code Between Microservices

正文到此结束