Question

我们最近开始将一个巨大的整体分成微服务。我们遇到的挑战之一是解析外键的方式和位置。

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

PriceQuote服务，主要负责根据变体和城市管理价格

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的位置引用？微服务内部还是外部？如果在微服务之外？其中吗

Answer 1

粒度对我来说很好（隔离）。我无法在同一服务中看到位置管理和报价。仅仅因为表指向具有外键的其他人并不意味着它们应该由相同的服务管理。因此，就分解而言，这对我来说是好的。

我不确定你的意思＆＃34;解决＆＃34;并且没有关于问题域的详细信息，但是您是否不会使用已知位置和/或变体的价格报价服务？还要记住，我们已经过了很好的规范化趋势＆＃34;。为了方便起见，复制一些小数据元素是可行的，因为权衡是隔离与服务到服务运行时的依赖关系。空间很便宜。例如，当价格报价执行其初始插入时，还要添加＆＃34;名称＆＃34;字段以及＆＃34; id＆＃34;你应该真的需要CarData吗？如果PriceQuote服务在插入期间没有名称，而是使其基于事件并异步更新。

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

1 个答案: