什么是 API 网关？聊聊架构

为了提高系统的性能和可靠性，将应用服务进行拆分微服务化。作为系统入口的 API 网关也逐渐成为了标配。

今天我们一起来看看 API 网关的设计思路，需要承载了哪些功能？以及如何选择流行的 API 网关？

什么是 API 网关

既然需要 API 网关为我所用，首先就让我们来了解一下什么是 API 网关。

什么是 API 网关

网关一词最早出现在网络设备，比如两个相互独立的局域网之间通过路由器进行通信，中间的路由被称之为网关。

任何一个应用系统如果需要被其他系统调用，就需要暴露 API，这些 API 代表着一个一个的功能点。

如果两个系统中间通信，在系统之间加上一个中介者协助 API 的调用，这个中介者就是 API 网关。

对接两个系统的 API 网关

当然，API 网关可以放在两个系统之间，同时也可以放在客户端与服务端之间。

对接客户端和服务端的 API 网关

知道了 API 网关的基本定义，再来看看为什么我们要使用它。

为何要使用 API 网关

网关作为系统的唯一入口，也就是说，进入系统的所有请求都需要经过 API 网关。

当系统外部的应用或者客户端访问系统的时候，都会遇到这样的情况：

系统要判断它们的权限

如果传输协议不一致，需要对协议进行转换

如果调用水平扩展的服务，需要做负载均衡

一旦请求流量超出系统承受的范围，需要做限流操作

针对每个请求以及回复，系统会记录响应的日志

也就是说，只要是涉及到对系统的请求，并且能够从业务中抽离出来的功能，都有可能在网关上实现。

例如：协议转换，负载均衡，请求路由，流量控制等等。后面我们会一一给大家介绍这些功能。

在了解 API 网关有哪些基本功能以后，来看看它可以服务于哪些系统或者客户端。

API 网关服务定位

API 网关拥有处理请求的能力，从定位来看分为 5 类：

面向 WebApp，这部分的系统以网站和 H5 应用为主。通过前后端分离的设计，将大部分的业务功能都放在了后端，前面的 Web App 只展示页面的内容。

MobileApp，这里的 Mobile 指的是 iOS 和 Android，设计思路和 WebApp 基本相同。

区别是 API 网关需要做一些移动设备管理的工作（MDM）。例如：设备的注册，激活，使用，淘汰等，全生命周期的管理。

由于移动设备的特殊性，导致了我们在考虑移动设备请求的时候，需要考虑请求，设备，使用者之间的关系。

面向合作伙伴的 OpenAPI，通常系统会给合作伙伴提供接口。这些接口会全部开放或者部分开发，在有条件限制（时间，流量）的情况下给合作伙伴访问。因此需要更多考虑 API 网关的流量和安全以及协议转换的管理。

企业内部可扩展 API，给企业内部的其他部门或者项目使用，也可以作为中台输出的一部分，支持其他系统。这里需要更多地考虑划分功能边界，认证和授权问题。

面向 IOT 设备，会接收来自 IOT 设备的请求，特别是工业传感器等设备。这里需要考虑协议转换和数据过滤。

API 网关架构

既然谈了 API 网关的功能和定位，接下来说说它的架构：

API 网关系统架构图

API 网关拆分成为 3 个系统：

Gateway-Core（核心）

Gateway-Admin（管理）

Gateway-Monitor（监控）

Gateway-Core 核心网关，负责接收客户端请求，调度、加载和执行组件，将请求路由到上游服务端，并处理其返回的结果。

大多数的功能都在这一层完成，例如：验证，鉴权，负载均衡，协议转换，服务路由，数据缓存。如果没有其他两个子系统，它也是可以单独运行的。

Gateway-Admin 网关管理界面，可以进行 API、组件等系统基础信息的配置；例如：限流的策略，缓存配置，告警设置。

Gateway-Monitor 监控日志、生成各种运维管理报表、自动告警等；管理和监控系统主要是为核心系统服务的，起到支撑的作用。

hello，我是御风，很高兴在这里与你相遇。我是一名程序员，也是一名B站UP主。我乐于分享，勤于学习。希望我们共同成长。永远相信梦想的力量