我想用多对一等DB关系的微服务架构。在整体架构,我们可以轻松地创建,因为它们属于同一个项目,但在微服务架构,我们如何能达到同样的实体关系。
例:
有一个userDeatil服务等为产品详情service.Now有一个名为的OrderDetail第三服务和订单将有用户ID和与之相关ProductIDs。那么,如何才能管理“用户和订单”和“订单和产品”之间的关系。
我已经搜索过网,但没能得到公平idea.There是具有相同的查询,但不具有明确的答案另一个线程。 Link
在我看来,你的情况是你如何指定你的服务,你特别是如何定义每个服务界上下文!
根据情况上述我看不出有任何理由的产品服务应该了解订单anythings(即使它只是顺序-ID)和倒退。还有一个问题,我在这种情况下看:如果一个服务不可用你的服务将无法正常工作(例如,当产品服务它不在线,您的订单服务将无法正常工作,因为他从产品服务需要产品的细节...)。
我想你应该重新考虑你的微服务的限界上下文。你应该记住:
在DDD(领域驱动设计)与它的工具范例提供了很大的帮助,以帮助你,在你的服务的定义过程中,鼓励这些品质。
所以,下面只是一个想法(这不是一个建议,你应该检讨是否有重要的商业案例):