api 网关模式微服务 - 本地开发答案

【问题标题】：api gateway pattern microservices - local developmentapi 网关模式微服务 - 本地开发
【发布时间】：2022-02-04 02:21:08
【问题描述】：

我的问题是关于将 API 网关模式与微服务结合使用，因为它与单个开发人员机器上的本地开发有关。

我们有一个小型微服务架构设置，其中包含一个 API 网关（我们使用的是 Envoy，但正在转向 NGINX），网关后面有一个微服务（很快就会有更多的微服务）。

这是一个非常基本的微服务环境，我们用来测试我们的微服务架构，包括我们的 API 网关和 K8s 部署到 QA。

API 网关和微服务被容器化到 docker 容器中，并立即在使用 docker compose 的本地开发机器 (visual studio/c#) 上启动。

当我们在本地 docker compose 时，我们会同时启动 api 网关和位于网关后面的微服务。然后，在我们的本地开发机器上，我们通过 api 网关容器测试调用，以便开发人员可以验证 api 网关是否配置正确，并按预期通过位于其后面的微服务流动流量。

我们很好奇（这是问题所在），如果其他使用 API 网关模式的开发团队通常在开发机器上开发时在本地启动 api 网关，并在将容器推送到 QA 环境之前在其本地机器上测试网关。

我们认为 NGINX API 网关将直接部署到我们希望在 QA/Prod 环境中运行的 Kubernetes 中，并且我们认为本地开发人员通过 API 网关对流量进行测试会在部署到 QA 中的 K8s 之前有所帮助.

然而，NGINX 似乎有一个在 Kubernetes 中使用的单独入口控制器映像，并且 API 网关的配置似乎与 NGInX 入口控制器的配置不匹配。因此，我们正在猜测自己是否在开发时在我们的开发机器上本地启动 API 网关是否有益。我们想听听其他团队的做法。

【问题讨论】：

【解决方案1】：

当您的网关在远程机器上运行时难以调试时，在本地运行它是一种好方法。

我认为，要获得良好的分布式开发人员体验，必须有一个好的工具来记录和验证所有 api 网关路由及其行为。

没有它可能会很痛苦。本地调试可能缺少一些真实的基础架构场景。在生产中发现它不是一种选择:)

【讨论】：

穆里洛，感谢您的回复。好资料。似乎 kubernetes 场景中的网关将被入口控制器取代。本质上，入口控制器将兼作 api 网关。 INGNX 有一个入口控制器和一个可用的 api 网关。看起来也许我们应该只使用 QA 环境中的入口控制器作为我们的第一个位置来测试到我们的微服务的路由。

【解决方案2】：

除了 Kubernetes 部分，NGINX Ingress 控制器通常用于处理 Kubernetes 中的大多数 API 网关用例。但是在某些情况下，当 Ingress 控制器和 API 网关都可以使用时，这里有一些有用的信息：https://www.nginx.com/blog/how-do-i-choose-api-gateway-vs-ingress-controller-vs-service-mesh/

【讨论】：