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

Question

假设您正在将微服务与 Docker 容器和 Kubernetes 结合使用。

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

Answer 1

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

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

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

Answer 2

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

简而言之：不，因为 API 网关只是一个入口点，任何服务到服务的通信都可以通过服务网格更好地处理。