开源地址

https://github.com/XiaoMi/mone/tree/master/gateway-all

一、背景

在微服务时代，服务拆分粒度越来越细，每个微服务各自负责自己的核心功能并对外提供一系列的 api 接口。但随着业务的拓展，接口越来越多，也就诞生了一些问题。可以在一个地方去统一的管理这些接口吗？在涉及到鉴权这个普遍的问题时，难道需要每个微服务都实现一次吗？每个微服务都有自己的协议和代码书写风格，比如驼峰和下划线，能统一吗？

这种情况下，我们就需要 api gateway 来解决这些问题。

二、什么是 gateway 网关

API 网关是一种服务，是系统的统一入口。我们可以将各个微服务公共非业务功能放在 API Gateway 中实现，如身份验证、监控、负载均衡、缓存等，以尽可能减少各服务的职责。API 网关将各系统对外暴露的服务聚合起来，所有要调用这些服务的系统都需要通过 API 网关进行访问，基于这种方式网关可以对 API 进行统一管控。

三、Tesla 网关

Tesla 是由小米效能团队开源的基于 JDK19 的一款高性能、易扩展的优秀的 API 网关平台，是小米效能团队结合小米多年大促经验沉淀而成，目前已经经历过十余次小米大促的考验，并在其中承担了流量治理的核心角色，是小米业务链中不可或缺的一环。

说到基于 Java 的 API 网关，可能很多人第一反应就是 SpringCloud Gateway 或者 Zuul，但是 Tesla 网关无论在易用性、扩展性和性能方面都有非常明显的优势。

• 易用性：Tesla 拥有可视化操作界面，同时支持配置实时更新，实时生效，极大简化学习使用成本，优化操作体验。

• 扩展性：Tesla 通过对自定义 Filter 支持，尤其是 Sidecar 模式的动态 Filter 支持，给 Tesla 提供了强大的扩展性支持，可以满足大多数业务和项目的需求。

• 高性能：Tesla 网关自身是基于 Netty 进行开发，在性能上已经拥有非常亮眼的表现。同时全面支持 JDK19 的 Virtual Thread，使 Tesla 网关的性能和资源分配上都得到了较大的提升。

1、技术架构

Tesla 网关主要由两个部分组成：控制台 + 网关。其中控制台主要是维护 API 数据和 Filter 数据，同时还可以对不同网关集群的域名进行管理。Tesla 网关集权是该产品的核心组成部分，负责整个流量治理、安全防护、Filter 执行、协议转换和流量转发等内容。

2、核心能力

2.1、动态发现，负载均衡

当下微服务和容器化的流行，使得业务服务的节点数量、ip 地址等随时可能发生变化。Tesla 网关打通了服务注册中心，订阅相关服务信息，在业务服务侧发生变化时能做到实时感知。并且在处理实际的请求时，支持多种负载均衡策略，比如轮询、哈希等。这样，业务服务做扩缩容，或者故障恢复、热备、切换时，配合业务服务的优雅退出，已经基本能做到调用方无感知了。

2.2、统一管理 api，动态秒级更新

我们按“租户->集群->接口分组->接口”对 api 接口进行组织。你能在 Tesla 控制台查看到你有权限查看的 api 接口，并对他们进行一系列操作，比如开启鉴权，接口 mock 等。Tesla 控制台统一管理了所有的 api 接口，在你新增或者更新了一个接口时，网关集群也能实时感知到接口的变化，实现了运行时配置更新机制。

2.3、用户自定义插件，实时上传，动态插拔

在 Tesla 网关发展的过程中，我们发现让用户能参与进来贡献 filter 插件是一件很棒的事情，每个 filter 是一个功能，大家可以尽情发挥创造力贡献自己的 filter，实现多种功能，像是鉴权、灰度、限流等。Tesla 网关允许用户实时上传自己的 filter 代码，网关集群动态加载，无需重启，每个用户都可以复用别人的 filter。

2.4、多种协议转换

网关作为统一的 api 入口，对外提供的是 restful 风格的 http 接口。但后端的微服务使用的协议是多种多样的，你可以是 dubbo，是 grpc，是 http，在这里，网关封装了后端的不同协议，暴露给前端统一的接口风格。

2.5、流量管理

• 流量安全：流量安全是每一个网关产品都绕不开的话题，如何应对 DDoS 等安全问题、如何进行请求鉴权、如何进行数据脱敏等。Tesla 网关对这一系列安全问题都有完善的，并且经过多次大促验证的解决方案。

• 流量控制：网关产品无论在日常运行，或是大促等特殊时间，都有一套完整的限流熔断措施，可以极大程度上保护后端业务系统的健壮性和可用性。但是 Tesla 网关不止满足于此，还额外扩展了很多实用的功能更好的帮助业务系统。其中就包括结果缓存、流量记录回放等功能，从而给业务系统提供更多的便利和帮助。

• 资源隔离：Tesla 网关承载了比较多的业务系统。其中有流量大的，有安全要求高的，有业务复杂的。可以说几乎每个业务系统都有自己特殊的要求，那么做到每个业务系统互不干扰对 Tesla 网关就尤其重要。比如 A 系统业务非常复杂，导致请求返回比较慢，如果不做资源隔离，单一系统就可以抢占更多的系统资源，从而影响其他业务系统。Tesla 网关目前已经可以做到系统资源隔离、业务资源隔离。每个业务都有自己独立的资源池，保障“专款专用”，给业务保驾护航。

3、设计难点

网关作为流量的统一入口，其稳定性、性能、伸缩性和可扩展性是其设计的重点。

为了保障稳定性，我们对集群做了隔离，像交易链路这样的核心服务就可以申请自己的独立集群。集群里每个接口分组也都有独立线程池来处理请求的接收、分发和返回，以此保障不同分组互不影响。

对于性能，网关引入了 netty 自研了一个 web_server 保证高吞吐，网关集群对核心元数据会在内存里有一份缓存，靠同步机制保证实时性；此外，对慢请求实现了打断机制，避免资源被占用，最后我们还对 dubbo 版本做了一些优化，比如，dubbo 的泛化调用一开始是不支持设置超时时间的。

对于伸缩性的话，作为流量入口的网关是要能支持随时扩缩容以应对突发流量的，所以网关集群里的每台机器本身不具备状态，都由 admin 管理平台来控制数据的同步。

最后是扩展性，网关鼓励大家提交自己的 filter，互惠互助。

4、设计脑图

四、关于未来的发展方向

目前我们的网关架构是中心化网关，提供通用能力如鉴权、限流等处理请求，并根据服务标识将请求路由到正确的后端服务；服务处理完请求，响应原路返回。

作为流量的统一入口，面对多样的业务形态和复杂的网络结构，中心化网关架构在实际场景中遇到了一些困难。第一、随着业务发展壮大，网关集群机器数不断增长。这加剧了运维层面的复杂性，IT 成本也面临不能承受之重。第二，一些核心链路的业务迫切需要与其他业务隔离，避免不可预知的突发流量影响到这些高保业务的可用性。

所以这里开始建设和推广网关的去中心化。Mesh 网关与后端服务同一个 Pod 部署，即 Mesh 网关与业务系统同服务器、不同进程，具备网关的全量能力。这是我们目前在探索的一个方向。