关于阿里云:Higress-Nacos-微服务网关最佳实践

作者：澄潭

在去年 11 月的云栖大会上，咱们开源了云原生网关 Higress，时隔 2 月，Higress 的 Github 我的项目曾经播种了 700+ star，以及大量社区小伙伴的关注。在社区的交换中咱们发现有不少微服务开发者在应用如 Spring Cloud Gateway/Zuul 等微服务网关对接 Nacos 注册核心实现微服务的路由，并且心愿理解迁徙到 Higress 网关能带来哪些益处。

Higress 的 Github 我的项目
https://github.com/alibaba/hi…

本文将介绍 Higress 组合 Nacos 作为微服务网关能力，并介绍微服务网关倒退的两个趋势，为网关的选型指明路线：

• 趋势一：对立 API 规范，向云原生微服务架构演进
• 趋势二：合并平安 & 流量网关，向 DevSecOps 演进

Higress：Nacos 的最佳拍档

Higress 和 Nacos 其实是师出同门——阿里中间件团队。在 Higress 撑持阿里外部业务的阶段，Higress 就曾经搭配 Nacos 作为微服务网关应用，凭借高性能撑持了双十一的洪峰流量；到了云产品商业化阶段，Higress 和 Nacos 持续基于阿里云 MSE（Microservices Engine）产品，严密合作演进产品性能；Higress 开源之后，如果想要自建微服务网关，抉择 Higress 配合 Nacos 应用，具备以下劣势：

1. 比照 Spring Cloud Gateway/Zuul 等传统 Java 微服务网关性能高出 2-4 倍 ，能够显著升高资源老本
2. 作为云原生网关，实现了 Ingress/Gateway API 规范，兼容 Nginx Ingress 大部分注解，反对业务渐进式向基于 K8s 的微服务架构演进
3. 与 Dubbo/OpenSergo/Sentinel 等开源微服务生态深度整合，提供最佳实际

Higress 的装置部署请点击原文参考 Higress 官网文档，这里默认曾经装置好 Higress，搭配 Nacos 应用的具体形式如下：

配置服务起源

apiVersion: networking.higress.io/v1
kind: McpBridge
metadata:
  name: default
  namespace: higress-system
spec:
  registries:
    # 定义一个名为“production”的服务起源
  - name: production
    # 注册核心类型是 Nacos 2.x，反对 gRPC 协定
    type: nacos2  
    # 注册核心的拜访地址，能够是域名或者 IP
    domain: 192.xxx.xx.32
    # 注册核心的拜访端口，Nacos 默认都是 8848
    port: 8848
    # Nacos 命名空间 ID
    nacosNamespaceId: d8ac64f3-xxxx-xxxx-xxxx-47a814ecf358    
    # Nacos 服务分组
    nacosGroups:
    - DEFAULT_GROUP
    # 定义一个名为“uat”的服务起源
  - name: uat
    # 注册核心类型是 Nacos 1.x，只反对 HTTP 协定
    type: nacos
    # 注册核心的拜访地址，能够是域名或者 IP
    domain: 192.xxx.xx.31
    # 注册核心的拜访端口，Nacos 默认都是 8848
    port: 8848
    # Nacos 命名空间 ID
    nacosNamespaceId: 98ac6df3-xxxx-xxxx-xxxx-ab98115dfde4    
    # Nacos 服务分组
    nacosGroups:
    - DEFAULT_GROUP

咱们通过 McpBridge 资源配置了两个服务起源，别离取名“production”和“uat”，须要留神的是 Higress 对接 Nacos 同时反对 HTTP 和 gRPC 两种协定，倡议将 Nacos 降级到 2.x 版本，这样能够在上述配置的 type 中指定“nacos2”应用 gRPC 协定，从而更疾速地感知到服务变动，并耗费更少的 Nacos 服务端资源。

基于 McpBridge 中的 registries 数组配置，Higress 能够轻松对接多个且不同类型的服务起源（Nacos/Zookeeper/Eureka/Consul/…），这里对于 Nacos 类型的服务起源，反对配置多个不同命名空间，从而实现不同命名空间的微服务能够共用一个网关，升高自建微服务网关的资源老本开销。

配置 Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.io/destination: service-provider.DEFAULT-GROUP.d8ac64f3-xxxx-xxxx-xxxx-47a814ecf358.nacos
  name: demo
  namespace: default
spec:
  rules:
  - http:
      paths:
      - backend:
          resource:
            apiGroup: networking.higress.io
            kind: McpBridge
            name: default
        path: /
        pathType: Prefix

和常见的 Ingress 在 backend 中定义 service 不同，这里基于 Ingress 的 resource backend 将下面定义服务起源的 McpBridge 进行关联。并通过注解“higress.io/destination”指定路由最终要转发到的指标服务。对于 Nacos 起源的服务，这里的指标服务格局为：“服务名称. 服务分组. 命名空间 ID.nacos”，留神这里须要遵循 DNS 域名格局，因而服务分组中的下划线 ’_’ 被转换成了横杠 ’-‘。

丰盛的微服务网关能力

Higress 在微服务发现的根底上，提供了多种实用的微服务网关能力，这里以“灰度公布”和“自定义扩大”进行举例，更多能力能够点击原文参考 Higress 官网文档进行理解。

灰度公布

Higress 齐全兼容了 Nginx Ingress 的金丝雀（Canary）相干注解，如下所示，能够将带有 HTTP Header 为 x -user-id: 100 的申请流量路由到灰度服务中。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.io/destination: service-provider.DEFAULT-GROUP.98ac6df3-xxxx-xxxx-xxxx-ab98115dfde4.nacos
    nginx.ingress.kubernetes.io/canary: 'true'
    nginx.ingress.kubernetes.io/canary-by-header: x-user-id
    nginx.ingress.kubernetes.io/canary-by-header-value: '100'
  name: demo-uat
  namespace: default
