我在中等规模的组织工作。从大约一年开始，我们开始重构我们的旧解决方案，创建微服务。对于后端部分Go被选中，前面我们有Node.js
现在假设我们有一些html表单，用户放置一些数据。在它的前端部分进行自己的验证并调用三个不同端点（三个不同的微服务）之一。
由前端数据验证然后由三个微服务分别验证。复制/粘贴相同的规则。还有很多这样的例子。
我建议创建一些验证器服务，它将在一个地方执行验证，我得到的答案就像'在微服务架构中我们无法创建强大的依赖关系'
我的问题是，“强依赖性”是否真的如此糟糕以至于我们需要进行愚蠢的复制/粘贴，而且还要为复制/粘贴代码创建单元测试（我们也复制/粘贴它们并更改名称）。如果“强依赖性”如此糟糕，你可以给出一些例子。
答案 0 :(得分：4)
对于您的第一个问题，答案是您不应该“复制/粘贴”任何内容，并且消除服务之间的“硬”同步依赖关系与它无关。这是一个强有力的信号，表明单片分解的功能边界是错误的。我现在的问题是，当一个微服务应该拥有并管理自己的数据时，你会使用三个独立的服务对同一数据进行验证吗？此外，通常有一些近乎横切的实用程序类型的问题，即多个微服务可能共享，并且公共库（例如Java的JAR）不违反架构的意图。无需复制/过去。
现在，这就是为什么“强大的”同步依赖关系通常是一个坏主意。微服务架构的目的是以最小的风险快速部署新的和改进的“单/做一件事”功能，并且不会对性能产生负面影响。它可以实现渐进式改进，并加快所需功能的上市时间如果你的新服务行为不端，它只会影响它负责的功能 - 没有别的。现在想象一下，如果你通过“代码模块”而不是功能/功能来分解你的单片应用程序。你最终只能得到一个分布式的整体！您不仅失去了架构的所有优点和意图，而且性能和复杂性也会对可能致命的程度产生负面影响。