微服务架构中如何在微服务之间共享java模型

Posted 2023-03-08

【中文标题】微服务架构中如何在微服务之间共享java模型

【英文标题】：How to share java models between microservices in microservice architecture

【发布时间】：2019-08-19 00:56:40

【问题描述】：

我正在设计我的新应用程序的架构。我选择了微服务架构。在我的架构中，我注意到我有不同微服务使用的模型。我想知道是否有一种方法可以在微服务之间共享模型代码，而不是在每个微服务中编写它们。

顺便说一句，我正在为我的应用程序使用 Spring Boot 框架。

【参考方案1】：

在微服务架构中，每一个都是绝对独立的，并且必须隐藏内部实现的细节。

如果您共享模型，您就是在耦合微服务，并失去了最大的优势之一，即每个团队都可以不受限制地开发其微服务，并且无需了解如何发展其他微服务。请记住，您甚至可以在每种语言中使用不同的语言，如果您开始耦合微服务，这将很困难。

https://softwareengineering.stackexchange.com/questions/290922/shared-domain-model-between-different-microservices

【讨论】：

嗯，微服务（通常）需要相互通信，所以您必须至少公开一个 api，而该 api 附带一个模型

@Lino 如果你是专门找POJO的，请把它打包成jar，在微服务中使用。

@MebinJoe 这正是我的想法。基本上可以有一个 auth-service，它包含一个 Account-POJO，它又在一个公共模块中提供，可以被另一个微服务使用。但是：使用 auth-service 的微服务的作者可能决定实现自己的 POJO 或其他结构，这些结构将用于将 JSON 响应映射到类或 w/e 消费服务需求。跨度>

【参考方案2】：

您可以将模型类移动到不同的项目/存储库，并将其作为依赖项添加到需要共享它的微服务中。

【讨论】：

如果这样做，您将在两个微服务之间创建耦合，并且实际上最终可能会产生仅模仿微服务的单体应用程序。

【参考方案3】：

您应该只共享定义了您的微服务 API 的模型，例如Protobuff .proto 文件或从中生成的 Java 类。

这通常通过创建一个单独的项目或将您的微服务项目转换为多模块项目来完成，其中一个模块是具有接口定义的瘦 API 模块。

在微服务之间共享代码并没有错，但你必须小心。分享太多内部实现细节，你最终会得到distributed monolith instead of micro-services。

【参考方案4】：

您可以使用通用模型创建一个单独的项目，创建该项目的 jar 并在其他微服务中添加此 jar 的依赖项。

但我有一个实践经验，维护这个公共项目是一场噩梦，因为每次更改都必须创建一个新版本并更新所有微服务的构建脚本。

在我看来，我们不应该在微服务之间共享模型。

【讨论】：

我知道这个讨论很晚了。但是，如果您决定不使用单独的项目来处理所有模型，并且决定在每个微服务中重用每个模型，那么您最终会遇到同样的问题。当模型更改时，您必须更改每个微服务中的所有模型文件，这最终会做更多的工作，然后只需更新每个微服务的依赖项。

@RutgerdeGroen 你是对的。我也是这么想的。如果您发现分享模型，请告诉我正确的方法。例如：来自一个微服务 API 的响应列表，供另一个微服务 FeignClient 使用。不要认为在新的微服务中再次创建模型是个好主意。

我最终创建了一个私有 npm 包，其中包含需要在服务之间共享的所有模型。例如，我使用相同的数据模型创建了一个 REST API 和一个 GraphQL 微服务。他们都通过一个 npm 包访问模型。这样你就可以在一个地方管理所有的模型，你只需要在一段时间内更新依赖关系。

【参考方案5】：

不确定您的微服务是否使用 Swagger，但是，您可以使用 Swagger Codegen 来生成模型。

例如，如果您有接受和/或返回用户对象的 UserService。 UserService 的使用者可以使用 Swagger Codegen 插件在构建时自动生成 User 类。

您可以非常轻松地使用 Swagger Codengen maven 或 gradle 插件。

【参考方案6】：

如果你对这个决定很严厉，你会以这样或那样的方式遇到不令人满意的情况。这取决于您的 SDLC 和团队动态。在 Ipswitch，我们有许多协作的服务，并且有高度共享的概念，例如设备和监视器。让每项服务都有自己的模型是不可持续的。我们在一个案例中这样做了，翻译只是增加了额外的工作并引入了不一致的缺陷。但是整个系统是由一个大型开发团队共同构建的。所以分享在那里最有意义。但是对于拥有多个团队和跨微服务的多个 SDLC 的企业来说，隔离模型以避免耦合更有意义。然而，即便如此，如果团队接受这样做的风险/收益，由给定团队管理的一组密切协作的服务当然可以共享一个模型。除了学术和哲学之外，这并没有错。

因此，简而言之，尽量少分享，但也要避免为您的团队带来不必要的工作。