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

阅读数:1480 2015 年 1 月 28 日

话题:语言 & 开发

通常来说,构建微服务是为了能够将隔离作为一种应对变化的方法。在服务之间共享代码会增加服务之间的相互耦合,跨越隔离界线,导致隔离有效性和变化应对能力减弱,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