API网关或服务网格

Question

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

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

Answer 1

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

另一方面，

服务网格的工作原理类似于代理服务器或侧向车辆模式，它们可以取消服务的通信责任，并处理其他问题，例如断路器，超时，重试，服务发现等。 / p>

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

Answer 2

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

简而言之：否，因为API网关只是一个入口点，所以使用Service Mesh可以更好地处理任何服务之间的通信。

Answer 3

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

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

根据您的特定要求，您可以使用其中一个，另一个，或者都不使用

Answer 4

上面的fatcook做了很好的解释。请参阅Azure-Frontdoor

，因为这试图在Azure上执行与Kong相同的操作。 API网关+处理控制平面级别的功能