我正在尝试了解微服务。我想知道如何解决微服务架构中一对多/多对多关系的问题以及最佳实践。假设我想将学生课程应用程序转换为学生服务和课程服务以及学生服务讲座到同一数据库中的学生表和课程服务会谈课程表。
实施例: 学生可以报名参加许多课程,许多课程也可以有很多学生(多对多关系)。我有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)
你能否通过回答解决微服务中多对多关系问题的最佳实践来帮助我?
答案 0 :(得分:0)
这是微服务领域的典型问题。即使在面向微服务的体系结构中,重点应放在解决非常具体的业务问题上,然后才能拥有支持的数据库表。
似乎是学生注册&#39;在这种情况下,服务可能有所帮助,可以获得有问题的联接。有第三项服务,如学生注册和#39;可能会在服务中引入更多明显的网络调用,如果正确使用缓存,这些微服务可以非常快速地响应。
事实上,您可以根据您的业务流程或用例,评估您是否需要最后的所有三项服务,即学生,课程和学生注册,或者某些组合可以合并。如果他们中的一些人的组合在不知道彼此的情况下无法回答大多数商业问题,那么就可以做到这一点。
最后,在共享数据库上实际实现微服务可能并非完全错误。请参阅: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。
答案 1 :(得分:0)
在考虑微服务时,有助于记住Bounded contexts
的概念Martin Fowler :有界上下文具有两个不相关的概念(例如仅支持票证仅存在于客户支持上下文中),还有共享概念(如产品和客户)。 不同的上下文可能具有完全不同的共同概念模型,其机制可以在这些多义概念之间进行映射以进行集成。
学生和课程的概念在您的应用程序的每个微服务中可能会有很大差异。例如,可以将Student定义为StudentInformationManagement微服务中具有标识符,名字,姓氏和地址的人员,并且只有一个标识符和CourseAttendance微服务中的课程列表。
也就是说我不会为这些微服务使用共享数据库,而是使用所需的实体创建单独的数据库。只有标识符在服务之间“共享”。
在设计数据模型时尝试考虑您的过程:当学生注册时,我会获得哪些信息?当他报名参加课程时?