通常来说，构建微服务是为了能够将隔离作为一种应对变化的方法。在服务之间共享代码会增加服务之间的相互耦合，跨越隔离界线，导致隔离有效性和变化应对能力减弱， 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 所毁。
暂无签名
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论