ToB企服应用市场:ToB评测及商务社交产业平台

标题: 「架构选型」5 种 API 网关技术选型 [打印本页]

---

作者: 钜形不锈钢水箱    时间: 7 小时前
标题: 「架构选型」5 种 API 网关技术选型
几种常见网关的对比

先来个几款 API 网关的对比，让各人有个整体的印象。

设计网关，必要考虑哪些？

如果让你设计一个 API 网关，你会考虑哪些方面？
路由转发

哀求先到达 API 网关，然后颠末断言，匹配到路由后，由路由将哀求转发给真正的业务服务。
注册发现

各个服务实例必要将自己的服务名、IP 地址和 port 注册到注册中心，然后注册中心会存放一份注册表，Gateway 可以从注册中心获取到注册表，然后转发哀求时只必要转发到对应的服务名即可。
负载均衡

一个服务可以由多个服务实例组成服务集群，而 Gateway 设置的通常是一个服务名，如 passjava-member 服务，所以必要具备负载均衡功能，将哀求分发到不同的服务实例上。
弹力设计

网关还可以把弹力设计中的那些异步、重试、幂等、流控、熔断、监视等都可以实现进去。如许，同样可以像 Service Mesh 那样，让应用服务只关心自己的业务逻辑（或是说数据面上的事）而不是控制逻辑（控制面）。
安全方面

SSL 加密及证书管理、Session 验证、授权、数据校验，以及对哀求源进行恶意攻击的防范。错误处理越靠前的位置就是越好，所以，网关可以做到一个全站的接入组件来对后端的服务进行保护。固然，网关还可以做更多更有趣的变乱，比如：灰度发布、API聚合、API编排。
灰度发布
网关完全可以做到对相同服务不同版本的实例进行导流，还可以收集相干的数据。如许对于软件质量的提升，甚至产品试错都有非常积极的意义。
API 聚合
利用网关可以将多个单独哀求聚合成一个哀求。在微服务体系的架构中，因为服务变小了，所以一个明显的问题是，客户端大概必要多次哀求才能得到全部的数据。如许一来，客户端与后端之间的频繁通信会对应用程序的性能和规模产生非常不利的影响。于是，我们可以让网关来帮客户端哀求多个后端的服务（有些场景下完全可以并发哀求），然后把后端服务的相应结果拼装起来，回传给客户端（固然，这个过程也可以做成异步的，但这必要客户端的配合）。
API 编排
同样在微服务的架构下，要走完一个完备的业务流程，我们必要调用一系列 API，就像一种工作流一样，这个事完全可以通过网页来编排这个业务流程。我们大概通过一个 DSL 来定义和编排不同的 API，也可以通过像 AWS Lambda 服务那样的方式来串联不同的 API。
网关设计重点

网关设计重点重要是三个, 高性能、高可用、高扩展:
高性能

在技术设计上，网关不应该也不能成为性能的瓶颈。对于高性能，最好利用高性能的编程语言来实现，如 C、C++、Go 和 Java。网关对后端的哀求，以及对前端的哀求的服务肯定要利用异步非阻塞的 I/O 来确保后端延迟不会导致应用程序中出现性能问题。C 和 C++ 可以参看 Linux 下的 epoll 和 Windows 的 I/O Completion Port 的异步 IO 模型，Java 下如 Netty、Spring Reactor 的 NIO 框架。
高可用

因为全部的流量或调用颠末网关，所以网关必须成为一个高可用的技术组件，它的稳定直接关系到了全部服务的稳定。网关如果没有设计，就会成变一个单点故障。因此，一个好的网关至少要做到以下几点。

• 集群化。网关要成为一个集群，其最好可以自己组成一个集群，并可以自己同步集群数据，而不必要依赖于一个第三方系统来同步数据。
  
• 服务化。网关还必要做到在不间断的情况下修改设置，一种是像 Nginx reload 设置那样，可以做到不绝服务，另一种是最好做到服务化。也就是说，得要有自己的 Admin API 来在运行时修改自己的设置。
  
• 连续化。比如重启，就是像 Nginx 那样优雅地重启。有一个主管哀求分发的主历程。当我们必要重启时，新的哀求被分配到新的历程中，而老的历程处理完正在处理的哀求后就退出。
  

