微服务和耦合

时间:2017-04-14 19:57:55

标签: spring-mvc microservices coupling

我正在尝试使用某种微服务架构。我正在尝试使用HTTP和JSON作为通信媒介(我知道比将其称为ReST更好)。

所以,我正在使用spring-mvc,我希望在被调用者上使用一个类作为ResponseBody,在被调用者上使用RequestBody。所以碰巧我可以在两个项目上复制和镜像类,或者创建一个jar并将它包含在两者中。

我在两种情况下看到耦合,第一个是重复耦合,另一个是(我确定它有一个名字)耦合。

RequestResponse模型不是项目的共同点。我正在使用事件驱动的架构,事件有些相似(有点完全相同)。

我该怎么办?

2 个答案:

答案 0 :(得分:0)

根据公共库,与微服务的低耦合并不矛盾。您只是想确保您共享的库是针对与您的服务无关的特定问题而开发的,并且它不依赖于您服务中的任何内容。

想想那个图书馆就像你想要的第三方图书馆一样。例如,你提到你正在使用弹簧 - 只是你在两个微服务中使用弹簧的事实并不意味着它们是耦合的。

这也意味着您必须对您的库进行版本化,并将其留给消费的微服务团队,以决定何时可以更改/升级版本。这是一个link,用于在java中创建不同的库版本。另请阅读此link,其中包含有关清单的一般信息。

在java中,您可以使用两种方法之一来包含版本化库。

  1. 明确地在命名空间或接口/类名中包含版本号。这允许类加载器具有唯一标识并且能够容易地同时包括多个版本。 (可能是首选的方式)。
  2. 使用相同的名称,一次只包含一个版本的jar。这意味着您必须使用新的jar依赖项替换现有的jar依赖项,然后采用任何可能的更改。检查这个很棒answer
  3. 如果您的库是通信客户端,您可以考虑在服务器端同时支持多个版本(以允许单独的微服务团队按自己的步调采用更新的版本)。

答案 1 :(得分:-1)

如果您的微服务发布了一个界面,您需要特别注意如何处理更改。共享通信库是将这两种服务耦合到一起的特别危险的方式,特别是因为它给出了服务之间的一致性错觉。

如果你想共享一个界面,你必须至少做以下(IMO):

  • 对您的微服务进行版本控制,并支持所有先前版本的传输有效负载。 (无论如何你想这样做)
  • 将实际的运输合同作为版本化的包发送(这样消费者就不会被迫使用最新的合同)我认为在java中你可能会使用maven(但我不是一个java人)

这非常重要,因为它意味着两件事情是可能的

  • 服务可以随意更改其界面,而无需担心下游代码依赖性(假设它遵循版本规则)。
  • 消费者可以选择何时更新其通信包装器,并且从不公开强制构建和发布新版本以响应其中一个依赖项的更改。

有关版本控制的更多信息,请查看我的博客。 Microservice versioning; How to make breaking changes without breaking stuff