Higress 开源后,我们整理了开发者最关心的 15 个问题
发布时间 2024-08-12
云原生架构下,网关承载着流量管理、服务调用、安全管理等多重职能,在稳定性、性能、安全性、易用性上存在着更高的要求。在 CNCF Landscpae 编排和管理的 API Gateway 领域中,已经有不少开源的网关选择,开发者们也有着不小的选型诉求。
云原生网关 Higress 开源后,引起了开发者们的热烈讨论,我们整理了大家在 GitHub、钉群、微信群讨论的问题,并将回答汇总如下,方便各位更准确的读懂 Higress,也非常欢迎您和我们一起共建、定义 Higress。
Q1:Higress 现在适合上生产系统么?
A1:推荐发布 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:目前还没有现成的,需要您自行构建。 目前 Docker 镜像都是提供的,直接部署可以使用
Q9:Higress 能脱离 istio 环境,只基于 Docker 运行吗?
A9:当前是需要依赖 K8s 的,后续支持 Nacos/Consul 等注册中心,与 K8s 松耦合。
Q10:Higress 除了运行在 K8s 上,是否支持在虚拟机和物理机上运行呢?
A10:还不支持,但后续会通过 Nacos 做配置管理,来支持这个需求。
Q11:Higress 的 Dashboard 会对外开源么?
A11:有计划的,非常希望借助社区的力量来加速 Dashboard 的开源,好用的后端开源项目需要搭配好用的控制台。
Q12:当前开源的版本支持 Waf 功能么,有相关的最佳实践么?
A12:支持的,并且会遵循 WASM 插件的社区生态,这方面的最佳实践会逐步提供出来。
Q13:Higress 是否支持弹性伸缩,网关是无状态的么?
A13:Higress 基于 K8s HPA,是支持弹性伸缩的,网关无状态,是个 deployment 。
Q14:Higress 有 roadmap 了么?
A14:最近的 milestone 是 0.6.0,更新内容包括:
- Higress Controller 提供管控平面的 RESTful API
- 发布 Higress CLI 工具,简化安装、升级、运维步骤
- 推出 Higress Console,支持域名/路由/服务管理的 UI 交互操作
- 提供开箱即用的指标监控和日志分析能力
近期的 roadmap 如下:
Q15:如何加入 Higress 社区进行贡献,已经迫不及待了。
A15:我们非常欢迎大家通过各种形式参与到我们项目的建设中,包括但不限于:
- 架构设计
- 模块设计
- 代码实现
- Bug Fix
- Demo 样例
- 文档、网站和翻译
具体的参与方法可以参见我们官网的开发者指引:
https://higress.io/zh-cn/docs/developers/contributor-guide
或与 higress@googlegroups.com 联系。
实际上,我们并不拘泥于贡献的形式,开发者提出的每一个 issue,无论是 Bug Report、改进建议或者甚至是问题咨询都代表着对项目的关注和帮助。希望 Higress 项目和社区一起健康成长,成为云原生网关领域一个优秀的解决方案。