微服务架构系列 - 框架篇：Go Micro 中的 API 网关底层实现原理（上）

Monday. December 30, 2019 - 1 min

微服务架构系列（十）

前面我们介绍过，Go Micro 框架可以通过 API 网关方式对外提供统一接口，以便客户端可以通过 HTTP 方式请求网关背后的微服务。接下来，我们通过源码来探究 Go Micro 中的 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 网关（例如每种客户端应用外形规格一个网关），而这就是我们下面要介绍的 Backends for frontends 网关。

2、Backends for frontends 网关

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

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