高可用性涵盖了内部和外部的各种不确定因素，这里讲一下网关系统在高可用性方面做的努力。

img
高扩展

因为网关必要承接全部的业务流量和哀求，所以肯定会有或多或少的业务逻辑。而我们都知道，业务逻辑是多变和不确定的。比如，必要在网关上参加一些和业务相干的东西。因此，一个好的 Gateway 还必要是可以扩展的，并能进行二次开发的。固然，像 Nginx 那样通过 Module 进行二次开发的固然可以。
别的，在运维方面，网关应该有以下几个设计原则。

• 业务松耦合，协议紧耦合。在业务设计上，网关不应与后面的服务之间形成服务耦合，也不应该有业务逻辑。网关应该是在网络应用层上的组件，不应该处理通讯协议体，只应该分析和处理通讯协议头。别的，除了服务发现外，网关不应该有第三方服务的依赖。
  
• 应用监视，提供分析数据。网关上必要考虑应用性能的监控，除了有相应后端服务的高可用的统计之外，还必要利用 Tracing ID 实行分布式链路跟踪，并统计好肯定时间内每个 API 的吞吐量、相应时间和返回码，以便启动弹力设计中的相应策略。
  
• 用弹力设计保护后端服务。网关上肯定要实现熔断、限流、重试和超时等弹力设计。如果一个或多个服务调用耗费的时间过长，那么可接受超时并返回一部分数据，或是返回一个网关里的缓存的上一次乐成哀求的数据。你可以考虑一下如许的设计。
  
• DevOps。因为网关这个组件太关键了，所以必要 DevOps 如许的东西，将其发生故障的概率降到最低。这个软件必要颠末精良的测试，包括功能和性能的测试，另有浸泡测试。还必要有一系列自动化运维的管控工具。
  

网关设计留意事项

• 不要在网关中的代码里内置聚合后端服务的功能，而应考虑将聚合服务放在网关核心代码之外。可以利用 Plugin 的方式，也可以放在网关后面形成一个 Serverless 服务。
  
• 网关应该靠近后端服务，并和后端服务利用同一个内网，如允许以保证网关和后端服务调用的低延迟，并可以减少很多网络上的问题。这里多说一句，网关处理的静态内容应该靠近用户（应该放到 CDN 上），而网关和此时的动态服务应该靠近后端服务。
  
• 网关也必要做容量扩展，所以必要成为一个集群来分担前端带来的流量。这一点，要么通过 DNS 轮询的方式实现，要么通过 CDN 来做流量调治，或者通过更为底层的性能更高的负载均衡装备。
  
• 对于服务发现，可以做一个时间不长的缓存，如许不必要每次哀求都去查一下相干的服务地点的地方。固然，如果你的系统不复杂，可以考虑把服务发现的功能直接集成进网关中。
  
• 为网关考虑 bulkhead 设计方式。用不同的网关服务不同的后端服务，或是用不同的网关服务前端不同的客户。
  

别的，因为网关是为用户哀求和后端服务的桥接装置，所以必要考虑一些安全方面的事宜。具体如下：

• 加密数据。可以把 SSL 相干的证书放到网关上，由网关做统一的 SSL 传输管理。
  
• 校验用户的哀求。一些基本的用户验证可以放在网关上来做，比如用户是否已登录，用户哀求中的 token 是否合法等。但是，我们必要衡量一下，网关是否必要校验用户的输入。因为如许一来，网关就必要从只关心协议头，到必要关心协议体。而协议体中的东西一方面不像协议头是标准的，另一方面分析协议体还要耗费大量的运行时间，从而降低网关的性能。对此，我想说的是，看具体需求，一方面如果协议体是标准的，那么可以干；另一方面，对于分析协议所带来的性能问题，必要做相应的隔离。
  
• 检测异常访问。网关必要检测一些异常访问，比如，在一段比力短的时间内哀求次数超过肯定命值；还比如，同一客户端的 4xx 哀求出错率太高……对于如许的一些哀求访问，网关一方面要把如许的哀求屏蔽掉，另一方面必要发出告诫，有大概会是一些比力重大的安全问题，如被黑客攻击。
  

