Javascript 在微服务之间共享代码-在这种情况下是否合理？

有太多的答案和博客帖子说“永远不要在微服务之间共享代码”，我现在想知道我该如何遵循这些建议。我有以下微服务，每个微服务都通过RabbitMQ进行通信：

express服务器和两个不同的后台服务具有完全不同的代码，而请求工作者只是多个实例。每个请求工作者都应该处理一个请求，并在完成请求后返回一个直接回复（RPC）

我的问题：

我编写了一个类（

RequestScheduler

），它提供了调度请求的方法（例如

getProfile:Promise

）。因为我显然不允许在微服务之间共享代码，那么微服务之间的通信代码呢

---

我看不出有什么办法可以避免将代码与左侧的微服务一起共享。

@kentor日志记录是一个跨领域的问题。如果有一个用于日志记录的公司标准，并且为其提供了一个模块或库，那么您可以使用该库。它是共享的，但这很好，因为日志记录是非常隔离的，不应该干扰您的业务域逻辑或工作流。微服务中的一般准则是不共享代码。可以共享的东西是不会经常更改的库，如美国的州、颜色等。为了回答您的问题

关于微服务之间通信的代码如何

，我建议不要共享此代码。将此代码/库共享给其他应用程序可能会带来副作用bug。

在我所看到的有关微服务体系结构的讨论中，横切关注点往往没有得到很好的记录，可能是因为乍一看它们似乎与概念相反（尽管它们不是）。在开发我们的应用程序（首次使用微服务）时，我们遇到了与您所问问题类似的问题。在与一些在it方面比我们当时有更多经验的人交谈后，我们意识到微服务的概念更多地是关于域的封装，因此围绕大小、库共享等的严格规则都是次要的，而不是微服务有单一责任（SRP）的概念并且拥有一个定义良好的域（DDD）

我们有用于将新服务连接到事件总线、管理授权、跨服务事件日志的库（我们将其作为NuGet包进行管理），甚至还有用于错误处理的标准中间件——我们几乎在所有服务中共享这些库

虽然我们还没有定义一个硬性的规则，但我想说，我们对待代码重用的方式是“如果我们生态系统中的所有微服务都需要它，那么它必须作为一个共享库提供。如果大多数微服务都可以使用它，那么它应该作为一个共享库提供。 每个微服务都可以选择是实现共享库还是推出自己的解决方案。”

---

只要您的共享代码以允许每个微服务独立管理其自身升级的方式分发，并且您的共享代码不受任何特定于域的语言或问题的影响，请务必共享

微服务之间的通信代码

对我来说就像一个库或包，不会经常更改。为什么不把它当作一个包呢

---

一个好的选择是在私有npm注册表中创建一个包。然后，您将能够拥有该软件包的不同版本。因此，使用语义版本控制将是安全的。

请您详细描述您的问题，不清楚您要避免复制哪些代码。如果您的两个后台服务共享相同的代码，那么将其提取到单独的微服务中可能是值得的？我试图避免使用帮助我在微服务之间通信的代码（例如，如上所述的调度请求），因此这不可能是它自己的微服务。我们需要有一点RabbitMQ的背景知识才能了解RPC需要什么，但我相信如果我使用REST进行通信，我也会面临同样的问题。将代码打包为模块。所以我在这里很粗鲁-投票以基于意见的方式结束这个问题是非常愚蠢的+“不要共享代码”的唯一合理含义是“不要管理影响不同微服务的代码”。例如，如果microservicea和B在v1中使用LibX，那么它是完全正常的。即使是必要的，在没有LIB的今天，您如何开发任何东西？如果microserviceb将LibX升级到v2，那么就可以了，因为microservicea不必这样做。他们确实是独立的。因此，将公共代码打包到lib中，并确保一旦“发布”lib中的代码（在版本中）不会更改。如果您想更改库，请创建新版本。这就是问题的全部。您是否建议每次从头开始编写通信库都不那么容易出错？完全不同意。顺便说一句，每个库都可能引入副作用bug。这是你为不尝试一次又一次地解决同一个问题而付出的代价，这通常看起来更容易出错，效率更低。在我看来，“微服务之间的通信”是在微服务之间重用自定义库的一个很好的例子。如果您拥有域和微服务，您可以创建一个公共库，该库可以共享给域中的其他微服务。我试图避免的是，如果我有一个API，我不会创建一个我将分发给我的客户消费者的客户机库。AWS SDK是不同的，虽然它是提供的，但它是由社区和AWS人员维护的，而不是由那些在API上工作的人维护的。