管理微服务中的数据模型共享

Question

谁能帮忙理解一下。

我们正在使用微服务架构开发应用程序现在我们有不同的结构。

根据功能我们制作了不同的微服务。

现在我们被一分挡住了。

除了不同的 Actor，我们还有“管理”或“客户服务”用户。

从他们那里，我们有一些特定的 API。

我们对此有疑问。

1) Do we need to consider creating different micro service project.
2) Assume we consider different micro services, do we need to share all the domain models to this micro service.

3) Assume, we keep Admin or Customer Service APIS in respective Micro services, how good it is. my point is about exposing or potential to expose Admin API to the world.

Answer 1

1) 我们是否需要考虑创建不同的微服务项目。

如果您的数据迁移到微服务架构有意义，是的，您应该考虑微服务架构。

3) 假设，我们在各自的 Micro 中保留 Admin 或 Customer Service APIS 服务，多好。我的观点是关于暴露或可能 向世界公开 Admin API

恐怕您从错误的角度看待这个问题。用户的角色不应该是驱动微服务设计的角色。相反，它应该是您的数据/实体/域。重击规则是不同微服务的数据存储应该不同。

2) 假设我们考虑不同的微服务，是否需要共享 此微服务的所有领域模型。

我想在上述问题之后回答这个问题。如果你的微服务设计得当，你的域重叠将会最小化，反过来需要共享的代码（域 POJO）也将是最小的，但它仍然不是完全可以避免的。有一些创造性的方式来分享代码

1. 将包含所有共享代码的库 jar 文件发布到您的内部仓库并在您的主项目中引用它

2. 拥有一个包含所有微服务的父项目，以便您可以共享代码。 （恭喜，你刚刚创建了一个单一的代码库 :)） 说真的，恕我直言，这违背了微服务的精神。即使您仍然可以将每个微服务部署为单独的应用程序/jar 文件，但代码库仍然是单一的）

一个小建议是，不要沉迷于代码共享能力。如果你决定使用像 go/rust 这样的非 JVM 语言来编写你的其他微服务怎么办。毕竟，这是微服务架构的主要卖点之一。