微服务设计：一个调用还是两个单独的 API？ [关闭]答案

【问题标题】：Microservice design : one single call or two separate APIs? [closed]微服务设计：一个调用还是两个单独的 API？ [关闭]
【发布时间】：2020-02-25 13:51:13
【问题描述】：

我有一个执行以下逻辑的单片应用程序：

Get a list A (Customer) from database
Validate data in A using some criteria, if it's not validated, throw an error
Do some operations on A to get a list B (e.g. Regional customers)
Do sth with B

现在我正在使用微服务改造我的应用，但在设计调用时遇到了麻烦。

由于 B 可以完全从 A 推导出来，我只想创建一个返回所有数据集 A 的微服务 getCustomerA。这意味着需要单个数据库访问。这将是一个性能优势。

但问题是，在 A 上检索列表 B 的操作也是 业务代码的一部分。所以把这些代码放在客户微服务端更符合逻辑，如果我们遵循领域驱动设计，在微服务Customer，也许getRegionalCustomer。

所以我想知道，在这种情况下，最佳做法是什么？我们应该优先考虑单个数据库调用（第一种情况）还是最好进行两次调用（但在这种情况下，是 2 个数据库调用）？

【问题讨论】：

也许我在这里遗漏了一些细微差别，但我看到一个微服务在完成所有步骤（除了数据库，它当然是它自己的微服务）。
嗨，是的，也许我不清楚。验证必须在主应用端，因为它与其他域相关，我不能将其完全放在客户微服务中
想想你做的或将来可能做的所有用例。如果不先获得As就获得Bs没有意义，那么我认为您不需要将它们分开。但是，如果您想遵循 micro 服务的想法，那就拆分它们。对可以在单一应用程序中一次完成的事情进行多次调用可能看起来效率低下，但在我看来，简洁的设计更为重要。
从A得到B的逻辑是什么？也许你正在尝试做你的微服务太微了

标签： java api microservices

【解决方案1】：

由于这主要是基于意见，我只能告诉你:-)

根据我的经验，将应用程序拆分为微服务只是为了做到这一点，将技术教条置于技术简单性之上，并且经常引入大量不必要的开销。

关于数据库调用，我还可以根据经验告诉您，在执行两个简单的调用而不是执行一个过于复杂的调用时，您通常会赢得性能。特别是如果您开始在许多表上引入大连接或 - 哎哟 - 在 on 子句中进行子选择。

看看最简单的解决方案是否有效并保持代码整洁。不断提高质量并在需要时进行优化。如果你有一段逻辑需要被拆分成一个微服务（例如，因为你想使用不同的语言、框架或想卸载一些计算），那么就去做吧。

【讨论】：

【解决方案2】：

领域驱动设计并没有告诉每个边界上下文只能包含一个实体，实际上，当这些实体明确相关时，一个有界上下文（或微服务）可以包含多个实体，换句话说，当它们需要以事务方式持久化。

在您的情况下，由于两个实体之间的紧密关系，最好的方法是只构建一个执行这两种操作的微服务

【讨论】：