领域对象共享微服务

Posted 2023-03-08

【中文标题】领域对象共享微服务

【英文标题】：domain object sharing microservices

【发布时间】：2018-10-20 07:34:30

【问题描述】：

我正在尝试了解微服务。我想知道如何解决微服务架构中一对多/多对多关系的问题以及最佳实践是什么。假设我想将学生课程应用程序转换为学生服务和课程服务和学生服务谈话到学生表和课程服务谈话课程表在同一个数据库中。

示例： 学生可以注册很多课程，很多课程也可以有很多学生（多对多关系）。我有 2 个微服务 微服务 1：学生服务 微服务2：课程服务

学生服务有学生对象

@Entity
@Table(name = "STUDENT")
public class Student 

@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private long id;

@Column(name = "NAME")
private String name;


//@ManyToMany(fetch = FetchType.LAZY)
//@JoinTable(name = "STUDENT_COURSE", joinColumns = @JoinColumn(name = //"STUDENT_ID"), inverseJoinColumns = @JoinColumn(name = "COURSE_ID"))
//  private List<Course> courses = new ArrayList<Course>();

课程服务有课程对象

@Entity
@Table(name = "COURSE")
public class Course 

@Id
@Column(name = "ID")
private long id;

@Column(name = "COURSE_NAME")
private String name;

//@ManyToMany(mappedBy = "courses", fetch = FetchType.LAZY)
//private List<Student> students = new ArrayList<Student>();

我了解学生服务必须致电课程服务来获取课程，但我如何将课程映射到学生？（例如学生 A 已注册课程 X、Y、Z）

如何获取学生的课程列表或学生的列表 课程？ 我是否需要在

Student 中复制 Course 课程 课程服务中的服务

和

学生

班？ 我需要 将域类移动到公共项目，然后在它们之间共享 避免重复的微服务？

您能否帮助我回答解决微服务中多对多关系问题的最佳实践？

【问题讨论】：

您的微服务会引发任何事件吗？

目前还没有，必须实施。我欢迎你的建议

【参考方案1】：

在考虑微服务时，记住Bounded contexts 的概念会有所帮助

Martin Fowler：有界上下文既有不相关的概念（例如仅存在于客户支持上下文中的支持票证），也有共享概念（如产品和客户）。 不同的上下文可能具有完全不同的共同概念模型，这些模型具有在这些多义概念之间进行映射以进行集成的机制。

Student 和 Course 的概念在应用程序的每个微服务中可能会有很大不同。例如，Student 可以在 StudentInformationManagement 微服务中定义为具有标识符、名字、姓氏和地址的人，并且在 CourseAttendance 微服务中只有一个标识符和课程列表。

也就是说，我不会为这些微服务使用共享数据库，而是使用所需的实体创建单独的数据库。只有标识符在服务之间“共享”。

在设计数据模型时尝试考虑您的流程：当学生注册时，我会获得哪些信息？他什么时候报名上课？

【讨论】：

我习惯于为不同的环境（开发、认证、生产、D-1 等）创建不同的数据库，并为每个上下文我调用特定的所有者和命名空间。

很好的参考。就我的 2 美分，我发现一旦你克服了重复代码的事实（这伤害了我们所有人），你会发现封装你的服务实际上有助于使事情变得更健壮。例如，我的服务中有许多“重复”类，但“借用”类通常具有较少的字段并且它们只有 getter（不要让借用服务修改另一个服务的实体）。这很棒的原因是它确保这些对象在它们自己的上下文之外是不可变的。

【参考方案2】：

这是微服务领域的典型问题。即使在面向微服务的架构中，重点也应该放在解决非常具体的业务问题上，然后有支持的数据库表。

在这种情况下，“StudentRegistration”服务似乎会有所帮助，它可以获取相关连接。拥有像“StudentRegistration”这样的第三个服务可能会在服务中引入不仅仅是明显的网络调用，如果缓存使用得当，这些微服务可以非常快速地响应。

事实上，您可以根据您的业务流程或用例评估是否最终需要所有三种服务，即 Student、Course 和 StudentRegistration，或者可以合并某些组合。如果他们中的一些人在彼此不了解的情况下无法回答大多数业务问题，则可以做到这一点。

最后，在共享数据库上实际实现微服务可能并非完全错误。见：http://microservices.io/patterns/data/shared-database.html

请注意，通过事件模型为此类密切相关的微服务拥有完全独立的数据库并始终保持这些表同步并不简单，因此在这方面要小心。然而，这并非不可能。有记录的设计模式可以满足跨多个微服务的业务事务，即：CQRS 模式 (https://martinfowler.com/bliki/CQRS.html)、SAGA 模式(http://microservices.io/patterns/data/saga.html) 和事件溯源：http://microservices.io/patterns/data/event-sourcing.html。

【讨论】：

所以如果我使用共享数据库，我是否需要复制学生服务学生对象中的课程域对象和课程服务课程类中的学生域对象？我们如何做到这一点？我需要在这两个服务中使用域对象的@Entity 吗？

Hibernate 为我创建了表，那么应该存在哪些域对象以及域对象在课程服务和学生服务中的外观如何？