12、微服务架构中的数据处理与事务管理

微服务架构中的数据处理与事务管理

1. 打破外键关系示例

在这个示例中,目录代码使用通用订单项表来存储专辑信息,财务代码使用分类账表来跟踪财务交易。每月末,我们需要为组织内的不同人员生成报告,为了让报告更易读,财务包中的报告代码会从订单项表中提取SKU的标题信息。这可能还涉及从分类账到订单项表的外键约束。

为了解决这个问题,我们需要在两个方面进行更改:
- 停止让财务代码直接访问订单项表,因为该表属于目录代码。可以通过在目录包中提供一个API调用,让财务代码调用该API来获取数据。
- 这样做可能会导致生成报告时需要进行两次数据库调用,但我们需要考虑系统当前的性能以及所需的性能。有时候,为了其他方面的改进而牺牲一些性能是可以接受的。

同时,我们会失去外键关系,这就需要在生成的服务中管理这种约束,例如实现跨服务的一致性检查或触发清理相关数据的操作。这通常需要由定义系统行为的人员来决定。

2. 共享静态数据示例

数据库中存储共享静态数据(如国家代码)的情况很常见。对于音乐商店中所有潜在服务都从同一表读取数据的情况,我们有以下几种选择:
| 选项 | 描述 | 优缺点 |
| ---- | ---- | ---- |
| 复制表 | 为每个包复制该表,长期来看每个服务也会复制。 | 优点:数据在各服务中独立;缺点:存在数据一致性挑战。 |
| 作为代码处理 | 将共享静态数据作为代码,如存储在配置文件或枚举中。 | 优点:更新配置文件比修改数据库表更容易;缺点:数据一致性问题仍存在。 |
| 独立成服务 | 将静态数据推送到一个独立的服务中。 | 优点:适用于数据量、复杂度

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值