假设您正在使用带有Docker容器和Kubernetes的微服务。
如果您在微服务前使用API网关（例如Azure API网关）来处理复合UI和身份验证，您是否仍需要Service Mesh来处理服务发现和断路器？ Azure API Gateway中是否有任何功能可以应对这些挑战？怎么样？
API网关仅处理进入Kubernetes集群的入口点，例如它向您的前端微服务发送请求。但是，在请求进入群集后，它无法执行任何操作。微服务之间可能仍有多个调用。您仍然希望验证这些请求的身份验证，您仍然希望确保服务之间存在断路器等。理论上，您可以确保所有微服务通过API网关相互呼叫，但我不认为这就是你想要的。
简而言之：不，因为API网关只是一个入口点，所以使用Service Mesh可以更好地处理任何服务通信服务。
API网关应用于OSI模型的第7层，或者您可以说管理来自外部网络的流量（有时也称为北/南流量），而Service Mesh应用于OSI模型的第4层或管理器服务间通信（有时也被称为东/西交通）。 API网关功能的一些示例包括反向代理，负载平衡，身份验证和授权，IP列表，速率限制等。
另一方面，Service Mesh的工作方式类似于代理或侧车模式，它解除了服务的通信责任，并处理其他问题，如断路器，超时，重试，服务发现等。
如果您碰巧使用Kubernetes和Microservices，那么您可能想要探索其他解决方案，例如Ambassador + Istio或Kong，它们可用作Gateway和Service Mesh。
您可以使用API网关来处理服务发现和断路器 - 但这将使其成为您部署的中心点，即所有外部和内部呼叫都必须通过网关进行路由。
服务网格在每个服务旁边部署一个额外的边缘组件（“sidecar”），使整个行为分布（但也更复杂）
根据您的特定要求，您可以使用一个，另一个，两个或不使用
很好地解释了上面的fatcook ..请参阅Azure-Frontdoor
因为这试图和Azure上的Kong一样。 API网关+处理控制平面级功能