网关应用

流量网关

流量网关,顾名思义就是控制流量进入集群的网关,有很多工作必要在这一步做,对于一个服务集群,势必有很多非法的哀求或者无效的哀求,这时候要将哀求拒之门外,降低集群的流量压力。

 
定义全局性的、跟具体的后端业务应用和服务完全无关的策略网关就是上图所示的架构模型——流量网关。流量网关通常只专注于全局的Api管理策略，比如全局流量监控、日志纪录、全局限流、黑白名单控制、接入哀求到业务系统的负载均衡等，有点类似防火墙。Kong 就是典范的流量网关。

下面是kong的架构图,来自官网:

 
这里必要补充一点的是，业务网关一样平常摆设在流量网关之后、业务系统之前，比流量网关更靠近业务系统。通常API网指的是业务网关。偶然候我们也会模糊流量网关和业务网关，让一个网关负担全部的工作,所以这两者之间并没有严格的界限。

业务网关

当一个单体应用被拆分成许许多多的微服务应用后，也带来了一些问题。一些与业务非强相干的功能，比如权限控制、日志输出、数据加密、熔断限流等，每个微服务应用都必要，因此存在着大量重复的代码实现。而且由于系统的迭代、职员的更替，各个微服务中这些功能的实现细节出现了较大的差异，导致维护本钱变高。另一方面，原先单体应用下非常容易做的接口管理，在服务拆分后没有了一个会合管理的地方，无法统计已存在哪些接口、接口定义是什么、运行状态如何。
网关就是为了办理上述问题。作为微服务体系中的核心底子办法，一样平常必要具备接口管理、协议适配、熔断限流、安全防护等功能，各种开源的网关产品（比如 zuul）都提供了良好高可扩展性的架构、可以很方便的实现我们必要的一些功能、比如鉴权、日志监控、熔断限流等。
与流量网关相对应的就是业务网关,业务网关更靠近我们的业务,也就是与服务器应用层打交道,那么有很多应用层必要考虑的变乱就可以依托业务网关,比方在线程模型、协议适配、熔断限流，服务编排等。下面看看业务网关体系布局:

 
从这个图中可以看出业务网关重要职责以及所做的变乱, 目前业务网关比力成熟的 API 网关框架产品有三个 分别是:Zuul1、Zuul2 和 SpringCloud Gateway, 后面再进行对比。

网关与服务器集群

回到我们服务器上,下面图先容了网关(Gateway)作用,可知 Gateway 方式下的架构，可以细到为每一个服务的实例设置一个自己的 Gateway，也可以粗到为一组服务设置一个，甚至可以粗到为整个架构设置一个接入的 Gateway。于是，整个系统架构的复杂度就会变得简单可控起来。

这张图展示了一个多层 Gateway 架构，其中有一个总的 Gateway 接入全部的流量(流量网关)，并分发给不同的子系统，另有第二级 Gateway 用于做各个子系统的接入 Gateway(业务网关)。可以看到，网关所管理的服务粒度可粗可细。通过网关，我们可以把分布式架构组织成一个星型架构，由网络对服务的哀求进行路由和分发。下面来聊聊好的网关应该具备哪些功能,也就是网关设计模式。
常见网关对比

既然对比,就先宏观上对各种网关有一个了解,后面再挑一些常用的或者说应用广泛的具体了解。
目前常见的开源网关大致上按照语言分类有如下几类：

• Nginx+lua：OpenResty、Kong、Orange、Abtesting gateway 等
  
• Java：Zuul/Zuul2、Spring Cloud Gateway、Kaazing KWG、gravitee、Dromara soul 等
  
• Go：Janus、fagongzi、Grpc-gateway
  
• Dotnet：Ocelot
  
• NodeJS：Express Gateway、Micro Gateway
  

按照利用数量、成熟度等来划分，主流的有 4 个：

• OpenResty
  
• Kong
  
• Zuul/Zuul2
  
• Spring Cloud Gateway
  

OpenResty

