这不是一个讲概念的专栏，而且我也不擅长讲概念，每一篇文章都是一个故事，我希望你可以通过这些故事了解我当时在实际工作中遇到问题和背后的思考，架构设计是种经验，我有幸参与到多个亿级系统的架构设计中，有所收获的同时也希望把这些收获分享与大家。

2013年，我在做 APP 服务端的平台化转型，故事就从这里开始。

在最开始做网关时，我并没有一开始就明确说要做个 API 网关，而是做着做着发现这是个网关。因为当时我是在做服务端的平台化转型，最开始时只是提供了客户端登录、获取插件列表、插件启动授权几个简单的 API，其中客户端登录是通过 RSA 和 AES 非对称加密算法来实现，登录之后平台颁发 token 给客户端，有了 token 之后，客户端就通过 OAuth 2.0 协议来调用获取插件列表、插件启动授权等 API，不过由于最开始没想清楚，提供出去的 API 接口定义和格式不统一，虽然都是 json 格式，但几乎每个 API 都有自己的的格式定义，即每个 method 在服务端都实现了一个 Servlet 服务，客户端天天是要这接口要那接口，搞了上百个接口还是被客户端碾着走，更糟糕的是代码越来越臃肿还老出问题。

后来就想为何不把接口定义和格式统一了，就只提供一个 Serlvet 服务，通过解析 API 接口参数在后端进行服务的分发，这样至少可以减少每个 API 都写一遍 Servlet 的工作，当时的这个架构是 C/S 的架构，客户端通过公网访问弹内的服务器，这个功能上线其实是上线了一个新的 API，之后客户端的新功能都必须使用新的 API，老的 API 在客户端线上的版本逐步下线后，服务端再对老的 API 进行清理，当整个架构逐渐形成之后，服务端的开发效率得到了显著的提升，也是这时，我觉得这其实是个网关的雏形，所以整个平台演进的过程，在这一阶段我总结为：统一服务接口。

1。什么是网关？

现在来谈谈 API 网关，关于 API 网关的定义，有很多的说法，其字面意思就是系统的统一 API 入口。说白了，就是将客户端的所有请求统一通过 API 网关接入服务端，并完成认证、授权、安全、流控、熔断、调度、转发、监控等处理过程。API 网关的价值，就是为实现更加安全、高效和稳定的 API 调用提供服务保障。

就我当时负责的平台而言，统一了服务接口还不能说是做了一个网关，因为这仅仅是实现了网关统一接入组件的一个点，那网关的统一接入组件又是什么？下面我们先聊下网关的每一个组件，以及每一个组件的职责。

API 网关的核心组件

从 API 调用的过程来看，我把 API 网关划分为四个组件：

• 统一接入组件，管理所有的请求接入，负责认证鉴权、安全、校验、限流、降级和熔断等，它就像 API 网关的护城河；
• 服务调度组件，管理请求的路由和调度，负责协议解析、路由、转换、映射和服务编排等，它是外部请求调度后端服务的中间枢纽，也是 API 网关的大脑（只有大脑才知道哪个 API 应去哪里调度）；
• 服务发布组件，管理 API 的注册和订阅，负责服务发现、服务订阅和服务更新等，它是 API 网关的心脏（心脏会不断的把 API 信息同步给网关）；