Service Mesh vs API Gateway,用途特征大相径庭?
2018-04-12

作者:Kasun Indrasiri

翻译:赵化冰(博客链接:http://zhaohuabing.com/)

原文:Service Mesh vs API Gateway

地址:https://medium.com/microservices-in-practice/service-mesh-vs-api-gateway-a6d814b9bf56



在我前一篇关于 Service Mesh 的文章中(注1)有几个关于 Service Mesh 和 API Gateway 之间关系的问题。因此在我打算在本篇文章中讨论 Service Mesh 和 API Gateway 的用途。

为了区分 API Gateway 和 Service Mesh,让我们先分别看看两者的主要特征。


API Gateway:将你的服务作为被管理的API暴露给外部系统

使用 API Gateway 的主要目的是将你的微服务作为被管理的 API 暴露给外部系统。因此,我们在 API Gateway 层开发的 API 或者边界服务对外提供了业务功能。

  • API/Edge 服务调用下游微服务,通过组合/混装多个下游微服务形成业务逻辑。

  • API/Edge 服务需要以一种可靠的方式调用下游服务,因此需要应用断路器,超时,负载均衡/故障转移等可靠性模式。因此大部分的 API Gateway解决方案都内置了这些特性。

  • API Gateway 也需要内置对以下特性的支持,包括:服务发现,分析(可见性:性能指标,监控,分布式日志,分布式调用追踪) 和安全。

  • API Gateway 和 API 管理生态系统的其他这些组件的关系紧密,比如: API 市场/商店, API 发布门户。


Service Mesh

现在我们来看看Service Mesh有哪些不同。

  • Service Mesh是一个网络通信基础设施, 可以用于将网络功能从你的服务代码中剥离出来。

  • 采用 Service Mesh, 你不用在服务代码中实现用于可靠通信的模式如断路,超时等,类似地,Service Mesh 也提供了服务发现,服务可见性等其他功能。


API Gateway and Service Mesh实践

API Gateway 和 Service Mesh 之间的主要不同点在于 API Gateway 是暴露 API/Edge 服务的关键组件,而 Service Mesh 则仅仅是一个服务间通信的基础设施,并不了解你应用中的业务逻辑。

下图说明了 API Gateway 和 Service Mesh 的关系。如同我们上所说,他们之间也有一些重叠的部分(例如断路器等),但重要的是需要理解这两者是用于完全不同的用途。

图1: API Gateway和Service Mesh实践


如图所示,Service Mesh 作为 Sidecar 和服务一起部署,它是独立于服务的业务逻辑的。

另一方面,API Gateway host 了所有的 API 服务(这些API服务有明确定义的业务功能),它是你应用的业务逻辑的一部分。API Gateway 可以具有内建的服务间通信能力,但它也可以使用 Service Mesh 来调用下游服务。(API Gateway->Service Mesh->Microservices)。

在API管理层次,你可以使用API Gateway内建的服务间通信能力;也可以通过Service Mesh来调用下游服务,以将应用网络通信功能从应用程序转移到Service Mesh中。

译者按:

API Gateway 和 Service Mesh 的关系是我最近一直在思考的问题,也和同事及社区的朋友之间进行了一些讨论。这篇短文很清晰地总结了两者之间的相似之处以及这两者在微服务架构中的不同用途。

文章中提到 “可以使用API Gateway内建的服务间通信能力;也可以通过Service Mesh来调用下游服务”。在和同事讨论时,大家提到一个比较重要的考虑因素是在 API Gateway 处引入一个 Sidecar 可能带来的额外延迟。

API Gateway 作为微服务引用的流量入口,其对效率要求较高,如果随 API Gateway 部署一个 Sidecar,可能对效率有一定影响。

我对此未进行测试,但从理论上来说,服务发现,重试,断路等逻辑无论放到 API Gateway 还是 Service Mesh 中耗时应该是差不多的,部署 Sidecar 只是增加了创建一个本地链接的消耗,如下图所示:

将 API Gateway 和 Service Mesh 的功能进行清晰划分,API Gateway 负责应用逻辑,Service Mes h负责服务通讯,Metrics 收集等微服务基础设施,这样划分后在架构上更为清晰。对于效率问题,我们可以考虑对 API Gateway 进行水平扩展来解决。

注:

1、https://medium.com/microservices-in-practice/service-mesh-for-microservices-2953109a3c9a 



推荐阅读:

Service Mesh第三梯队,不可忽略的Nginmesh


Service Mesh深度思考 | DreamMesh抛砖引玉(3)-艰难的过渡

示例说明 | 想要正确使用Istio?这份sidecar说明书必不可少
Service Mesh深度思考 | DreamMesh抛砖引玉(3)-艰难的过渡

Service Mesh深度思考 | DreamMesh抛砖引玉(2)-CloudNativeService Mesh深度思考 | DreamMesh抛砖引玉(1)-序

Istio服务网格高级流量镜像,7种模式解决流量镜像难