OpenResty是一个流量网关,根据前面对流量网关的先容就可以知道流量网关的责怪。
OpenResty基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建可以大概处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。
通过揉和浩繁设计良好的 Nginx 模块，OpenResty 有效地把 Nginx 服务器转变为一个强大的 Web 应用服务器，基于它开发职员可以利用 Lua 编程语言对 Nginx 核心以及现有的各种 Nginx C 模块进行脚本编程，构建出可以处理一万以上并发哀求的极端高性能的 Web 应用
OpenResty 最早是顺应 OpenAPI 的潮流做的，所以 Open 取自“开放”之意，而Resty便是 REST 风格的意思。固然厥后也可以基于 ngx_openresty 实现任何情势的 web service 或者传统的 web 应用。
也就是说 Nginx 不再是一个简单的静态网页服务器，也不再是一个简单的反向代理了。第二代的 openresty 致力于通过一系列 nginx 模块，把nginx扩展为全功能的 web 应用服务器。
ngx_openresty 是用户驱动的项目，厥后也有不少国内用户的到场，从 openresty.org 的点击量分布上看，国内和国外的点击量基本持平。
ngx_openresty 目前有两大应用目的：

• 通用目的的 web 应用服务器。在这个目的下，现有的 web 应用技术都可以算是和 OpenResty 或多或少有些类似，比如 Nodejs, PHP 等等。ngx_openresty 的性能（包括内存利用和 CPU 效率）算是最大的卖点之一。
  
• Nginx 的脚本扩展编程，用于构建机动的 Web 应用网关和 Web 应用防火墙。有些类似的是 NetScaler。其上风在于 Lua 编程带来的巨大机动性。
  

Kong

相干毗连: 官网、Github
Kong基于OpenResty开发，也是流量层网关, 是一个云原生、快速、可扩展、分布式的Api 网关。继承了OpenResty的高性能、易扩展性等特点。Kong通过简单的增加机器节点，可以很容易的程度扩展。同时功能插件化，可通过插件来扩展其能力。而且在任何底子架构上都可以运行。具有以下特性：

• 提供了多样化的认证层来保护Api。
  
• 可对出入流量进行管制。
  
• 提供了可视化的流量检查、监视分析Api。
  
• 可以大概及时的转换哀求和相应。
  
• 提供log办理方案
  
• 可通过api调用Serverless 函数。
  

Kong办理了什么问题
当我们决定对应用进行微服务改造时，应用客户端如何与微服务交互的问题也随之而来，究竟服务数量的增加会直接导致摆设授权、负载均衡、通信管理、分析和改变的难度增加。
面对以上问题，API GATEWAY是一个不错的办理方案，其所提供的访问限定、安全、流量控制、分析监控、日志、哀求转发、合成和协议转换功能，可以解放开发者去把精力会合在具体逻辑的代码，而不是把时间耗费在考虑如何办理应用和其他微服务链接的问题上。
图片来自Kong官网:

 
可以看到Kong办理的问题。专注于全局的Api管理策略，全局流量监控、日志纪录、全局限流、黑白名单控制、接入哀求到业务系统的负载均衡等。

Kong的优点以及性能
在浩繁 API GATEWAY 框架中，Mashape 开源的高性能高可用API网关和API服务管理层——KONG（基于 NGINX+Lua）特点尤为突出，它可以通过插件扩展已有功能，这些插件（利用 lua 编写）在API哀求相应循环的生命周期中被执行。于此同时，KONG本身提供包括 HTTP 基本认证、密钥认证、CORS、TCP、UDP、文件日志、API哀求限流、哀求转发及 NGINX 监控等基本功能。目前，Kong 在 Mashape 管理了超过 15,000 个 API，为 200,000 开发者提供了每月数十亿的哀求支持。
Kong架构
Kong提供一些列的服务,这就不得不谈谈内部的架构:

 
起首最底层是基于Nginx, Nginx是高性能的底子层, 一个良好的负载均衡、反向代理器,然后在此底子上增加Lua脚本库,形成了OpenResty,拦截哀求, 相应生命周期,可以通过Lua编写脚本,所以插件比力丰富。

Zuul1.0

