API 网关和服务网格功能定位比较

2020年2月8日 | 由 helight | 1300字 | 阅读大约需要3分钟 | 归档于 sevicemesh | 标签 #istio #microservices

上一篇文章介绍了服务网格和 API 网关的使用场景和如何配合使用,这篇文章继续介绍,再把服务网格和 API 网关的区别和应用场景进行挖掘。

为了进一步区分 API 网关和服务网格,需要在功能定义上看这两个组件的关键功能特点。

API 网关:目标是通过管理 API 来把你内部服务的能力以 API 的方式暴露给集群外的使用者

这是 API 网关最关键的能力,就是通过管理方式(一般会有相应的管理平台或者系统)把集群的的服务或是微服务的能力代理给外部使用者使用。所以在这一层我们开发或者封装的一般是产品级别的 API,是内部想对外部提供的服务能力的 API。在这一层我们开发或者封装的 API 或者是边缘服务,以这种方式对外提供服务。

  • API/边缘服务调用下游(复合和原子)服务或者微服务的API,一次来对下游多个服务的业务功能进行组合或者封装。
  • API/边缘服务还需要以弹性的方式调用下游服务,并且要用多种策略,比如熔断使用,超时控制,均衡负载和故障保护等。所以大多数的 API 网关都内置了这些功能了。
  • API 网关也内置了服务发现,安全防护和一些基本的分析功能(比如:度量,监控,分布式日志,分布式追踪等)。
  • API 网关还有一个能力是和 API 管理生态系统中的组件进行紧密合作,比如 API 测试,API 市场,API Doc,API 门户等。

以上这些也是我们在构建内部微服务体系过程中的一些积累,在以平台化的方式提供服务能力的时候,API 的管理能力尤为重要。

服务网格

再来看看服务网格的特点和定位。

  • 服务网格是一个基础设施,目标是解决服务之间的可靠可信的网络通信,使得应用程序不在考虑这方面的功能,而专注在业务逻辑的开发上。
  • 在处理服务和服务之间的网络通信的时候,就不需要再实现这些逻辑(比如:熔断,超时控制等)。服务网格也提供一些其它能力比如服务发现,服务追踪,度量,监控等等。
  • 服务网格剥离了网络通信能力和业务逻辑,所以在业务逻辑部分的开发可以真正实现多语言,多框架支持。

API 网关和服务网格实践

从上面可以看出来,API 网关和服务网格之间最关键的区别就是:API 网关的主要功能是暴露内部服务能力给外部,而服务网格主要解决的是内部服务之间的基础网络通信问题,服务网格这里不涉及业务逻辑。

下图是一个服务体系同时都有 API 网关和服务网格。就如我们上篇文章讨论过的,它们还是有一定功能重复(比如熔断,超时等),但是理解这两个解决方式解决的问题是从根本上不一样的,也就是它们存在的意义和目标是不一样的。

如上图所示,服务网格主要是一个 sidecar 的方式存在,它和业务逻辑服务是独立的模块或者说进程。从另一方面说,API 网关把关着所有对外的 API 功能(这些功能都是定义在每个业务逻辑模块中的),并且 API 网关是业务解决方案的一部分。API 网关可能内置了内部服务通信能力,但是也不能妨碍 API 网关继续使用服务网格的能力去调用下游服务,基本过程是:API 网关->服务网格的sidecar->业务服务。

在 API 调用过程实现上,你可以使用 API 网关的内置内部通信能力,或者 API 网关通过服务网格再调用下游服务。