共计 2925 个字符，预计需要花费 8 分钟才能阅读完成。
云原生架构下，网关承载着流量治理、服务调用、平安治理等多重职能，在稳定性、性能、安全性、易用性上存在着更高的要求。在 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：以后是须要依赖 K8 s 的，后续反对 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… 或与 higress@googlegroups.com 分割。
实际上，咱们并不拘泥于奉献的模式，开发者提出的每一个 issue，无论是 Bug Report、改良倡议或者甚至是问题征询都代表着对我的项目的关注和帮忙。心愿 Higress 我的项目和社区一起健康成长，成为云原生网关畛域一个优良的解决方案。
搭把手 & 直播预报
Higress 自 11 月 5 日开源后，曾经取得了 500+star，并在 GitHub Trend 上进入 Top4，可见在云原生网关开源有着较高的关注度和较多的利用需要。咱们邀请您在理解 Higress 的时候，再走近一步，例如奉献一份文档、提交一段代码，您就有可能成为 Higress 的第一批 Contributor 甚至 Committer。
咱们打算在 11 月 16 日在钉群和阿里云云原生视频号上线一场真直播，请 Higress 的研发同学分享 Higress，并和大家进行互动，欢送参加，参加形式是退出钉群或微信群，钉群反对在群内观看直播回放。
