在微服务设计中生成 JPA 实体答案

【问题标题】：Generating JPA entities in microservices design在微服务设计中生成 JPA 实体
【发布时间】：2015-06-08 15:56:00
【问题描述】：

我正在考虑设计，对在微服务架构中生成实体有点困惑（虽然我是微服务设计的新手，但我对多个精益战争很着迷）。我有数据库和多重战争的想法。我应该从 DB 生成实体并将它们放在一个 jar 中，并将 jar 包含在我创建的每场战争中，或者还有另一种选择。其次，我放置persistence.xml。如果我打算稍后使用缓存来缓存实体实例，上述方法会带来任何问题。谢谢

【问题讨论】：

不确定我是否了解微服务如何改变 JPA 实体设计与任何其他类型的应用程序。您是在谈论实体本身，还是如何组织它们并处理多个微服务中使用的同一实体？
不，我主要关心的是实体包装。我是否应该将实体打包在 jar 中并包含在每场战争中。或者战争应该只包括相关实体。
您可能应该通过描述您打算解决的问题来重申您的问题。服务有多少，实体有多少，服务和实体之间是什么关系？
我不知道这有什么不同。如果我说 10 个实体和 5 个服务。
好吧，我相信我们需要对微服务进行去中心化的数据管理。但对我来说这似乎有点过头了，我将创建 5 个服务，我的数据库有 10 个表。为什么要将一个小架构分解为多个架构。在每个模式中创建 5 个模式和 2 个表是否很好。

标签： jakarta-ee jpa microservices

【解决方案1】：

如果所有微服务共享同一个数据库，那么就无法将微服务移动到另一台主机上，这违反了最小数据共享原则，增加了依赖等等。
集中式数据存储在操作上很方便，但微服务应该希望嵌入其所有依赖项以实现独立部署。另一种方法是：每个微服务都嵌入了它的所有依赖项，包括数据库，因此将这个微服务移动到任何地方都是微不足道的，这很漂亮，但在当前上下文中并不实用。

微服务应该拥有自己的表，因为在微服务之间共享表会扼杀移动性；但是，共享数据库集群安装绝对没问题（Nadareishvili, Mitra, McLarty, & Amundsen, 2016）。我发现这种方法最好：如果数据库是 Oracle 或 SQL Server，则微服务在同一数据库中拥有独立的模式。如果数据库是 MySQL，那么微服务应该拥有独立的数据库，因为我相信 MySQL 每个数据库只支持一个模式。

微服务不仅可以拥有不同的数据库，还可以拥有不同类型的数据库，例如在我当前的应用程序中，我们使用 MySQL 进行在线事务处理，但使用 NoSQL 进行离线处理。

使用 Spring Boot 和 Spring Data JPA，我不会遇到在每个微服务中生成实体的任何问题。我仍在微服务中复制实体代码，但它仅适用于所需的实体。我们总是可以创建一个公共 jar 并在微服务之间共享，但它并不适用于所有情况。类似的讨论在这个question

【讨论】：