微服务：如何处理外键关系 [英] Microservices: how to handle foreign key relationships

问题描述

微服务体系结构建议每个服务应处理自己的数据。因此，依赖于其他服务（服务B）拥有的数据的任何服务（服务A）都不应通过直接DB调用而是通过第二个服务（服务B）提供的api访问此类数据。

Microservices architecture suggest that each service should handle it's own data. Hence any service (Service A) dependent on data owned by other service (service B) should access such data not by making direct DB calls but through the api provided by the second service (service B).

那么微服务最佳实践在检查外键约束方面有什么建议。

示例：我正在开发交付功能（微服务1）用于产品和某些产品，仅可以将产品表中提到的某些位置交付给仅产品微服务（微服务2）访问。

Example: I am developing a delivery feature (microservice 1) for products and certain products are deliverable to only certain locations as mentioned in the products table accessible to only products micro service (mircoservice 2).

我如何确保微服务1（即交付功能）未将订单送到未服务的位置。我有这个问题，因为交付功能无法直接访问产品数据库，因此在将交付订单放入交付数据库中时，在数据库级别没有适用的约束（无法检查产品数据库中是否存在外键匹配项）或表）。

How do I make sure that microservice 1 (i.e delivery feature) does not take an order to a unserviced location. I have this question because delivery feature can not directly access products database, so there is no constraints applicable at DB level when a delivery order is place in to delivery data base (no check is possible to see if a foreign key match exists in products database or table).

推荐答案

可以将共享数据库用于多个微服务。您可以在此链接中找到微服务的数据管理模式： http：// microservices .io / patterns / data / database-per-service.html 。顺便说一句，对于微服务架构而言，这是一个非常有用的博客。

It is possible to use a shared database for multiple microservices. You can find the patterns for data management of microservices in this link: http://microservices.io/patterns/data/database-per-service.html. By the way, it is a very useful blog for microservices architecture.

在您的情况下，您更喜欢针对每个服务模式使用数据库。这使微服务更加自治。在这种情况下，您应该在多个微服务之间复制一些数据。您可以在微服务之间通过api调用共享数据，也可以通过异步消息共享数据。这取决于您的基础架构和数据更改的频率。如果不经常更改，则应使用异步事件复制数据。

In your case, you prefer to use database per service pattern. This make microservices more autonomous. In this situation, you should duplicate some of your data among multiple microservices. You can share the data with api calls between microservices or you can share it with async messaging. It depends on your infrastructure and frequency of change of the data. If it is not changing often, you should duplicate the data with async events.

在您的示例中，送货服务可以复制送货地点和产品信息。产品服务管理产品和位置。然后将所需数据与异步消息一起复制到Delivery Service的数据库中（例如，您可以使用Rabbit mq或apache kafka）。交付服务不会更改产品和位置数据，但会在完成工作时使用这些数据。如果交付服务使用的部分产品数据经常更改，那么使用异步消息传递进行数据复制将非常昂贵。在这种情况下，您应该在产品和交付服务之间进行api调用。送货服务要求产品服务检查产品是否可送货到特定地点。送货服务要求产品服务提供产品和位置的标识符（名称，ID等）。这些标识符可以从最终用户那里获取，也可以在微服务之间共享。由于此处的微服务数据库不同，因此我们无法在这些微服务的数据之间定义外键。

In your example, Delivery service can duplicate delivery locations and product information. Product service manage the products and locations. Then the required data is copied to Delivery service's database with async messages (for example you can use rabbit mq or apache kafka). Delivery service does not change the product and location data but it uses the data when it is doing its job. If the part of the product data which is used by Delivery service is changing often, data duplication with async messaging will be very costly. In this case you should make api calls between Product and Delivery service. Delivery service asks Product service to check whether a product is deliverable to a specific location or not. Delivery service asks Products service with an identifier (name, id etc.) of a product and location. These identifiers can be taken from end user or it is shared between microservices. Because the databases of microservices are different here, we cannot define foreign keys between the data of these microservices.

Api呼叫可能更易于实现，但此选项的网络成本较高。此外，在进行api调用时，您的服务也不太自治。因为在您的示例中，当产品服务关闭时，交付服务无法执行其工作。如果使用异步消息传递复制数据，则进行传递所需的数据位于传递微服务的数据库中。当产品服务不起作用时，您将可以交货。

Api calls maybe easier to implement but network cost is higher in this option. Also your services are less autonomous when you are doing api calls. Because, in your example when Product service is down, Delivery service cannot do its job. If you duplicate the data with async messaging, the required data to make delivery is located in the database of Delivery microservice. When Product service is not working you will be able to make delivery.

这篇关于微服务：如何处理外键关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！