微服务架构中如何以及在哪里解决外键
我们最近开始将一个巨大的整体拆分为微服务。我们遇到的挑战之一是如何以及在哪里解析外键。
给你一个更好的视角。我们正计划构建以下微服务。这些服务中的每一个都有自己的专用数据库，以便使服务独立。
价格报价服务，主要负责管理基于变量和城市的价格
PriceQuote
-----------------------
id(Pk)
veriant_id(Fk)
city_id(Fk)
price
CarData Service，此微服务中存在三个问题。品牌、型号、变型
Variants
-----------------------
id(Pk)
model_id(fk)
name
位置服务、州、城市和区域集中在单个微服务中
Cities
-----------------------
id(Pk)
state_id(fk)
name
请帮助我解决以下问题
>
这是设计微服务的正确方法吗？
在哪里解决variant_id和city_idFks，而检索价格
报价？内部还是外部微服务？。如果外部微服务？哪里？
共有1个答案
粒度对我来说看起来很好(隔离方面)。我看不出把位置管理和价格报价放在同一个服务中。仅仅因为表使用外键指向其他表并不意味着它们应该由同一个服务管理。就分解而言，我觉得这没问题。
我不确定你所说的“解决”是什么意思，也没有关于问题域的详细信息，但是，在已经知道位置和/或变型的情况下，你不会使用报价服务吗？还要记住，我们已经过了“伟大的正常化趋势”。为了方便起见，复制一些小的数据元素是可以的，因为隔离与服务到服务的运行时依赖性之间存在权衡。空间很便宜。例如，当报价单进行初始插入时，如果您确实需要，请让它添加“名称”字段以及CarData的“id”。如果在插入过程中PriceQuote服务手头没有名称，请将其设置为基于事件并异步更新。
-
null 最终产品将是，它将具有图像、描述、评分（满分为5分）和许多评论。 在微服务架构中，应该在什么位置组合多个微服务的响应？ 大约1： MVC/REST API接近APIGateway API网关对所有微服务进行异步调用 响应将返回到MVC/WebAPI。在这里可以执行响应的合成。 大约2： MVC/REST API接近Apigateway API网关对产品微服务进行异步调用。 Product
-
我读了一些文章，看了一些视频，但在为这些微服务提供服务方面，没有找到具体的建议。我的理解是，他们应该使用自己的应用程序服务器。 我的问题是它们应该部署在不同的服务器上，还是没关系。 当它们在同一台服务器（计算机）上提供服务时，不会有端口冲突吗？
-
本文向大家介绍详解Java 微服务架构，包括了详解Java 微服务架构的使用技巧和注意事项，需要的朋友参考一下 一、传统的整体式架构 传统的整体式架构都是模块化的设计逻辑，如展示（Views）、应用程序逻辑（Controller）、业务逻辑（Service）和数据访问对象（Dao），程序在编写完成后被打包部署为一个具体的应用。如图所示： 系统的水平扩展 如果要对系统进行水平扩展，通常情况下，只需要
-
Kubernetes 设计之初就是按照 Cloud Native 的理念设计的，Cloud Native 中有个重要概念就是微服务的架构设计，当将单体应用拆分微服务后， 随着服务数量的增多，如何微服务进行管理以保证服务的 SLA 呢？为了从架构层面上解决这个问题，解放程序员的创造性，避免繁琐的服务发现、监控、分布式追踪等事务，Service mesh 应运而生。 微服务 下图是Bilgin Ibr
-
我试图了解GraphQL最适合在微服务架构中使用的地方。 关于只有一个GraphQL模式作为API网关，将请求代理给目标微服务并强制它们的响应，存在一些争论。微服务仍然会使用REST/Trift协议进行通信。 另一种方法是拥有多个GraphQL模式，每个微服务一个。有一个较小的API网关服务器，它将请求路由到目标微服务，并带有请求的所有信息+GraphQL查询。 第一种方法 将1个GraphQL模
-
本文向大家介绍微服务哪些框架相关面试题，主要包含被问及微服务哪些框架时的应答技巧和注意事项，需要的朋友参考一下 Dubbo，是阿里巴巴服务化治理的核心框架，并被广泛应用于阿里巴巴集团的各成员站点。阿里巴巴近几年对开源社区的贡献不论在国内还是国外都是引人注目的，比如：JStorm 捐赠给 Apache 并加入 Apache 基金会等，为中国互联网人争足了面子，使得阿里巴巴在国人眼里已经从电商升级为一