微服务中的 API 网关模式概述

前面我们介绍过,Go Micro 框架可以通过 API 网关方式对外提供统一接口,以便客户端可以通过 HTTP 方式请求网关背后的微服务。接下来,我们通过源码来探究 Go Micro 中的 API 网关是如何实现的,不过在此之前,有必要先给大家系统介绍下 API 网关模式。

为什么需要 API 网关

首先,我们要了解为什么需要 API 网关。

如果不使用 API 网关,采用客户端与微服务直接通信的话,对应的架构图是这样的:

API 网关架构图

但是这种模式存在以下这些问题:

  • 客户端应用通常需要使用来自多个微服务的功能,直接通信则需要处理对多个微服务的调用,不同微服务可以使用的是不同的协议,需要客户端分别进行处理;
  • 会将客户端与微服务的地址、端口耦合起来,如果微服务地址和端口动态变化,维护起来非常棘手;
  • 后台微服务通常提供的是细粒度的 API,直接通过客户端调用会造成多次请求往返才能组合出所需要的结果,增加了网络延迟;
  • 所有后台微服务地址和端口等细节信息直接暴露在外部服务中,存在安全隐患;
  • 诸如访问授权、数据转换、动态请求调度之类的通用功能整合,分散到客户端处理难以维护;
  • 不同的客户端可能需要的数据不同,对网络性能的要求也不一样,如果直接通信的话无法区分处理。

而使用 API 网关模式则可以很好的解决上述提到的问题。

什么是 API 网关

下面我们来看下什么是 API 网关模式。

API 网关是一个反向代理服务器,将请求从客户端路由到后台微服务,是访问微服务的唯一入口,它封装了系统内部架构,为每个客户端提供一个定制的 API,此外,它可能还具备其它职责,如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理等。

API 网关模式的核心要点是,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能,通常,网关会提供 HTTP API,有时,我们也可以将其称作「用于前端的后端」。

Chris Richardson 在他的博客中把 API 网关划分为以下两种:

  • 单节点 API 网关
  • Backends for frontends 网关

1、单节点网关

顾名思义,所有客户端(浏览器、移动 App、H5应用等)通过同一个 API 网关节点访问后台微服务,对应架构图如下所示:

API 网关架构图

这种架构方式存在一定风险,因为 API 网关会随着客户端应用的需求增长而不断膨胀,因此,在复杂的微服务体系中,建议将 API 网关拆分成多个服务或多个更小的 API 网关(例如每种客户端应用外形规格一个网关),而这就是我们下面要介绍的 Backends for frontends 网关。

2、Backends for frontends 网关

这种模式是针对不同的客户端来实现一个不同的 API 网关,也就是「用于前端的后端」(Backends for frontends,检查 BFF)模式,对应的架构图如下:

API 网关架构图

下一篇我们将以 Micro API 为例,介绍 Go Micro 框架中 API 网关的底层实现。

上一篇: 基于 Consul 的 Go Micro 客户端服务发现是如何实现的

下一篇: Go Micro 中的 API 网关实现 —— Micro API 底层源码剖析(上)