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

Question

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

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

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

请帮我解决以下问题

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

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

Answer 1

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

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