spec:
  rules:
  - http:
      paths:
      - backend:
          resource:
            apiGroup: networking.higress.io
            kind: McpBridge
            name: default
        path: /
        pathType: Prefix

您还能够基于 OpenKruise Rollout 让灰度公布和服务部署过程联动，从而实现渐进式交付，具体能够参考这篇文章《Higress & Kruise Rollout: 渐进式交付为利用公布保驾护航》

自定义扩大

作为微服务网关，须要在微服务架构中承当局部通用逻辑的解决，例如认证鉴权，平安防护等。通用的逻辑无奈满足多样性的业务场景，Higress 能够反对开发者增加自定义解决逻辑。与 Spring Cloud Gateway 等传统微服务网关须要开发者本人在 Gateway 代码中加 Filter 不同，Higress 反对开发者应用多种语言编写 Wasm 插件，并动静加载失效，插件失效过程无需重启网关，变更插件逻辑对流量齐全无损。

下例是一个屏蔽特定申请的 Wasm 插件，当申请 url 中呈现“swagger.html”时将被间接回绝拜访，插件实现代码参考：

https://github.com/alibaba/hi…

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: request-block
  namespace: higress-system
spec:
  selector:
    matchLabels:
      higress: higress-system-higress-gateway
  pluginConfig:
    block_urls:
    - "swagger.html"
  url: oci://higress-registry.cn-hangzhou.cr.aliyuncs.com/plugins/request-block:1.0.0

Wasm 插件的开发 & 编译 & 镜像推送形式能够参考这篇文章《Higress 实战：30 行代码写一个 Wasm Go 插件》

微服务网关发展趋势

趋势一：对立 API 规范，向云原生微服务架构演进

基于一套 API 能够有不同的实现，既让用户不被具体实现锁定，又桥接了技术演进的鸿沟。API 能够说是整个云原生架构的基石，或者有一天 K8s 会隐没，然而面向形象的 API 规范定会长存。在流量网关畛域，Ingress API 曾经成为规范。而对于微服务网关等更简单的应用场景，Ingress 受限于其简略的协定字段，须要通过 Ingress 注解等形式进行能力扩大，难以被标准化。因而诸如 Contour、Emissary、Kong、APISIX 等都定义了本人的 HTTP 路由等 CRD，网关的 API 定义开始出现碎片化。

这一背景之下，Gateway API 应运而生，并且在过来的一年里从 alpha 演进到了 beta 阶段。尽管目前 Gateway API 还未定稿，协定仍会产生变动，不倡议用于生产，但 API 对立趋势曾经不可阻挡，只是工夫的问题。下图是 Gateway API 的一个用例场景，不同于 Ingress API，将集群运维和业务运维的职责进行了划分，这样业务开发人员不再须要关怀网站证书等集群级的细节，只专一于业务自身的 DevOps，集群运维工作能够交给 SRE 人员进行对立解决。

Higress 目前采纳 Ingress 注解的能力来实现能力扩大，并兼容了 Nginx Ingress 大部分罕用注解，且具备平滑迁徙到 Gateway API 的能力。

Higress 为传统微服务架构，提供了渐进式的形式，向基于 K8s 的云原生微服务架构演进：能够通过 Nacos 发现部署在 K8s 之外的服务，从而实现了网关后端微服务能够和 K8s 解耦，业务团队能够将微服务一一迁徙至 K8s，而不必放心网关层的流量影响。

从传统微服务网关迁徙到 Higress，再渐进式实现整个微服务架构的云原生化，是一个理智的抉择。

趋势二：合并平安 & 流量网关，向 DevSecOps 演进

Higress 提出了将平安、流量、微服务网关三合一的概念，首先来看一个典型的多层网关架构：

在这个架构中，用 WAF 网关实现平安能力，Ingress 网关实现集群入口网关能力（非 K8s 场景或会部署一层 Nginx），SCG（Spring Cloud Gateway）实现微服务网关能力。这样的架构下，须要对每一层网关都进行容量评估，每一层网关都是潜在的瓶颈点，都可能须要进行扩容。这样造成的资源老本和运维人力老本都是微小的。并且每多一层网关，就多一层可用性危险。一旦呈现可用性问题，多层网关会导致问题定位复杂度显著回升，对应的均匀故障复原工夫（MTTR）将大幅减少。

采纳三合一的架构中，能够显著降低成本，并进步零碎整体可用性。同时这也合乎 DevSecOps 的微服务演进趋势，微服务开发者能够更多地从业务接口视角关注安全性，而不是采纳所有路由一刀切的 WAF 防护模式。

技术架构演进的背地是组织架构演进，这也是微服务 DevOps 始终在强调的，要围绕开发者为外围，从而晋升微服务开发效率。向 DevSecOps 演进并没有捷径，仍然须要开发角色和运维角色之间的双向奔赴，突破传统开发与运维之间的壁垒，造成从开发、部署、平安经营这样一个全功能化的麻利团队。

通过 Higress 将网关合并作为向 DevSecOps 演进的抓手，是一个理智的抉择。

参加 Higress 社区

Higress 开源奉献小组正在炽热招募贡献者。如果您有工夫，有激情，有志愿，欢送分割社区退出开源奉献小组，一起独特欠缺 Higress，一起主导下一代云原生网关的设计和实现。

社区官网 ：https://higress.io

社区开发者群 ：

社区交换群 ：