前言
在介绍这个API网关的前言，首先可以问大家一个问题，平时大家新增一个服务或新增一个接口，是如何创建对外接口路由的？
若没有API网关，大家可能会通过新建域名，新增nginx配置来实现
一般而言，没有api-gateway，公司或多或少都会出现这样的情况弊
- 客户端到微服务直接通信，强耦合；
- 需要多次请求，客户端聚合数据，工作量巨大，延迟高；
- 协议不利于统一，各个部门间有差异，需要端来兼容；
- 面向端的 API 适配，耦合到了内部服务；
- 多终端兼容逻辑复杂，每个服务都需要处理；
- 统一逻辑无法收敛，比如安全认证、限流
因此，从以上这一个大背景来看，API网关在37手游内还是有必要
选型
对于主流API网关，我们做了以下调研和选型
其中，最著名的为KONG：
可以看到Kong解决的问题：专注于全局的Api管理策略，全局流量监控、日志记录、全局限流、黑白名单控制、接入请求到业务系统的负载均衡等。它是典型的流量网关
kong需要注意的问题
1，通过lua脚本来编写插件以达到扩展的目的
2，后续需要维护大量的lua脚本
最终，我们出于以下考虑，选择了自研
-
kong更多是一个流量网关，而如果我们要适配业务，可能需要许多业务上的定制，此时就需要开发维护大量的lua脚本，这对后续的维护是不利的。并且用开源组件，需要深入了解源码。
-
devops文化，开发需要对稳定性全面负责自研API网关可以让开发人员更好地了解API网关的工作原理，从而更好地负责其稳定性和维护。
-
适配现有技术栈成本更低 自研API网关可以更好地适配现有的技术栈和业务流程，从而提高工作效率和稳定性。 包括监控、日志、链路追踪、开发语言等
自研API网关如何设计？
设计可以分为以下这五步
现状分析
目前从37手游来看，整体的技术架构分析如下
- http/https协议：所有接口协议都已经统一
- golang：全面golang化、服务化
- 组件：内部已有现成组件实现监控、链路追踪、日志等功能
需求设计
作为一个API网关，应该满足一下五个需求
- 高可用：是API网关的生命线；因为API网关是所有服务流量的入口，如果没办法保障API网关稳定运行，有足够的容灾以及降级机制，那么对于整体的业务就是灾难。
- 路由转发：API网关最基本的功能，这个环节的设计，关系到后续业务使用体验。
- 配置化：使API网关更灵活，实现路由热更新。
- 可扩展：API网关除了基础的转发功能以外，还需要支持诸多的功能，如鉴权、限流等一系列的功能，可扩展性，不仅可以使API网关更稳定，也能支持丰富的功能。
- 高性能：毕竟是一个网关，如果性能太差，那么也会拖垮整个系统。
功能设计
高可用
我们采取的是用容器化以及service做服务发现来保障的
路由转发
我们有以下策略保障配置的可用性
- 反向代理：httputil.ReverseProxy，原生兼容，稳定安全。
- 服务发现：全匹配>前缀匹配
- 多转发路由、权重转发，与nginx proxy_pass类似
配置化
扩展性
出于扩展性考虑，采用插件化
定制化
网关实际是所有流量的入口，我们可以轻易的做到统一数据标准化和统一请求某些服务，于是有了许多定制化东西：
- 风控：根据配置，将请求的流量优先请求风控，根据结果再进行下一步
- 用户信息、应用信息、IP信息获取：网关在校验完登录态后，以统一格式在header传递给下游
