开源地址
https://github.com/XiaoMi/mone/tree/master/gateway-all 欢迎对云原生技术/研发效能感兴趣的小伙伴加入(Fork、Star)我们。
概述
一、背景
在微服务时代，服务拆分粒度越来越细，每个微服务各自负责自己的核心功能并对外提供一系列的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 网关与业务系统同服务器、不同进程，具备网关的全量能力。这是我们目前在探索的一个方向。