Question

我正在尝试启动一个微服务应用程序，但是我在某些技术上有些卡住。

我正在尝试构建一个问题跟踪器应用程序为例。

它具有2个数据库表，问题和注释。为了示例，这些也将是单独的微服务。

它必须是可以由多种类型的客户端使用的单独的API，例如手机，网络等。

在使用独占方法时，所有代码库都耦合在一起，并且在发出要求说REST API的请求时，我将处理例如'/ issues / 19'请求通过以下伪代码获取ID为'19'的问题及其相应的注释。

on_request_issue(id) # handler for the route '/issues/<id>'
    issue = IssuesModel.findById(id)
    issue.comments = CommentsModel.findByIssueId(id)
    return issue

但是我不确定如何使用微服务来解决这个问题。假设我们有微服务问题和微服务评论。

我可以让客户端向“ / issues / 19”和“ / comments / byissueid / 19”发送请求。但这在我看来并不好，因为如果我们有多件事我们正在为一页发送大量请求。

我还可以向微服务问题发出请求，因为它也向微服务评论发出请求，但是对我来说，这比上述情况还要糟糕，因为我读过微服务不应该耦合，这使它们很难耦合。

因此，我了解了API网关，它们可以/应该接收一个请求并扇出其他微服务，但是后来我真的无法弄清楚如何使用API网关。应该例如，我在其中编写代码以捕获“ / issues / 19”请求，然后同时扇动到微服务问题和微服务commetns，组装这些东西并返回它？在那种情况下，我感觉我的工作量加倍了，那么API网关会不会变成一个新的整体？

谢谢您的时间

Answer 1

API网关听起来像您所需要的。如果您将其保持简单，仅触发内部API，它将不会成为您的新手。

当您的应用程序随着新的微服务而增长时，或者当您必须支持不同的客户端（浏览器，移动应用程序，手表，物联网等）时，它将使您甚至可以进行更好的处理

顺便说一句，您展示的示例听起来像是一个很好的练习，实际上，对于大多数Web应用程序来说，它看起来像是过度设计。我不会中断对它自己的微服务的每个数据库调用。

Answer 2

将某项服务拆分为小型服务的动机之一是服务自主性，在这种情况下，问题是，当注释服务关闭时，您是否应该显示问题-如果它们始终总是耦合在一起，则可能不应该驻留在两个服务中，如果它们不在两个服务中，那么您将获得这种去耦功能

也就是说，您可能仍需要API网关来解决与客户的CORS问题

最后，comment / byissueid并不是一个好的REST接口，issueId应该是/ comments /？issueId = ..

微服务请求

2 个答案: