问如何与微服务体系结构保持关系的完整性

EN

订购服务是否只是用用户的ID插入“订单”记录，而没有在任何地方保持任何关系？

是的

这里要记住的是，尽管这些服务被称为“微”，但它们往往是相当大的。您将有大量紧密耦合的对象，例如地址或它们中的任何内容。

任何系统都会选择一个范围，上面写着“好吧，我不关心100年前的客户家谱，也不在乎他们开的是哪种类型的车”。

Microservice体系结构要求您考虑整个系统可能不是单个范围。

当您习惯于编写单点或大型关系数据库时，立即的想法是“但我需要客户和订单之间的引用完整性！”但现实往往是你没有。

你可以想象出一整吨与维护客户/客户系统相关的逻辑，而这实际上与你的系统是一个电子商务网站、一个留言板、还是一个税务系统或其他任何东西都没有关系。

您希望能够在系统的该部分添加功能，而不必考虑购买商品或填写纳税申报表。

因此，在其他系统中，用户id的松散耦合是很好的，当然，在删除或丢失用户信息时，您需要小心。维护审计跟踪或复制关键字段(如名称和地址)到其他系统，如果这样做是明智的，例如在已完成的订单上，需要一个送货标签。

您使用API:s和松散耦合的微服务。实际上，这意味着您的服务之间的休息通信。如果一个实体在一个微服务中被添加、删除、编辑或还原，而这会影响到其他微服务中的数据，则可以让第一个服务通过http发出REST请求，该请求可能使用http头中的令牌进行身份验证，而该请求使第二个服务更新其底层数据，而不管其结构如何，这样它才能保持其有效性。

我认为您应该有一个入口点组件(可能，eshop webapp MVC)到您的miscroservices的生态系统中，它将扮演协调器的角色，当然，您的微服务可能会在http上进行协作，但是对于写操作，这种请求应该通过一个条目，而执行器必须确保用户的操作顺序(通过队列和操作状态)，否则，当用户删除订单时(仅举一个例子)，您可能会遇到问题，这就是为什么您必须保持这样的操作顺序才能获得身份。

您还可以将体系结构转换为事件驱动的体系结构，这也可以确保操作的顺序。