微服务应该调用自身还是调用内部函数答案

【问题标题】：Should a microservice call itself or call an internal function微服务应该调用自身还是调用内部函数
【发布时间】：2022-01-25 05:00:53
【问题描述】：

我正在为我的公司处理一个旧项目，我发现了一个奇怪的代码实践。

我们有多个 API：

Account/CustomerInformations => Should return all information
Account/CustomerName => Return just name
Account/CustomerPhone => return just phone

在函数CustomerInformations() 的代码中，他们正在调用同一服务的其他API（微服务正在调用自己）（Account/CustomerName，Account/CustomerPhone），我觉得这很奇怪，因为我认为它不是一个很好的做法。

询问了架构师后，他给出的理由是，这是通过负载均衡器，让调用更快的唯一理由。

我认为我们应该调用一个Task来完成这项工作，而不是自己调用微服务。

在这种情况下最好的做法是什么？

【问题讨论】：

无需调用其他端点。 CostumerInformations 服务必须实现自己的逻辑来获取所有必需的信息，而不是依赖于其他两个微服务，因为其他微服务只有特定的功能和特定的目的。如果数据来自数据库或调用特定的其他微服务端点（不是您的服务端点），请编写您自己的查询获取数据。

标签： api rest asp.net-core microservices

【解决方案1】：

这看起来很简单。该 pull-all 函数需要重构以一次性从数据库中提取所有数据，如果需要，使用分页，而不是将其卸载到同一函数中的其他端点。每次该服务调用自己时，它都会浪费时间在您的网络路径中旅行，增加延迟并增加成本。如果你的架构师认为“通过负载均衡器”会使其更快，那他就是个白痴——它会让懒惰而不是正确地实现这一点变得更容易

【讨论】：

他这样解释他的选择：“服务器我正忙于提取数据，...对于第一个需求，因此通过调用负载均衡器，我们确信我们可以调用另一个什么都不做的服务器。”他的想法是调用另一台服务器比调用同一台服务器中的函数要好。他在做同样的事情，其他功能执行更复杂的工作，比如账户余额计算等......

【解决方案2】：

表结构是什么样的？如果所有信息都驻留在同一个表中，那么使用内部 API 可能会很好。可能会缺少一些信息，您可能想检查是否有某种方法可以引入 LocalOptimization 或已经在代码中，这些方法可以巧妙地识别是调用内部 API 还是调用外部 API。只是假设，但小代码重构在这里应该有所帮助。

【讨论】：

【解决方案3】：

据我了解，目前不将内容保留在内部的原因是为了缓解潜在的性能问题。如果过去确实存在性能问题，那么将事情保持在内部可能不是可行的方法，实际上可能会导致服务性能下降。

您可以选择将 CustomerInformation 拆分为它自己的微服务，这实际上会以几乎相同的方式拆分对 CustomerName 和 CustomerPhone 的调用，但不需要调用“它自己”。

【讨论】：