微服务库数据同步微服务共享数据库

转载

数据大侠客 2024-05-05 19:55:55

文章标签 微服务库数据同步数据库数据开发人员 文章分类 运维

架构模式: 共享数据库

上下文

让我们假设您正在使用微服务架构模式开发在线商店应用程序。大多数服务需要在某种数据库中保存数据。例如，订单服务存储有关订单的信息，而客户服务存储有关客户的信息。

微服务库数据同步微服务共享数据库_开发人员

问题

微服务应用程序中的数据库体系结构是什么？

要点

服务必须松散耦合，以便可以独立开发，部署和扩展
某些业务事务必须强制执行跨多个服务的不变量。例如，下订单用例必须验证新订单不会超过客户的信用额度。其他业务事务，必须更新多个服务所拥有的数据。
某些业务事务需要查询由多个服务拥有的数据。例如，查看可用信用使用必须查询客户以查找creditLimit和Orders以计算未结订单的总金额。
某些查询必须连接由多个服务拥有的数据。例如，查找特定区域中的客户及其最近的订单需要客户和订单之间的联接。
有时必须复制和分割数据库才能扩展。请参阅比例立方体。
不同的服务有不同的数据存储要求。对于某些服务，关系数据库是最佳选择。其他服务可能需要NoSQL数据库，例如MongoDB，它擅长存储复杂的非结构化数据，或Neo4J，用于高效存储和查询图形数据。

结论

使用由多个服务共享的（单个）数据库。每个服务使用本地ACID事务自由访问其他服务拥有的数据。

例子

OrderService和CustomerService可以自由访问彼此的表。例如，OrderService可以使用以下ACID交易，确保新订单不会违反客户的信用额度。

BEGIN TRANSACTION
…
SELECT ORDER_TOTAL
 FROM ORDERS WHERE CUSTOMER_ID = ?
…
SELECT CREDIT_LIMIT
FROM CUSTOMERS WHERE CUSTOMER_ID = ?
…
INSERT INTO ORDERS …
…
COMMIT TRANSACTION

即使同时交易试图为同一客户创建订单，数据库也将保证不会超过信用额度。

结果上下文

这种模式的好处是：

开发人员使用熟悉且直接的ACID事务来强制数据一致性
单个数据库操作起来更简单

这种模式的缺点是：

开发时间耦合 - 例如，处理OrderService的开发人员需要与访问相同表的其他服务的开发人员协调模式更改。这种耦合和额外的协调将减缓发展。
运行时耦合 - 因为所有服务都访问同一个数据库，所以它们可能会相互干扰。例如，如果长时间运行的CustomerService事务在ORDER表上保持锁定，则OrderService将被阻止。
单个数据库可能无法满足所有服务的数据存储和访问要求。