如何实现可复制的子API网关？

Question

前言

我目前正在尝试学习微服务如何工作以及如何实现容器复制和API网关。不过，我遇到了障碍。

我的应用程序

我为应用程序提供了三项主要服务。

1. API网关
2. 履带管理器
3. 用户

针对此问题，我将专注于API Gateway和Crawler Manager服务。

API网关

这是运行Go服务器的Docker容器。通讯全部通过GraphQL完成。

我正在使用API​​网关，因为我希望应用程序中具有不同的服务，每个服务都有自己的专用API。这是为了统一一切。

它所做的只是代理请求到其适当的服务，然后将响应返回给客户端。

爬网管理器

这是另一个运行Go服务器的docker容器。通信是通过GraphQL完成的。

或多或少，其行为类似于另一个API网关。让我解释一下。

此服务希望客户端发送如下请求：

{
   # In production 'url' will be encoded in base64
   example(url: "https://apple.example/") {
      test
   }
}

url只能链接到以下三个站点之一：

• https://apple.example/
• https://peach.example/
• https://mango.example/

严格禁止其他任何网站。

一旦Crawler Manager服务接收到请求，并且链接是这三个链接之一，它将确定要满足请求的 other 服务。因此，它的行为与另一个API网关非常相似，但具有特殊性。

每个URL域都有自己的专用服务来对其进行处理。为什么？因为每个站点的标记相差很大，并且每个站点都需要进行爬网以获取信息。因为它们的标记是多种多样的，所以我想为他们每个人提供服务，以防万一网站被更新，整个Crawler Manager服务不会崩溃。

就查询而言，每个站点都将返回与其他站点格式相同的响应。

视觉轮廓

问题

现在，我们对我的应用程序的工作方式有了一些了解，我想在这里讨论我的实际问题。

1. 是否具有辅助API网关标准和良好实践？有更好的方法吗？
2. 如何复制该系统并具有多个Crawler Manager 服务家族实例？

我对如何实际创建此设置感到非常困惑。我看了看Docker Swarm / Kubernetes中的集群，但是用我设置的方式看来，我需要创建集群。这使我总体上质疑我的设计。也许我不必考虑让它们保持结构化？

Answer 1

在非常普通的级别上，如果服务A调用具有多个副本B1，B2，B3 ...的服务B，则它需要知道如何调用它们。这两个基本选项是拥有某种服务注册表，该服务注册表可以返回所有副本，然后选择一个副本，或者将负载均衡器放在第二个服务的前面，然后直接到达该副本。通常，设置负载平衡器要容易一些：服务调用可以是纯HTTP（GraphQL）调用，在开发环境中，您可以省略负载平衡器，而直接让一个服务调用另一个。

                                 /-> service-1-a
Crawler Manager --> Service 1 LB --> service-1-b
                                 \-> service-1-c

如果您愿意使用Kubernetes，它本质上具有对此模式的内置支持。 Deployment是相同吊舱（容器）的若干副本，因此它将管理我的图中的service-1-a，-b，-c。 Service提供了负载均衡器（默认的ClusterIP类型提供了只能在群集内访问的负载均衡器）以及DNS名称。您可能会为爬虫管理器窗格配置一个环境变量SERVICE_1_URL=http://service-1.default.svc.cluster.local/graphql，以将所有内容连接在一起。

（在您的原始图中，具有某个服务的多个副本的每个“框”将是一个Deployment，而在框顶部接收到入站连接的点将是一个Service。）

在普通Docker中，您需要做更多的工作来复制它，包括手动启动副本和负载平衡器。

---

从架构上看，您所显示的内容似乎不错。对我而言，最大的“如果”是，您已对其进行了设计，以使您要爬网的每个站点都可能获得多个独立的爬网容器和不同的代码库。如果这在您的情况下确实合理，那么以这种方式拆分服务是有道理的，拥有“第二路由服务”并不是问题。