如何实现可复制的子 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 服务收到请求并且链接是这三个之一，它会决定哪个其他 服务来满足请求。所以这样一来，它的行为就很像另一个 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 是相同 pod（容器）的一些副本，因此它将管理我图中的 service-1-a、-b、-c。 Service 提供负载均衡器（其默认 ClusterIP 类型提供仅在集群内可访问的负载均衡器）以及 DNS 名称。您可能会使用环境变量 SERVICE_1_URL=http://service-1.default.svc.cluster.local/graphql 配置您的爬虫管理器 pod，以将所有内容连接在一起。

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

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

---

从架构上看，您所展示的似乎还不错。对我来说最大的“如果”是您已经设计了它，以便您正在抓取的每个站点都可能获得多个独立的抓取容器和不同的代码库。如果这在您的场景中确实合理，那么以这种方式拆分服务是有意义的，并且拥有“第二个路由服务”并不是真正的问题。