政采云业务网关实践：使用 Higress 统一替代 APISIX/Kong/Istio Ingress

由于一些历史的背景，政采云平台在网关建设上遇到一些问题：

容器网关配置较多，配置方式多样，运维压力较大：

• 配置多是因为容器网关配置分为服务路由、搭建类路由、return/rewrite 类路由不同类型的路由。微服务架构使得服务数目多，搭建类平台的技术方案导致子域名非常多，网关的配置复杂度就是 MXN（M 是服务个数，N 是域名的个数），比如子域名个数约 400 多，服务个数约 500 多，整个配置量约 20w+；
• 搭建类平台子域名单独定义根路径转发，每个页面的分发路径随意填写，导致网关的配置需要支持到每个搭建页面到路径的映射关系配置；
• 业务的 return/rewrite 逻辑很多是业务服务迁移过程中产生的，旧的请求一直没有推动下线。一些网关规则配置以服务为中心管理，一些网关规则配置以域名为中心管理，各个服务的路由不唯一，经常会出现配置了网关规则不生效，运维需要排查哪里的配置冲突导致的该问题，并可能出现因一次变更影响其他路由规则的生效问题。

• 流量网关使用的是 openrestry，容器网关使用了 Istio IngressGateway，开放平台/业务网关使用了 Spring Cloud Gateway，旧的开放平台使用的是 kong，搭建网关对应的 node express，跨网网关（APISIX）等。虽然不同场景的网关对应不同开发团队，但不同的技术栈选型导致日常维护的工作量增大，同时也给后续的能力建设带来很多的问题。

业务诉求：

• 随着业务发展，业务研发团队对于网关有一些可扩展的能力诉求，比如说认证、安全管控、请求体修改的需求等。

网关配置治理

• 强化规范。基于目前的业务场景，以及后续可能需要支撑的业务场景，优化了域名使用规范，网关规则配置规范，并集成到日常的变更流程，强化规范的落地。

• 网关规则需要分层配置。网关配置分层基于不同工程师的负责范畴进行分层，分为域名层和服务层两部分。运维工程师负责域名层的配置，研发工程师负责服务层的配置。

• 网关规则的管理以应用为中心。应用需要涉及到资源，是有上线、下线等生命周期管理的，把服务层的网关规则跟应用绑定，即在元数据中心里面服务层网关规则就是应用的一个属性。服务层网关规则的生命周期就跟应用是一致的了。

• 网关技术栈统一就涉及到网关服务的选型。

技术栈统一是逐步达成的目标，不过从目前需要解决的问题紧急度上看，容器网关、业务网关需要合并，以一个技术栈解决网关配置治理、扩展能力的问题。经过社区活跃度、能力对比等多个维度的比较，最终筛选出 APISIX、Higress、Istio（IngressGateway）这三个网关服务。

• 插件能力加强。Higress 在开源的 wasm client 上做了封装，更方便开发者做插件的开发，比如做了插件生效的范围控制，并且社区已有很多插件能力可以直接使用。

• 扩展功能。Higress 在多数据源这块集成了多种主流注册中心，这些能力可以直接复用，不用重复建设；基于 Envoyfilter 提供了 http2rpc 的能力，并封装了单独的 CRD, 方便 http2dubbo 的配置。

APISIX 是一个比较优秀的云原生网关解决方案，底层基于 openresty，且在公司高速公路项目上也使用了 APISIX 做跨网络域的请求转发。不过考虑到目前网关重度使用场景是容器网关，该网关规则对应的是 virtualservice 资源，我们也有内部系统围绕 virtualservice 做了相关解决方案，原生支持 virtualservice 会简化迁移工作量，我们选择了 Higress。

最终我们继续选择 Istio CRD 做网关配置的资源。

1. 基于域名聚合功能不生效。为了优化变更速度，Higress 默认开启了 enableSRDS，该特性会按照域名隔离生效到 Envoy 里面的配置，因为我们业务场景下一个路由对应的子域名特别多，之前是开启了基于域名合并网关配置，在使用 Higress 会导致配置量大增，关闭了 enableSRDS 该问题就解决了。

2. 配置生效特别慢。在大量网关配置生效到 Higress 的时候会达分钟级别。经过 Higress 社区同学排查优化了这块逻辑，最终使用 Higress 配置的生效时间也是秒级的。

3. 在有冲突网关规则下发生效的时候 Istio 出现生效混乱。Istio 1.22.0 以下的版本都存在一个问题，在有冲突网关规则下发的时候会在特定条件下出现生效混乱的问题，刚好我这次做网关规则迁移过程中发现了该问题，在我给 Istio 社区提 bug 的时候，他们刚在 1.22.0 版本修复该问题。Higress 社区同学很快的帮忙 merge 该修复的 commit，并发布在 Higress1.4.1 版本中。

4. 在同样配置下，Higress 使用内存较高。从监控可以看到，在相同配置下，Higress Gateway 的内存使用明显比 Istio-IngressGateway 要高。经过 Higress 社区同学精简 Higress Gateway 的监控指标，两者也达到基本一致的资源使用。

业务网关项目除了引入 Higress 取代 IngressGateway 作为业务网关外，还重点做了网关规则治理。下面我介绍下网关分层的解决思路，与业务耦合比较紧密，供参考。

在网关规则治理上，结合目前网关规则的分层配置要求，我们定义了应用路由（appvirtualservice，简称 avs）的 CRD 资源，把路由配置分成两层，域名层和服务层。域名层对应了原来的 virtualservice 资源，服务层对应了 avs 资源，avs 是不带域名信息的，跟域名是分开的，研发人员操作的网关规则都是对应的 avs 资源，avs 资源最终会生效到 virtualservice 资源。

apiVersion: arch.cai-inc.com/v1kind: AppVirtualServicemetadata:  labels:    app: web-a-front    vsLayer: app  name: web-a-front  namespace: testspec:  http:  - match:    - uri:        prefix: /a-index    route:    - destination:        host: web-a-front        port:          number: 80

基于实际的使用场景，在 avs 资源定义中，我们还定义了 PriorityClass（支持高，中，低三个等级，默认是中）字段，通过该字段决定该规则生效的优先级，部分缓解原来依赖创建时间决定规则生效优先级的不可控问题。

② 回放流量使用 HEAD 请求。回放流量只需要验证转发逻辑的正确，为了避免影响到生产环境的流量，原来的请求 method 都会设置 HEAD，去掉参数和请求体内容进行回放。

创建新的网关实例，分层之后的网关规则生效到新的网关实例，在负载均衡侧基于流量比例 1%->5%->10%->20%->50%->100% 的比例逐渐放大新网关实例承载的流量比例。

业务网关项目初步建设的成果还是较显著的：

• 无感。整个业务网关的变更对业务研发侧基本是无感的，他们只是感知到有这种变更事件。

• 网关规则治理目标达成。网关规则按照域名层和服务层进行分层，域名层属于基础配置，服务层以应用为中心进行管理，整体网关规则的治理目标基本达成。

• 技术栈统一。业务网关（Higress）取代了容器网关（Istio IngressGateway），旧的开放平台（kong），跨网网关（APISIX），旧的业务网关（Spring Cloud Gateway），节省了相关服务所占的资源，同时节省了后续的维护成本。