在 Nodejs 中构建微服务的更好方法答案

【问题标题】：Better ways of building Microservices in Nodejs在 Nodejs 中构建微服务的更好方法
【发布时间】：2018-05-16 09:17:15
【问题描述】：

我参与了一个非常大的项目，我们已经在 Nodejs 中构建了大约 50 到 70 个微服务。所有这些服务都导入了大约 5 到 10 个核心通用模块。在这个阶段，如果公共核心模块有任何单行更改，我们必须更新、构建和部署所有工件。有没有更好的处理方法？

谢谢。

【问题讨论】：

您能更详细地解释一下当前的架构吗？你在使用码头工人吗？当前的部署和构建流程是什么？
是的，我们确实使用 docker 通过 Jenkins 进行构建。对于特定的项目组，我们还有一些带有特定 node_modules 的 docker-images，因此每次触发构建时都不会下载 node_modules，除非我们的 package.json 发生变化。构建过程完成后，将使用代码及其 node_module 依赖项创建工件，因此很容易在更高（6 到 8 个）环境中移动。希望我回答了你的问题。
当然，只是希望您提供更多信息，以便可以回答您问题的人获得所有需要的信息。为你的问题投上我的一票:)
普通核心模块不应该是更稳定的超时时间，并且不需要在一段时间内进行很多更改。如果这些通用模块是作为服务开发的，只要不改变服务接口就可以了，否则如果直接导入，就得经过这个过程，直到模块成熟为止。跨度>

【解决方案1】：

我同意@skjagini 核心模块应该是稳定的，它们应该是真正的核心。总的来说，我主张在你的微服务之间尽可能少地共享，它们应该是独立开发和可部署的。它们不应该需要部署同步，因为你需要协调所有微服务的部署，至少你会破坏一些东西。如果这是您发现的问题，那么您自己拥有的是分布式单体而不是微服务架构。

我看不到您发布的问题的任何简单解决方案。如果公共代码确实发生了变化，那么任何使用该公共代码的可部署单元自然都需要重新构建和重新部署。唯一的例外是，如果特定的可部署项目不需要更改，在这种情况下，这可能意味着您的模块做得太多，没有明确的目的或太大。

【讨论】：