天穹-gateway网关系列1:Tesla网关整体介绍

317 阅读7分钟

开源地址

github.com/XiaoMi/mone…

一、背景

在微服务时代,服务拆分粒度越来越细,每个微服务各自负责自己的核心功能并对外提供一系列的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 网关与业务系统同服务器、不同进程,具备网关的全量能力。这是我们目前在探索的一个方向。