Zuul是全部从装备和web站点到Netflix流媒体应用程序后端哀求的前门。作为一个边缘服务应用程序，Zuul被构建来支持动态路由、监视、弹性和安全性。它还可以根据必要将哀求路由到多个Amazon自动伸缩组。
Zuul利用了一系列不同类型的过滤器，使我们可以大概快速机动地将功能应用到服务中。
过滤器
过滤器是Zuul的核心功能。它们负责应用程序的业务逻辑，可以执行各种任务。

• Type ：通常定义过滤器应用在哪个阶段
  
• Async ：定义过滤器是同步照旧异步
  
• Execution Order ：执行序次
  
• Criteria ：过滤器执行的条件
  
• Action ：如果条件满意，过滤器执行的动作
  

Zuul提供了一个动态读取、编译和运行这些过滤器的框架。过滤器之间不直接通信，而是通过每个哀求特有的RequestContext共享状态。
下面是Zuul的一些过滤器:
Incoming
Incoming过滤器在哀求被代理到Origin之前执行。这通常是执行大部分业务逻辑的地方。比方:认证、动态路由、速率限定、DDoS保护、指标。
Endpoint
Endpoint过滤器负责基于incoming过滤器的执行来处理哀求。Zuul有一个内置的过滤器（ProxyEndpoint），用于将哀求代理到后端服务器，因此这些过滤器的典范用途是用于静态端点。比方:康健检查相应，静态错误相应，404相应。
Outgoing
Outgoing过滤器在从后端接收到相应以后执行处理操作。通常情况下，它们更多地用于形成相应和添加指标，而不是用于任何繁重的工作。比方:存储统计信息、添加/剥离标准标题、向及时流发送变乱、gziping相应。
过滤器类型
下面是与一个哀求典范的生命周期对应的标准的过滤器类型：

• PRE ：路由到Origin之前执行
  
• ROUTING ：路由到Origin期间执行
  
• POST ：哀求被路由到Origin之后执行
  
• ERROR ：发生错误的时候执行
  

这些过滤器资助我们执行以下功能：

• 身份验证和安全性 ：识别每个资源的身份验证需求，并拒绝不满意它们的哀求
  
• 监控 ：在边缘跟踪故意义的数据和统计数据，以便给我们一个准确的生产视图
  
• 动态路由 ：动态路由哀求到不同的后端集群
  
• 压力测试 ：逐渐增加集群的流量，以评估性能
  
• 限流 ：为每种哀求类型分配容量，并抛弃超过限定的哀求
  
• 静态相应处理 ：直接在边缘构建一些相应，而不是将它们转发到内部集群
  

Zuul 1.0 哀求生命周期

 
Netflix公布了通用API网关Zuul的架构转型。Zuul原本接纳同步阻塞架构，转型后叫作Zuul2，接纳异步非阻塞架构。Zuul2和Zuul1在架构方面的重要区别在于，Zuul2运行在异步非阻塞的框架上，比如Netty。Zuul1依赖多线程来支持吞吐量的增长，而Zuul 2利用的Netty框架依赖变乱循环和回调函数。

Zuul2.0

Zuul 2.0 架构图

img
上图是Zuul2的架构，和Zuul1没有本质区别，两点变革：

• 前端用Netty Server代替Servlet，目的是支持前端异步。后端用Netty Client代替Http Client，目的是支持后端异步。
  
• 过滤器换了一下名字，用Inbound Filters代替Pre-routing Filters，用Endpoint Filter代替Routing Filter，用Outbound Filters代替Post-routing Filters。
  

