在微服务和客户端库项目之间共享模型是一种好习惯吗？

Question

我正在为它创建一个REST微服务和一个客户端库。对于他们两个，我将使用相同的语言（在这种情况下为C＃）。

在这些项目之间共享响应/请求模型是一种好习惯吗？或者我的客户项目应该是独立的，因此拥有自己的（实际上是相同的）模型？

Answer 1

  

在...之间共享响应/请求模型是一种好习惯吗？   REST微服务和客户端库？

是的，这是一个很好的做法。请求/响应模型是服务定义的一部分，因此是服务与其使用者之间应该共享的少数几件事之一。服务和消费者之间的垂直耦合是不可避免的，因此应该被接受。但是，在服务之间共享模型时应该小心。

  

现在我对以下内容感到困惑：如果是另一个微服务器   使用该客户端库

我不确定您的意思 - 该服务不使用客户端库。

理想情况下，服务之间不应共享模型，除非它们是代表交叉问题的模型，如安全性，监控等。

Answer 2

可能会出现o.k.分享这些模特。一般来说，我将它们分开。客户端上的模型不必担心数据来自何处以及这些模型（服务端）更改的频率以及更改是否直接影响它们。解耦两个方面可以使您的构建/部署周期更稳定，并且不会强制客户端在服务模型更改时必须重建等。客户端模型的不同部分也可能从不同的微服务中获取数据。所有这一切都与您的整体模型复杂性有关。我猜。

Answer 3

最简单的答案是没有。

长答案是微服务架构的原理和目的是保持服务分离。这样我们就可以从中受益（例如，更高的迭代频率，更易于测试，更低的部署风险等）

• 该服务完全不应该知道其他服务。因此他们可以使用不同的语言和技术堆栈。如果在服务和使用者之间共享模型，它将把服务绑定在一起，使其难以升级（例如，升级Java版本，springboot版本），并且失去使用不同语言的自由。

• 当服务数量增长时，依赖关系将非常难以管理。相反，我们应该使用定义良好的API文档（例如Swagger可以帮助使文档始终保持最新状态），并进行版本控制以使API向后兼容。