关于网关
- API Gateway 是微服务架构中的一种设计模式（集成模式，解决Client - Service之间的通信问题）
- 用于设计、构建，大型、复杂、多客户端的微服务系统
- 与“Facade”模式类似，提供了单一的API入口，封装了底层的系统架构
- 提供了将请求反向代理到内部服务的能力，客户端路由到后端服务
- 提供了横向的通用能力，例如多协议、鉴权、限流、缓存、熔断等服务治理能力
网关特性
- 路由 、服务聚合、负载均衡、黑白名单、认证鉴权、限流、流量监控、缓存、降级、熔断、流量复制、流量染色等
网关价值
- 能力解耦：将Client通过网络层与内部的服务解耦
- 服务抽象：为后端服务接入提供了抽象，保证了后端服务变更时不会影响Client
- 横向统一：抽象出每个微服务调用中存在的一些复杂性和细节，例如认证、缓存等
- 协议无关：可跨多个通信渠道为不同的客户端提供服务
- 稳定提升：
- 通过提供诸如负载均衡、限流、熔断等能力，整体提升系统的稳定性
- 灰度建设： 灰度环境的必备组件
- 能力增强：
- 安全性：诸如流量加密与安全认证
- 可观察性：应用程序之间流量的实时可视化，包括流量量、延迟时间和错误率等数据。
- 网格建设：作为服务网格的必备基础组件。
- 总之，网关提供了一种更加简单、安全、可靠和高效的方式来管理应用程序，为应用程序的开发、部署、维护带来了诸多价值。
反向代理
- 反向代理 - 客户端和后端服务之间的代理 - 能力单一，灵活性差
- 负载均衡
- 防攻击
- SSL加密
- 缓存
- 网关 - 一种特殊类型的反向代理 - 能力丰富，灵活性强
- 见上述能力
常见网关
- 概述
目前主流的开源API网关都是基于Nginx、Envoy + 扩展程序实现的(Nginx的特点是轻量级和高性能，适用于静态资源的服务和反向代理；Envoy的特点是可扩展性和灵活性，适用于大规模的微服务架构和复杂网络拓扑下的流量管理和安全控制。)，除此之外还有一些基于JVM的Netflix Zuul和Spring Cloud Gateway。实现原理类似，都是采用责任链的设计模式，调用者请求首先达到网关，经过网关链式插件处理后才最终发送给后端业务服务。
- Spring Cloud Gateway - 底层使用了高性能的通信框架Netty
* 基于 Spring Framework 5、Reactor 和 Spring Boot 2.0等技术栈构建的API网关
* 提供了API路由、负载均衡、限流、重试、熔断、安全等核心功能，并且可以通过自定义过滤器链来扩展其功能。
* Spring Cloud Gateway的核心组件包括路由（Route）、过滤器（Filter）和Predicate。路由用于将请求路由到目标服务，过滤器用于对请求和响应进行处理，Predicate用于对请求进行匹配和过滤。
* Spring Cloud Gateway还支持集成多种服务注册中心和负载均衡算法，如Eureka、Consul、Ribbon等。
-
Kong - 基于OpenResty(是一个基于Nginx和Lua的Web应用服务器解决方案，它将Nginx作为Web服务器和反向代理服务器，并使用Lua脚本来扩展其功能。)编写的高可用、易拓展的云原生的API 网关
-
架构解析
- 基于NGINX和Apache Cassandra或PostgreSQL构建的
- 面向插件的架构，可以通过插件扩展、定制化Kong的功能
- 提供易于使用的RESTful API来操作和配置API管理系统
- 可以水平扩展多个Kong服务器
- 通过前置的负载均衡配置把请求均匀地分发到各个Server
-
功能特点
- 路由和负载均衡：根据请求属性（如路径、域名等）进行条件匹配和路由，支持多种负载均衡策略。
- 安全：提供身份验证、授权、TLS终止、Web应用防火墙（WAF）等安全功能。
- 可观察性：收集和导出度量数据，支持日志和分布式追踪。
- 限流和配额：设置请求速率限制和配额，防止API滥用。
- 缓存和性能优化：通过缓存响应数据和压缩响应内容，提高性能和降低延迟。
-
扩展集成
- 插件系统：Kong提供了一个丰富的插件生态系统，可通过插件扩展功能和集成第三方服务。
- 自定义插件：支持Lua脚本编写自定义插件，以满足特定需求。
- 多协议支持：支持HTTP/1.1、HTTP/2、gRPC、WebSocket等协议。
- 云原生集成：与Kubernetes、Istio等云原生组件集成，支持容器部署。
-
配置管理
- 声明式配置：支持使用Kubernetes自定义资源定义（CRD）或JSON配置文件进行配置。
- RESTful API：提供RESTful API接口，便于管理和自动化部署。
- 管理界面：Kong Enterprise提供Web UI界面（Kong Manager）和监控平台（Vitals）。
-
高可用性和性能
- 高可用性：支持集群部署，实现故障切换和高可用性。
- 性能优化：基于高性能的Nginx和OpenResty，提供低延迟和高吞吐量。
-
总之，Kong是一个功能丰富且性能优越的API网关，适用于微服务、无服务器和服务网格等场景
-
插件示例 // 这个插件定义了一个名为my-limit的限制器，它会根据IP地址来限制请求速率。在请求处理过程中，它会调用get_identifier函数获取客户端IP地址，然后根据IP地址和插件配置中的限制条件来判断请求是否超过了速率限制。
local rate_limiting = require "kong.plugins.rate-limiting" local function get_identifier() return kong.client.get_ip() end local function get_usage(key) local usage, err = rate_limiting.get_usage(key, "my-limit") if err then return nil, err end return usage.remaining, nil end local function incr_usage(key, period, amount) local _, err = rate_limiting.incr(key, amount, period, "my-limit") if err then return nil, err end return true, nil end local function check_limit(key, limit) local remaining, err = get_usage(key) if err then return nil, err end if remaining < 1 then return nil, "API rate limit exceeded" end incr_usage(key, limit.period, 1) return true, nil end local function rate_limiting_handler(conf) local identifier = get_identifier() if not identifier then return kong.response.exit(500, { message = "Cannot identify the client IP address" }) end local key = identifier .. ":" .. conf.limit_by local ok, err = check_limit(key, conf) if err then return kong.response.exit(429, { message = err }) end end return { ["my-limit"] = { handler = rate_limiting_handler, config_schema = { type = "record", fields = { { limit_by = { type = "string", default = "ip" }, }, { period = { type = "number", default = 60 }, }, { limit = { type = "number", default = 100 }, }, }, }, }, } 要在Kong中启用这个插件，需要将它安装到Kong中，并在Kong配置文件中添加以下内容： plugins: - name: my-plugin config: limit_by: ip period: 60 limit: 100 这个配置将会启用名为my-plugin的Lua插件，并将limit_by设置为ip，period设置为60秒，limit设置为100次。这样，每个客户端IP地址在60秒内最多只能访问API 100次。
-
| 维度 | 优点 | 缺点 |
|---|---|---|
| 性能 | 基于NGINX，性能优越，可以处理大量并发请求。 | |
| 扩展 | 通过插件体系轻松扩展功能，提供了许多官方和第三方插件。 | |
| 社区 | 拥有强大的开源社区，提供丰富的技术资源和支持。 | |
| 部署 | 支持多种部署方式，包括Docker、Kubernetes和虚拟机。 | |
| API | API支持gRPC、GraphQL和REST API。 | |
| 学习 | 成本较高，Kong的配置和插件体系需要一定的学习时间。 | |
| 限制 | 虽然Kong基于NGINX，但它也继承了NGINX的一些限制，例如在动态配置方面可能不如其他网关灵活。 | |
| 成本 | 尽管Kong提供免费的社区版，但企业版对于一些公司来说成本较高。 |
- APISIX - 基于OpenResty(Nginx+Lua)和etcd来实现，具有动态、实时、高性能的特性，国产，借鉴了Kong的设计思想，官方宣称性能优于Kong
- 架构解析
- 整体上分成数据面和控制面两个部分
- 控制面用来管理路由，主要通过 etcd 来实现配置中心
- 数据面用来处理客户端请求，通过 APISIX 自身来实现，会不断去 watch etcd 中的 route、upstream 等数据。
- 功能特点
- 路由和负载均衡：可以根据请求的参数、头信息和路径等，动态选择API的后端服务，以实现灵活的路由管理。
- 安全：持多种安全认证方式，包括OAuth、JWT和基于证书的认证等，可以确保API的安全性和可信度。
- 可观察性：提供完善的监控和日志功能，可以实时监控API的使用情况和性能指标，并且支持多种输出方式，包括Kafka、InfluxDB等。
- 扩展集成
- 插件系统：采用基于Nginx的插件扩展机制，用户可以自定义插件来满足特定的业务需求，扩展APISIX的功能和灵活性。
- 自定义插件：支持Lua脚本编写自定义插件，以满足特定需求。
- 多协议支持：支持HTTP/1.1、HTTP/2、gRPC、WebSocket等协议。
- 云原生集成：APISIX可以部署在云原生环境中，如Kubernetes、Docker等，可以充分利用云原生技术的优势，实现高效、可靠的API管理。
- 配置管理
- 配置：通过RESTful API或Web界面来配置路由和插件。
- RESTful API：提供RESTful API接口，便于管理和自动化部署。
- 管理界面：Enterprise提供Web UI界面。
- 高可用性和性能
- 高可用性：支持集群部署，实现故障切换和高可用性。
- 性能优化：基于高性能的Nginx和OpenResty，提供低延迟和高吞吐量。
- 总之，APISIX是一个高性能且易于扩展的API网关，适用于各种规模的项目。
- 架构解析
| 维度 | 优点 | 缺点 |
|---|---|---|
| 性能 | 基于NGINX，提供高性能、低延迟的API代理和负载均衡。 | |
| 扩展 | 通过插件体系进行功能扩展，支持Lua脚本编写自定义插件。 | 虽然提供了许多内置插件，但与Kong等竞争对手相比，第三方插件生态相对较弱。 |
| 社区 | 虽然得到Apache基金会支持，但与其他成熟API网关相比，社区规模相对较小。 | |
| 配置 | 动态配置，支持热加载和动态更新配置，不需要重启服务。 | |
| API | API支持gRPC、GraphQL和REST API。 | |
| 学习 | 成本较高，配置和插件编写可能需要一定的学习时间，尤其对于不熟悉Lua脚本的用户。 | |
| 成本 | 尽管APISIX提供免费的社区版，但企业版对于一些公司来说成本较高。 |
- Gloo - 由Solo.io开发，旨在连接、保护和扩展应用程序和微服务，基于Kubernetes原生设计的功能丰富的Ingress Controller，致力于成为下一代API网关标杆产品
- 架构解析
- 架构分为控制平面和数据平面，数据平面以Envoy为代理对所有实际流量进行转发，控制平面负责将用户配置转化为Envoy配置
- 通过Envoy XDS gRPC API来动态更新Envoy配置
- 本质是一个Envoy xDS配置翻译引擎, 为Envoy提供高级配置(及定制的Envoy过滤器)
- 监控各种配置源的更新,并立即响应通过gRPC更新给Envoy
- 功能特点
- 动态路由：根据请求属性（如路径、标头、查询参数等）进行条件匹配和路由。
- 变换：在路由过程中修改请求和响应，如添加或删除HTTP头、修改请求路径等。
- 负载均衡：支持多种负载均衡策略，如轮询、加权轮询、最少请求等。
- 可观察性：提供丰富的度量、日志和分布式追踪功能。
- 安全：支持多种安全功能，如TLS终止、外部认证、Web应用防火墙（WAF）等。
- 扩展集成
- 函数级路由：支持将请求路由到云原生函数（如AWS Lambda、OpenFaaS等）。
- 插件系统：通过自定义过滤器扩展Envoy，实现自定义功能和策略。
- 云原生集成：与Kubernetes、Istio、Consul等云原生组件紧密集成。
- 多协议支持：支持HTTP/1.1、HTTP/2、gRPC、WebSocket等协议。
- 配置管理
- 声明式配置：使用Kubernetes自定义资源定义（CRD）配置路由和策略。
- 控制平面：Gloo提供一个独立的控制平面，用于管理Envoy代理的配置和策略。
- 管理界面：提供Web UI和CLI工具，便于管理和监控Gloo实例。
- 高可用和性能
- 水平扩展：Gloo通过Kubernetes进行自动扩展和负载均衡。
- 快速更新：支持无缝更新配置和策略，无需重启Envoy代理。
- 高性能：基于Envoy代理，提供高性能和低延迟的API网关。
- 总之，Gloo是一个功能丰富且性能优越的API网关，特别适合Kubernetes、无服务器和服务网格等场景。
- 插件实现
//插件定义了一个名为header-routing的插件，它使用Lua编写，并在请求处理过程中根据请求头中的X-Route值来路由请求到不同的后端服务。如果X-Route的值是foo，则会将请求路由到foo.example.com；如果X-Route的值是bar，则会将请求路由到bar.example.com。 plugins: - name: header-routing type: lua config: | function envoy_on_request(request_handle) local headers = request_handle:headers() local route = headers:get("X-Route") if route == "foo" then request_handle:headers():replace("Host", "foo.example.com") elseif route == "bar" then request_handle:headers():replace("Host", "bar.example.com") end end //要在Gloo中启用这个插件，需要将它安装到Gloo中，并在Gloo路由规则中添加以下内容： - name: header-routing-route namespace: gloo-system spec: plugins: - name: header-routing namespace: gloo-system routePlugins: prefixRewrite: prefixRewrite: / virtualHost: domains: - '*' routes: - matchers: - prefix: /api routeAction: single: upstream: name: my-upstream namespace: gloo-system
- 架构解析
| 维度 | 优点 | 缺点 |
|---|---|---|
| 性能 | 基于Envoy，提供高性能、可观察性和灵活性。 | |
| 路由 | 函数级路由：支持函数级别的路由和转换，可将API请求转发到特定的函数或服务。 | |
| 安全 | 提供端到端的安全性，包括双向TLS认证、RBAC和JWT认证等功能。 | |
| Serverless | 与各种无服务器平台（如AWS Lambda、Google Cloud Functions等）集成。 | |
| API | API支持gRPC、GraphQL和REST API。 | |
| 学习 | 成本较高，Gloo的配置、函数级路由和转换可能需要一定的学习时间。 | |
| 成本 | 尽管Gloo提供免费的社区版，但企业版对于一些公司来说成本较高。 |
- Istio Gateway
- 架构解析
- 服务网格诞生的初衷是为了解决分布式应用的内部流量的管理问题，即“东西向”流量，而像Istio还内置了网关，从而将系统内外部的流量纳入了统一管控。
- Istio Gateway是Istio服务网格体系中的一个关键组件，负责在服务网格边缘管理进出流量。
- 基于Envoy代理构建，提供强大的流量管理、安全和可观察性功能
- Istio Gateway使用Kubernetes自定义资源定义（CRD）来配置流量路由和管理。主要的CRD包括Gateway、VirtualService、DestinationRule和ServiceEntry等。这些资源可以灵活地定义复杂的路由规则、负载均衡策略和流量策略。
- 功能特点
- 流量路由控制：可以根据请求的源IP地址、协议、端口等条件对流量进行路由和分发，以实现流量控制和管理。
- 负载均衡和故障转移：支持多种负载均衡算法和故障转移机制，可以实现流量的均衡和容错。
- 流量分割：可将流量按比例分配到不同的服务版本或实例。
- 故障注入：用于测试服务弹性，可以注入延迟和错误等故障。
- 安全：支持对流量进行TLS加密和认证，可以保证流量的安全性和可靠性。
- 拓展集成
- 环境适配：Istio Gateway可以工作在Kubernetes之外的环境，如虚拟机、裸金属服务器等。
- 协议支持：可通过扩展适配器支持更多协议和服务发现方式。
- 插件功能：自定义插件和代码扩展Istio Gateway的功能。
- 高可用和性能
- 水平扩展：通过Kubernetes进行自动扩展和负载均衡。
- 快速更新：支持无缝更新配置和策略，无需重启Envoy代理。
- 高性能：基于Envoy代理，提供高性能和低延迟的API网关。
- 总之，Istio Gateway是一个功能强大且灵活的API网关，适用于服务网格场景。通过整合Istio的各个组件，它可以提供端到端的流量管理、安全和可观察性。
- 架构解析
| 维度 | 优点 | 缺点 |
|---|---|---|
| 性能 | 基于Envoy，提供高性能、可观察性和灵活性。 | |
| 网格 | 与Istio服务网格深度集成，提供统一的流量管理、安全和策略实施。 | |
| 社区 | 社区活跃度高，服务网格担当 | |
| 流量管理 | 支持灵活的路由规则、流量分割和故障注入等功能。 | |
| API | 支持HTTP/1.1、HTTP/2、gRPC、WebSocket和TLS传输。 | |
| 可观察性 | 提供了丰富的指标和日志，可以通过集成Prometheus和Grafana等工具实现流量监控和分析。 | |
| 开放性与可拓展性 | 设计原则是开放性和可扩展性，可以与各种开源和商业的软件集成和扩展，例如Kubernetes、Prometheus、Elasticsearch等 | |
| 学习 | 成本较高，使用需要对Istio服务网格和Envoy代理有一定的了解。 | |
| 复杂 | Istio包含多个组件，学习、部署、管理相对复杂，有额外的运维负担。 |
Istio网关
- Kubernetes Ingress
- 外部服务如何访问Kubernetes Cluster内部的服务呢？
- 服务暴露的三种方式
- Cluster IP - 通过集群内部的IP暴露服务，缺点是只能集群内可以访问该服务
- Node Port - Node IP + NodePort，缺点是随着服务的增加，管理成本高
- Load Balancer - 通过云供应商的LB，自动创建指向LB的ClusterIP和NodePort
- Ingress API - 是一个Kubernetes API对象，提供了一种简单的方法来描述从集群外部到集群内服务的 HTTP和HTTPS 路由
- 使用 Ingress，我们可以定义路由流量的规则，而无需创建一堆负载均衡器或在节点上公开每个服务
- 例子 apiVersion: extensions/v1beta1 kind: Ingress metadata: name: echo-service namespace: default spec: rules: - host: echo.example.com http: paths: - backend: serviceName: echo servicePort: 80 path: /
- Ingress Controller - 通常是一个应用程序，在 Kubernetes 集群中作为 Pod 运行，并根据 Ingress Resources 配置负载均衡器。负载均衡器可以是运行在集群中的软件负载均衡器，也可以是运行在集群外部的硬件或云负载均衡器。
- 服务暴露的三种方式
- 外部服务如何访问Kubernetes Cluster内部的服务呢？
- Istio Ingress Gateway - 功能与 Kubernetes Ingress类似，负责进出集群的南北流量。
-
描述了一个负载均衡器，用于承载进出服务网格边缘的连接。
-
Envoy Proxy 作为入口代理处理所有的流量。
-
此时，Envoy Proxy充当了API Gateway的角色，流量通过CR中配置的Istio路由规则路由到各个内部的服务。
-
同时，配置的流量规则也会作用生效。 * Istio Ingress Gateway 配置
-
创建Istio Gateway - 设置了Envoy Proxy 充当LB apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: httpbin-gateway spec: selector: istio: ingressgateway # use Istio default gateway implementation servers: - port: number: 80 name: http protocol: HTTP hosts: - "httpbin.example.com"
-
创建VS - 路由规则 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: httpbin spec: hosts: - "httpbin.example.com" gateways: - httpbin-gateway http: - match: - uri: prefix: /status - uri: prefix: /delay route: - destination: port: number: 8000 host: httpbin
-
创建DR - 流量规则 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: httpbin-destination-rule spec: host: httpbin.example.com trafficPolicy: loadBalancer: simple: RANDOM subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 trafficPolicy: loadBalancer: simple: ROUND_ROBIN
- 自定义拓展
apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: name: header-filter spec: workloadSelector: labels: app: my-app configPatches: - applyTo: HTTP_FILTER match: context: GATEWAY listener: filterChain: filter: name: envoy.http_connection_manager subFilter: name: envoy.router patch: operation: INSERT_BEFORE value: name: envoy.filters.http.lua config: inlineCode: | function envoy_on_request(request_handle) request_handle:headers():add("X-My-Header", "foo") end
-
网关对比
1. 传统网关 VS. 云原生网关| 内容 | 传统网关 | 云原生网关 | 对比总结 |
|---|---|---|---|
| 架构 | 传统单体应用，将所有功能集成在一个组件中。 | 分布式，控制面、数据面分离，支持模块化和可插拔的功能。 | 云原生网关的架构具有天然的领先性 |
| 拓展性 | 水平拓展 | 只需要拓展数据面 | 云原生网关具备一键拓展的能力 |
| 代理类型 | JVM | Envoy/Nginx | 云原生网关代理具备多样性 |
| 性能 | 一般 | 很高 | 高性能是云原生网关的特性之一 |
| Kubernetes | 拓展组件 | 原生支持 | 以OpenResty为代表的拓展能力灵活性极强 |
| 配置储存 | 内存 | 持久化组件 | 分布式架构，提供了存储组件 |
| 可拓展性 | 插件弱 | 插件丰富 | 云原生网关的特性之一 |
| 可观测性 | 一般 | 可以集成Prometheus、Kiali集成，具备良好的可观测性 | 云原生网关的特性之一 |
| 路由能力 | 一般 | 支持灰度、流量复制、染色等高阶特性 | 具备灵活、强大的路由能力 |
| 容灾能力 | 一般 | 分布式架构，数据面、控制面分离，支持多集群部署 | 最大程度保障数据面可用性 |
- 云原生网关对比
| 内容 | Kong | APISIX | Gloo | Istio Gateway |
|---|---|---|---|---|
| 语言 | Lua | Lua | Go | Go |
| 代理 | Nginx | Nginx | Envoy | Envoy |
| 活跃度 | 高 | 中 | 中 | 高 |
| 开源协议 | Apache2.0 | Apache2.0 | Apache2.0 | Apache2.0 |
| 容器集成 | 自带数据面、控制面 | 自带数据面、控制面 | 作为控制面适配Envoy | 作为控制面适配Envoy |
| 路由策略 | host,path,method | host,path,method | header,query param,method,path,function | Host,head,path |
| 限流 | 支持 | 支持 | 商业版 | 基于Envoy全局限流 |
| 拓展 | 中 | 中 | 高 | 高 |
| 部署成本 | 中 | 中 | 中 | 中 |
| 商业服务 | 有 | 有 | 有 | 无 |
| 二次成本 | 高 | 高 | 高 | 高 |
| 学习成本 | 中 | 中 | 高 | 高 |
| 网格集成 | 中 | 中 | 高 | 高 |
| 可观察性 | 中 | 中 | 高 | 高 |
对比总结
- 向云原生、K8S、Istio靠拢
- API网关和服务网格正朝着融合的方向发展
- 动态服务发现能力集成
- 插件系统丰富
- 配置动态扩充
- HTTP，gRPC，Websocket等多协议支持
- 性能、容灾、流量治理能力强悍
- 学习成本、运维成本、二次开发成本高
轻舟网关
- 一个基于 Istio + Envoy 构建的高性能、可扩展、功能丰富的云原生API网关。
- 提供请求代理、动态路由、负载均衡、限流、熔断、健康检查、安全防护等功能，可用于微服务网关、七层负载均衡、Kubernetes Ingress、Serverless网关等应用场景。
- 数据面 - Envoy - 南北向流量代理
- 控制面 - Istio - 生成对应的xDS配置，并下发给Envoy
选择原因
- 技术路线：基于领先的网络代理组件 Envoy 构建，具备丰富的功能、优异的性能与可观测性
- 扩展性：可用于生产的增强级 Lua 扩展框架 Rider；基于 WebAssembly 的多语言扩展插件能力
- 多场景：具备支撑微服务网关、七层负载均衡、Kubernetes Ingress、Serverless网关等多种场景能力
- 云原生：以云原生标准数据面组件 Envoy 作为核心引擎，天然亲和云原生；可作为 Kubernetes、Service Mesh、Serverless 的 Ingress、Gateway 实现
- API生态与集成：以 API 为中心的生态管理，提供数百种工业级协议快速集成能力
- 控制平面：易用的控制台进行网关、服务、路由等多维度管理，简化使用者操作
轻舟特性
- HTTP、gRPC、Websocket 等多协议代理
- 支持 Kubernetes 等注册中心服务发现
- L7 流量代理、连接池配置
- 基于请求参数的动态路由、主动被动健康检查策略、丰富的负载均衡算法
- 多场景限流、熔断、降级、重试等流量治理功能
- IP黑白名单控制、认证鉴权等安全防护功能
- 自定义Header黑白名单，内置UA、Refer黑白名单
- 得益于 Envoy 优异的性能，单实例性能可达10w TPS以上
- 丰富的可观测性，可以对接诸如Prometheus等组件
