微服务共享代码

Question

有很多答案和博客说"从不在微服务之间共享代码",我现在想知道我应该如何遵循这个建议.我有以下微服务,每个都通过RabbitMQ进行通信:

快速服务器和两个不同的后台服务具有完全不同的代码,而请求工作者只是多个实例.每个请求工作者都应该处理一个请求,并在完成请求后直接回复它(RPC).

我的问题:

我编写了一个class(RequestScheduler),它提供了调度请求的方法(例如getProfile: Promise<IProfile>).因为我显然不允许在微服务之间共享代码,微服务之间的通信代码怎么样？

我没有看到如何避免在左侧的微服务中共享代码.

Answer 1

在我所见过的有关微服务架构的讨论中，横切关注点通常没有得到很好的记录——可能是因为乍一看它们似乎与概念相悖（尽管事实并非如此）。在开发我们的应用程序（第一次使用微服务）时，我们遇到了与您所问的类似的问题。在与一些比我们当时拥有更多经验的人交谈后，我们开始意识到微服务的概念更多的是关于域封装，因此关于大小、库共享等的硬性规则都是次要的微服务具有单一职责 (SRP) 并拥有单一、定义明确的域 (DDD) 的想法。

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

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

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

Answer 2

@kentor 日志记录是一个跨领域的问题。如果有一个公司的日志记录标准并且有可用的模块或库，那么您可以使用该库。它是共享的，但这很好，因为日志记录非常隔离，不应该干扰您的业务域逻辑或工作流程。微服务的一般准则是不共享代码。可以共享的东西是不经常更改的库，例如美国各州、颜色等。为了回答您的问题what about the code for the communication between the microservices，我会说不要共享此代码。与其他应用程序共享此代码/库的代码可能会引入副作用错误。