目录
五、Higress 为什么选择以 Envoy + Istio 为内核构建？
一、业界背景
当我们深入了解当前的网关市场，会发现有许多流行的选择，如 Nginx、Istio、Kong、Apisix 等。这些网关产品各有特点，适用于不同的场景。
然而，随着微服务架构的演进和云原生技术的普及，业务需求也在不断变化。
在某些场景中，我们需要的不仅仅是一个简单的流量网关，更需要一个能够与微服务框架无缝集成、提供丰富功能和灵活扩展的解决方案。
二、就这样诞生了
在这样的背景下，Higress 应运而生。它源于阿里巴巴内部电商、交易等核心生产场景的实践沉淀，以开源 Istio 与 Envoy 为核心构建的下一代云原生网关，是一款标准化、高集成、易扩展、热更新的云原生网关。
与其他网关相比，Higress 不仅具备强大的流量管理能力，还集成了安全网关、服务管理插件和自定义插件等功能。
具体来说，Higress 的特点如下：
-
高集成性：Higress 与 K8s 和微服务生态紧密集成，支持 Nacos 注册和配置、Sentinel 限流降级等能力。这意味着可以在一个统一的平台上管理流量、安全和微服务。
-
热更新能力：Higress 支持规则变更毫秒级生效等热更新能力，大大提高了系统的灵活性和响应速度。
-
丰富的插件生态：Higress 不仅提供了默认的插件，还支持自定义插件的扩展。这意味着可以根据业务需求定制自己的网关功能。
-
安全性：Higress 集成了多种安全功能，如限流、黑白名单等，确保系统的安全性和稳定性。
三、架构实现
通过 Higress 的介绍，我们可以看到它针对的是日益复杂的微服务架构和云原生应用场景。在业务快速迭代和需求多变的今天，Higress 提供了一个高效、灵活、安全的网关解决方案，帮助开发者和运维人员更好地应对挑战。
Higress 实现了安全防护网关、流量网关、微服务网关三层网关合一，可以显著降低网关的部署和运维成本。
四、覆盖场景
我为什么写这篇文章的主要原因，就是因为我们重度依赖商业化版本的 kong，近一段时间，也一直准备找一个平替网关，不仅能覆盖现有的场景，还能扩充更多的场景覆盖。
我们公司业务体系下的网关：
-
以 HAProxy、Nginx Ingress 为基础的流量网关；
-
Spring Cloud 微服务体系的 Spring Cloud Gateway；
-
作为 API 网关的 Kong；
-
服务网格体系下的 Istio Ingress Gateway。
Higress 所支持的网关场景：
-
Kubernetes Ingress 网关：
Higress 可以作为 K8s 集群的 Ingress 入口网关, 并且兼容了大量 K8s Nginx Ingress 的注解，可以从 K8s Nginx Ingress 快速平滑迁移到 Higress。
支持 Gateway API 标准，支持用户从 Ingress API 平滑迁移到 Gateway API。
-
微服务网关：
Higress 可以作为微服务网关, 能够对接多种类型的注册中心发现服务配置路由，例如 Nacos, ZooKeeper, Consul, Eureka 等。
并且深度集成了 Dubbo, Nacos, Sentinel 等微服务技术栈，基于 Envoy C++ 网关内核的出色性能，相比传统 Java 类微服务网关，可以显著降低资源使用率，减少成本。
-
安全防护网关：
Higress 可以作为安全防护网关， 提供 WAF 的能力，并且支持多种认证鉴权策略，例如 key-auth, hmac-auth, jwt-auth, basic-auth, oidc 等。
五、Higress 为什么选择以 Envoy + Istio 为内核构建？
在容器化的云原生大背景下，Kubernetes已经成为了基础设施与上层应用的标准接口，Kubernetes集群天然的内外网络隔离环境，使得外部流量进入Kubernetes集群内部需要通过入口网关，因此Kubernetes通过Ingress来规范化入口网关的定义与标准，虽然Ingress标准存在一些如路由表达能力弱等不足之处，社区已经在积极推进Gateway API标准定义来解决，但不可否认的是目前Ingress标准仍然占据主流。
从 CNCF 的年度报告中也能看得出来，Envoy 的增长是最快的，已经从2019年的不足20%增长为2020年的37%，且仅在 Nginx Ingress 之后，增长势头非常迅猛，这说明选择以 Envoy 为内核是符合云原生发展趋势的，而且随着 Service Mesh 逐步被大众认可，Istio + Envoy 的体系可以同时覆盖 Mesh 与 Ingress 领域，实现以一套技术架构调度东西向、南北向全域流量的目标，这对用户来说也是非常有意义的。
六、它的优势
-
生产等级
脱胎于阿里巴巴2年多生产验证的内部产品，支持每秒请求量达数 十万级 的大规模场景。
彻底摆脱 reload 引起的流量抖动，配置变更 毫秒级 生效且业务无感。
-
平滑演进
支持 Nacos/Zookeeper/Eureka 等多种注册中心，可以不依赖 K8s Service 进行服务发现，支持非容器架构平滑演进到云原生架构。
支持从 Nginx Ingress Controller 平滑迁移，支持平滑过渡到 Gateway API，支持业务架构平滑演进到 ServiceMesh。
-
兼收并蓄
兼容 Nginx Ingress Annotation 80%+ 的使用场景，且提供功能更丰富的 Higress Annotation 注解。
兼容 Ingress API/Gateway API/Istio API，可以组合多种 CRD 实现流量精细化管理。
-
便于扩展
提供 Wasm、Lua、进程外三种插件扩展机制，支持多语言编写插件，生效粒度支持全局级、域名级，路由级。
插件支持热更新，变更插件逻辑和配置都对流量无损。
七、来看看兼容性
1）替代 Nginx Ingress：
Higress 可以作为 K8s 集群的 Ingress 入口网关, 并且兼容了大量 K8s Nginx Ingress 的注解，可以从 K8s Nginx Ingress 快速平滑迁移到 Higress。
如下是一个基于 Higress 自带注解来实现 REST 路由，并兼容 Nginx Ingress 注解重写路径的示例：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
# 兼容 Nginx Ingress 注解
nginx.ingress.kubernetes.io/rewrite-target: /
# Higress 注解，支持 method/header/query 匹配路由
higress.io/match-method: POST
higress.io/exact-match-query-higressQuery: hi
higress.io/prefix-match-header-x-higress-header: hi
name: foo
spec:
ingressClassName: higress
rules:
- host: foo.example.com
http:
paths:
- pathType: Prefix
path: /foo
backend:
service:
name: foo-service
port:
number: 5678
值得一提的是，Nginx Ingress 的 Lua 代码性能比较差，Higress 对比 Nginx Ingress 的性能提升很大！
2）替代 Spring Cloud Gateway：
Spring Cloud 微服务体系下，作为微服务网关必须跟微服务注册中心进行对接，实现服务发现。Higress 提供了 McpBridge 这个 CRD，可以很方便地跟多种注册中心对接，我们使用的 Spring Cloud 注册中心是 Nacos，McpBridge 配置如下：
apiVersion: networking.higress.io/v1
kind: McpBridge
metadata:
name: default
namespace: higress-system
spec:
registries:
# 定义一个名为 my-nacos 的服务来源
- name: my-nacos
# 注册中心类型是 Nacos 2.x，支持 gRPC 协议
type: nacos2
# 注册中心的访问地址，可以是域名或者IP
domain: 127.0.0.1
# 注册中心的访问端口，Nacos 默认都是 8848
port: 8848
# Nacos 命名空间 ID
nacosNamespaceId: d8ac64f3-xxxx-xxxx-xxxx-47a814ecf358
# Nacos 服务分组
nacosGroups:
- DEFAULT_GROUP
接着，配置 Ingress 转发到注册在 Nacos 上的服务 user-center：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.io/destination: user-center.DEFAULT-GROUP.d8ac64f3-xxxx-xxxx-xxxx-47a814ecf358.nacos
name: user
namespace: default
spec:
rules:
- http:
paths:
- backend:
resource:
apiGroup: networking.higress.io
kind: McpBridge
name: default
path: /
pathType: Prefix
Spring Cloud 微服务无需做任何改造，即可接入 Higress 网关。
对比 Spring Cloud Gateway/Zuul 等传统 Java 微服务网关， Higress 的性能高出 2 倍以上，可以显著降低资源成本。
3）替代 Kong：
我们的 API 网关最初是基于 Kong 来构建的，主要使用了 Kong 的 Key Auth/Basic Auth/JWT Auth/HMAC Auth 插件，而 Higress 也都提供了这些插件能力：
以 Key Auth 为例，通过 Higress 提供的 WasmPlugin CRD 做如下配置即可：
apiVersion: extensions.higress.io/v1alpha1
kind: WasmPlugin
metadata:
name: key-auth
namespace: higress-system
spec:
# 全局配置，配置认证规则
defaultConfig:
consumers:
- credential: 2bda943c-xxxx-xxxx-xxxx-00163e1250b5
name: consumer1
- credential: c8c8e9ca-xxxx-xxxx-xxxx-e700dcc40e35
name: consumer2
keys:
- x-api-key
# 从请求header识别key
in_header: true
# 开启全局认证，consumer未识别将拒绝访问
global_auth: true
# 匹配规则，配置授权规则
matchRules:
# 路由级生效配置，匹配default命名空间下名为foo的ingress
- ingress:
- default/foo
config:
# 仅允许 consumer1 访问
allow:
- consumer1
# 域名级生效配置
- domain:
- www.test.com
- *.example.com
config:
# 仅允许 consumer1 访问
allow:
- consumer2
url: oci://higress-registry.cn-hangzhou.cr.aliyuncs.com/plugins/key-auth:1.0.0
发起一个认证请求，因为 xxx.exmaple.com 仅授权了 consumer2 访问，所以下面这个 curl 命令将返回 403：
$ curl http://xxx.example.com/test -H 'x-api-key: 2bda943c-xxxx-xxxx-xxxx-00163e1250b5'
Higress 提供了更灵活的自定义插件机制，相比 Kong 新增插件需要重新部署网关，Higress 可以动态扩展并热更新插件逻辑，对流量完全无损，而且也可以支持多种语言开发，不局限于 Lua 语言。
4）替代 Istio Ingress Gateway
Higress 本身并未对 Istio 有强依赖，因此默认关闭了 Istio 的 API 支持，需要通过 helm 参数配置开启该支持：
$ helm upgrade higress -n higress-system higress.io/higress --reuse-values --set global.enableIstioAPI=true
开启后，可以直接使用 Istio API 来管理 Higress 上的路由：
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: devops
namespace: higress-system
spec:
selector:
higress: higress-system-higress-gateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- devops.com
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: devops
namespace: higress-system
spec:
gateways:
- higress-system/devops
hosts:
- devops.com
http:
- name: default
route:
- destination:
host: devops.default.svc.cluster.local
基于 Istio API，Higress 也支持 TCP 路由，这可以替代我们之前使用 HAProxy 来代理 MySql 等中间件的功能，例如：
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: mysql
namespace: higress-system
spec:
selector:
higress: higress-system-higress-gateway
servers:
- hosts:
- '*'
port:
name: tcp
number: 3306
protocol: TCP
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: mysql
namespace: higress-system
spec:
gateways:
- mysql
hosts:
- '*'
tcp:
- match:
- port: 3306
route:
- destination:
host: mysql
port:
number: 3306
subset: v1
八、在标准 K8S 集群中使用
Higress 网关由控制面组件 higress-controller 和数据面组件 higress-gateway 组成。
-
higress-gateway 负责承载 数据流量，
-
higress-controller 负责管理 配置下发。
Helm 安装命令：
$ helm repo add higress.io https://higress.io/helm-charts
$ helm install higress higress.io/higress -n higress-system --create-namespace
获取 Higress Gateway 的 LoadBalancer IP，并记录下来。后续可以通过该 IP 的 80 和 443 端口访问 Higress Gateway。
$ kubectl get svc -n higress-system higress-gateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
常用安装参数：
| 参数名 | 参数说明 | 默认值 |
|---|---|---|
| 全局参数 | --- | --- |
| global.local | 如果要安装至本地 K8s 集群（如 Kind、Rancher Desktop 等），请设置为 true | false |
| global.ingressClass | 用于过滤被 Higress Controller 监听的 Ingress 资源的 IngressClass。在集群内部署了多个网关时，可以使用这一参数来区分每个网关的职责范围。IngressClass 有一些特殊的取值：1. 如果设置为“nginx”，Higress Controller 将监听 Ingress 为 nginx 或为空的 Ingress 资源。2. 如果设为空，Higress Controller 将监听 K8s 集群内的全部 Ingress 资源。 | higress |
| global.watchNamespace | 如果值不为空，Higress Controller 将只会监听指定命名空间下的资源。当基于 K8s 命名空间进行业务系统隔离时，若需要对每个命名空间部署一套独立的网关，可以通过这一参数来限制 Higress 监听指定命名空间内的 Ingress。 | "" |
| global.disableAlpnH2 | 是否在 ALPN 中禁用 HTTP/2 协议 | true |
| global.enableStatus | 若为true， Higress Controller 将会更新 Ingress 资源的 status 字段。为避免从 Nginx Ingress 迁移过程中，覆盖 Ingress 对象的 status 字段，可以将这一参数设置为false，这样 Higress 默认就不会将入口 IP 写入 Ingress 的 status 字段。 | true |
| global.enableIstioAPI | 若为true，Higress Controller 将同时监听 istio 资源 | false |
| global.enableGlobalAPI | 若为true，Higress Controller 将同时监听 Gateway API 资源 | false |
| global.onlyPushRouteCluster | 若为true，Higress Controller 将会只推送被路由关联的服务 | true |
| 核心组件参数 | --- | --- |
| higress-core.gateway.replicas | Higress Gateway 的 pod 数量 | 2 |
| higress-core.controller.replicas | Higress Controller 的 pod 数量 | 1 |
| 控制台参数 | --- | --- |
| higress-console.replicaCount | Higress Console 的 pod 数量 | 1 |
| higress-console.service.type | Higress Console 所使用的 K8s Service 类型 | ClusterIP |
| higress-console.web.login.prompt | 登录页面上显示的提示信息 | "" |
| higress-console.o11y.enabled | 若为 true，将同时安装可观测性套件（Grafana + Promethues） | false |
| higress-console.pvc.rwxSupported | 标识目标 K8s 集群是否支持 PersistentVolumeClaim 的 ReadWriteMany 操作方式。 | true |
九、Higress 的管理 UI
丰富的可观测：
Higress Console 内置了一套基于 Prometheus + Grafana 的监控套件，但默认不会安装。
在使用 Helm 安装 Higress 时，可以通过在命令行中添加 --set higress-console.o11y.enabled=true 参数启用这一监控套件。
$ helm repo add higress.io https://higress.io/helm-charts
$ helm install higress -n higress-system higress.io/higress --create-namespace --render-subchart-notes --set higress-console.o11y.enabled=true
小提示：Grafana&Prometheus 可以使用内置的，也可对接自建的。
丰富的路由能力：
通过上面定义的服务发现机制，发现的服务会出现在服务列表中；
创建路由时，选择域名，定义路由匹配机制，再选择目标服务进行路由；
路由策略里支持对特定路由生效插件。
域名和证书：
可以创建管理 TLS 证书，并配置域名的 HTTP/HTTPS 行为，域名策略里支持对特定域名生效插件。
强大的插件扩展：
官方提供了多种插件，用户也可以 开发 自己的插件，构建成 docker/oci 镜像后在控制台配置，可以实时变更插件逻辑，对流量完全无损。
十、大家可能关心的一些问题
Q1：Higress 现在适合上生产系统么？
A1：根据项目和团队的实际情况，评估是否已经满足了生产环境的要求。这包括但不限于功能测试、性能测试、安全测试等方面。在 Higress 的情况下，建议在发布 GA(General Availability)版本后进行生产部署，以获得更好的稳定性和安全性。
Q2：Higress 和 Envoy Gateway 有什么区别？
A2：Higress 是基于 Envoy 实现和扩展的，和 Envoy Gateway 一样遵循 Gateway API 标准，不同的是，还提供了：
-
Waf 防护、认证鉴权等安全插件能力
-
多注册中心、协议转化、限流降级等服务管理插件能力，例如，对于传统使用 Dubbo 的微服务用户希望使用原生 RPC 方式暴露对外服务，但通常提供外部访问的服务以使用 HTTP 为主，为了帮助 Dubbo 用户降低服务暴露的开发成本，Higress 提供了 HTTP 转 Dubbo 协议功能，且通过 Console 为用户提供白屏化的配置方式，某客户使用后反馈“这是业界完成度最高的 HTTP 转 Dubbo 协议”功能。
-
支持 WASM、Lua 等自定义插件，例如 Nginx 用户，我们还会支持进程外插件，满足多语言用户诉求，尤其是 Java 用户因现阶段 Java 社区对 WebAssembly 支持尚不完善但又希望对网关进行扩展的诉求。
Q3：Higress 和阿里巴巴的另一款开源网关 Tengine 有哪些不同？
A3：Tengine 是基于 Nginx 实现，通过 Lua 扩展，Higress 基于 istio + Envoy，通过 WASM 扩展，在技术架构上不太一样，开发者可以根据业务场景来进行选型。Higress 已经支持 Nginx Ingress 注解平滑迁移的能力，满足部分用户期望迁移到 Higress 但又不希望重新配置网关的诉求，同时 Higress 打破了 Nginx Ingress 只能关联单个 K8s 集群的限制，支持关联多个 K8s 集群，即可以将 Higress 作为统一接入网关使用，同时又可以享受 Ingress 的红利。
Q4：Higress 阿里云上的 MSE 云原生网关有什么关系？是基于此孵化的开源项目吗？
A4：MSE 云原生网关是 Higress 的商业化版本，能力上是有差异的，主要体现在性能、稳定性、易用性和安全性上，因为这些都非常依赖于云上的基础设施能力，详细资源还在整理，后续会在 MSE 的产品页和文档页进行展示，方便大家选型。当然，Higress 处于演进过程中，MSE 云原生网关上的哪些能力对外进行开源，我们会和社区一起定义，开源上我们也会规划一个插件市场。
Q5：Higress 将流量网关、微服务网关、安全网关三合一，这种做法业内是否通用？是否是一种发展趋势？
A5：流量网关、微服务网关、安全网关在业界中一直都有使用，部署形态大多采用各自使用独立集群部署，在K8s 主导的容器化背景下，K8s 通过 Ingress 标准化了入口网关，传统流量网关、微服务网关、安全网关独立部署模式在 K8s 下就显得部署成本高、运维复杂，站在用户角度只需要一款功能丰富的高集成网关即可，基于此我们判断高集成网关会是未来的一种发展趋势。
Q6：Higress 对上游进行了定制，是否存在着无法享受社区福利、还要背负生态跟进的问题？
A6：Higress 核心代码基本采用可插拔的 Filter 扩展，功能新增也尽量遵循可扩展原则，在上游跟进上为保持自身稳定性也不会马上跟进最新版本，比如 APISIX、Kong 内核都是基于 Nginx，但他们依然发展的很好，事实也说明上游跟进不会成为项目发展障碍。
Q7：Higress 支持 Nacos 的服务发现，是否有支持 Consul 的计划？
A7：Higress 和 Nacos 初步完成了整合，在整合完后，会提供给大家使用，Consul 的代码层面已经实现，生产还未验证，有计划开源和社区共建。
Q8：Higress 是否有离线部署版本？
A8：目前还没有现成的，可以拉取公网镜像推送到离线仓库进行构建。
Q9：Higress 能脱离 istio 环境，只基于 Docker 运行吗？
A9：当前是需要依赖 K8s 的，控制面在 istio 上，后续会考虑仅只依赖 Nacos 做控制。
Q10：Higress 除了运行在 K8s 上，是否支持在虚拟机和物理机上运行呢？
A10：还不支持，但后续会通过 Nacos 做配置管理，来支持这个需求。
Q11：Higress 的 Dashboard 会对外开源么？
A11：有计划的，非常希望借助社区的力量来加速 Dashboard 的开源，好用的后端开源项目需要搭配好用的控制台。
Q12：当前开源的版本支持 Waf 功能么，有相关的最佳实践么？
A12：支持的，并且会遵循 WASM 插件的社区生态，这方面的最佳实践会逐步提供出来。
Q13：Higress 是否支持弹性伸缩，网关是无状态的么？
A13：Higress 基于 K8s HPA，是支持弹性伸缩的，网关无状态，是个 deployment 。
扫一扫
6830
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
