在微服务架构中如何以及在何处解析外键

Posted 2023-03-08

【中文标题】在微服务架构中如何以及在何处解析外键

【英文标题】：How and where to resolve foreign key in microservice architecture

【发布时间】：2018-01-04 10:01:43

【问题描述】：

我们最近开始将一个大型单体应用拆分为微服务。我们遇到的挑战之一是如何以及在何处解析外键。

为了给你一个更好的视角。我们计划构建以下微服务。这些服务中的每一个都有自己的专用数据库，以使服务独立。

PriceQuote Service，主要负责管理基于变量和城市的价格

PriceQuote
-----------------------   
id(Pk)
veriant_id(Fk)
city_id(Fk)
price

CarData 服务，这个微服务包含三个关注点。品牌、型号、变体

Variants
-----------------------
id(Pk)
model_id(fk)
name

定位服务、州、城市和地区都包含在单个微服务中

Cities
-----------------------
id(Pk)
state_id(fk)
name

请帮我解决以下问题

这是设计微服务的正确方式吗？

在检索价格时在哪里解析 variant_id 和 city_id Fks 引用？微服务内部还是外部？如果在微服务之外？在哪里？

【问题讨论】：

微服务应该独立于这些依赖。我猜你必须重新定义你的服务层。请通过this了解微服务领域的设计。

这似乎被过度隔离了。

【参考方案1】：

粒度对我来说看起来不错（隔离方面）。我看不到将位置管理和报价放在同一个服务中。仅仅因为表指向其他具有外键的表并不意味着它们应该由相同的服务管理。所以就分解而言，这对我来说看起来不错。

我不确定您所说的“解决”是什么意思，也没有关于问题域的详细信息，但是您是否会在已经知道位置和/或变体的情况下使用报价服务？还要记住，我们已经过了“大标准化趋势”。当权衡是隔离与服务到服务的运行时依赖关系时，为了方便起见复制一些小数据元素是可以的。空间很便宜。例如，当报价进行初始插入时，如果您确实需要，它还添加“名称”字段以及 CarData 的“id”。如果在插入期间 PriceQuote 服务手头没有名称，请改为基于事件并异步更新它。

【讨论】：

我看到了非规范化的潜在负面影响。 CarData 和 Location 服务都是一种主数据。许多服务将依赖这些服务。每当发生任何变化时，跨微服务对其进行更新将是一项乏味的工作。

服务自己的数据负责侦听需要更新或插入所需的复制数据的事件。在十几个或更多服务中实现这种能力并不是什么大不了的事。但是，如果数量巨大并且复制的数据很大和/或复杂，那么也许是时候重新审视域边界了。这可能有用：The Hardest Part About Microservices: Your Data