我应该使用 API 网关还是服务网格？答案

【问题标题】：Should I use an API Gateway or Service Mesh?我应该使用 API 网关还是服务网格？
【发布时间】：2019-08-28 02:17:06
【问题描述】：

假设您正在使用带有 Docker 容器和 Kubernetes 的微服务。

如果您在微服务前使用 API 网关（例如 Azure API 网关）来处理复合 UI 和身份验证，是否还需要服务网格来处理服务发现和断路器？ Azure API Gateway 中是否有任何功能可以应对这些挑战？如何？

【问题讨论】：

标签： kubernetes microservices istio api-gateway

【解决方案1】：

API 网关仅处理 Kubernetes 集群的入口点，例如它向您的前端微服务发送请求。但是，在请求进入您的集群后，它什么也做不了。微服务之间可能仍然存在多个调用。您仍然希望验证这些请求的身份验证，您仍然希望确保服务之间存在断路器等。理论上，您可以确保所有微服务通过 API 网关相互调用，但我不认为这就是你想要的。

简而言之：不，因为 API 网关只是一个入口点，所以任何服务到服务的通信都最好使用服务网格来处理。

【讨论】：

谢谢Blokje5，在我接受你的回答之前，我需要确认一下，为什么API网关供应商必须说你甚至可以使用API网关进行服务发现和断路器等？跨度>

【解决方案2】：

您可以使用 API 网关来处理服务发现和断路器 - 但这会使它成为您部署的中心点，即所有外部和内部调用都必须通过网关进行路由。

服务网格在每个服务旁边部署一个额外的边缘组件（“sidecar”），使整体行为分散（但也更复杂）

根据您的特定要求，您可以使用一种、另一种、两者兼有或不使用

【讨论】：

【解决方案3】：

API 网关应用于 OSI 模型的第 7 层，或者您可以说管理来自外部网络的流量（有时也称为北/南流量），而服务网格应用于 OSI 模型的第 4 层或管理器间服务通信（有时也称为东/西流量）。 API 网关功能的一些示例包括反向代理、负载平衡、身份验证和授权、IP 列表、速率限制等。

另一方面，Service Mesh 像代理或边车模式一样工作，将服务的通信责任解耦并处理其他问题，例如断路器、超时、重试、服务发现等。

如果您碰巧使用 Kubernetes 和微服务，那么您可能想要探索其他解决方案，例如 Ambassador + Istio 或 Kong，它们既可以用作网关，也可以用作服务网格。

【讨论】：

谢谢，胖子。我们将使用 Azure API 管理作为 API 网关和 AKS 与 Istio 来处理断路器和服务发现。

【解决方案4】：

上面的 fatcook 很好地解释了.. 见Azure-Frontdoor

因为这是尝试在 Azure 上做与 Kong 相同的事情。 API 网关 + 处理控制平面级功能

【讨论】：