Inbound Filters ：路由到 Origin 之前执行，可以用于身份验证、路由和装饰哀求
Endpoint Filters ：可用于返回静态相应，否则内置的ProxyEndpoint过滤器将哀求路由到Origin
Outbound Filters ：从Origin那里获取相应后执行，可以用于度量、装饰用户的相应或添加自定义header
有两种类型的过滤器：sync 和 async。因为Zuul是运行在一个变乱循环之上的，因此从来不要在过滤中阻塞。如果你非要阻塞，可以在一个异步过滤器中如许做，而且在一个单独的线程池上运行，否则可以利用同步过滤器。
上文提到过Zuul2开始接纳了异步模型
上风是异步非阻塞模式启动的线程很少，基本上一个CPU core上只需启一个变乱环处理线程，它利用的线程资源就很少，上下文切换(Context Switch)开销也少。非阻塞模式可以接受的毗连数大大增加，可以简单理解为哀求来了只必要进队列，这个队列的容量可以设得很大，只要不超时，队列中的哀求都会被依次处理。
不敷之处：异步模式让编程模型变得复杂。一方面Zuul2本身的代码要比Zuul1复杂很多，Zuul1的代码比力容易看懂，Zuul2的代码看起来就比力费劲。另一方面异步模型没有一个明确清晰的哀求->处理->相应执行流程(call flow)，它的流程是通过变乱触发的，哀求处理的流程随时大概被切换断开，内部实现要通过一些关联id机制才能把整个执行流再串联起来，这就给开发调试运维引入了很多复杂性，比如你在IDE里头调试异步哀求流就非常困难。别的ThreadLocal机制在这种异步模式下就不能简单工作，因为只有一个变乱环线程，不是每个哀求一个线程，也就没有线程局部的概念，所以对于CAT这种依赖于ThreadLocal才能工作的监控工具，调用链埋点就不好搞(实际可以工作但必要进行特别处理)。
总体上，异步非阻塞模式比力实用于IO密集型(IO bound)场景，这种场景下系统大部分时间在处理IO，CPU盘算比力轻，少量变乱环线程就能处理。
Zuul 与 Zuul 2 性能对比
图片来源:Zuul's Journey to Non-Blocking

img
Netflix给出了一个比力模糊的数据，大致Zuul2的性能比Zuul1好20%左右，这里的性能重要指每节点每秒处理的哀求数。为什么说模糊呢？因为这个数据受实际测试环境，流量场景模式等浩繁因素影响，你很难复现这个测试数据。即便这个20%的性能提升是确实的，其实这个性能提升也并不大，和异步引入的复杂性相比，这20%的提升是否值得是个问题。Netflix本身在其博文22和ppt11中也是有点暗昧其词，甚至自身都有一些疑问的。
Spring Cloud Gateway

原理详见这篇：6000 字 | 16 图 | 深入理解 Spring Cloud Gateway 的原理
SpringCloud Gateway 是 Spring Cloud 的一个全新项目，该项目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。
SpringCloud Gateway 作为 Spring Cloud 生态系统中的网关，目的是替代 Zuul，在Spring Cloud 2.0以上版本中，没有对新版本的Zuul 2.0以上最新高性能版本进行集成，仍旧照旧利用的Zuul 2.0之前的非Reactor模式的老版本。而为了提升网关的性能，SpringCloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则利用了高性能的Reactor模式通信框架Netty。
Spring Cloud Gateway 的目的，不仅提供统一的路由方式，而且基于 Filter 链的方式提供了网关基本的功能，比方：安全，监控/指标，和限流。
Spring Cloud Gateway 底层利用了高性能的通信框架Netty。
SpringCloud Gateway 特性
SpringCloud官方，对SpringCloud Gateway 特性先容如下：
（1）基于 Spring Framework 5，Project Reactor 和 Spring Boot 2.0
（2）集成 Hystrix 断路器
（3）集成 Spring Cloud DiscoveryClient
（4）Predicates 和 Filters 作用于特定路由，易于编写的 Predicates 和 Filters
（5）具备一些网关的高级功能：动态路由、限流、路径重写
从以上的特性来说，和Zuul的特性差别不大。SpringCloud Gateway和Zuul重要的区别，照旧在底层的通信框架上。
简单阐明一下上文中的三个术语：
Filter（过滤器）
和Zuul的过滤器在概念上类似，可以利用它拦截和修改哀求，而且对上游的相应，进行二次处理。过滤器为org.springframework.cloud.gateway.filter.GatewayFilter类的实例。
Route（路由）
网关设置的基本组成模块，和Zuul的路由设置模块类似。一个Route模块由一个 ID，一个目的 URI，一组断言和一组过滤器定义。如果断言为真，则路由匹配，目的URI会被访问。
Predicate（断言）：
这是一个 Java 8 的 Predicate，可以利用它来匹配来自 HTTP 哀求的任何内容，比方 headers 或参数。断言的输入类型是一个 ServerWebExchange。
网关对比总结

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4