Why Higress + Nacos Is the Ideal Cloud‑Native Gateway for Microservices

At the 2022 Cloud Xi conference, Alibaba open‑sourced the cloud‑native gateway Higress. Within two months its GitHub repository (https://github.com/alibaba/higress) earned over 700 stars, attracting many developers who currently use Spring Cloud Gateway or Zuul with Nacos for service routing and wonder about the benefits of migrating to Higress.

Why Combine Higress with Nacos?

Higress and Nacos are both products of Alibaba's middleware team. In internal use, Higress already paired with Nacos to handle the massive traffic of Alibaba's Double 11 shopping festival. In the commercial MSE (Microservices Engine) product, the two continue to evolve together. For teams building their own gateway, using Higress with Nacos offers:

Performance 2‑4× higher than traditional Java gateways such as Spring Cloud Gateway or Zuul, reducing resource costs.

Full cloud‑native support with Ingress/Gateway API compatibility, allowing gradual migration to a Kubernetes‑based architecture.

Deep integration with the Alibaba open‑source ecosystem (Dubbo, OpenSergo, Sentinel), providing best‑practice patterns.

Basic Setup

The following McpBridge resource configures two service registries—one using Nacos 2.x (gRPC) and another using Nacos 1.x (HTTP). Upgrading Nacos to 2.x is recommended to enable the nacos2 type and benefit from faster service change detection and lower server load.

apiVersion: networking.higress.io/v1
kind: McpBridge
metadata:
  name: default
  namespace: higress-system
spec:
  registries:
  - name: production
    type: nacos2
    domain: 192.xxx.xx.32
    port: 8848
    nacosNamespaceId: d8ac64f3-xxxx-xxxx-xxxx-47a814ecf358
    nacosGroups:
    - DEFAULT_GROUP
  - name: uat
    type: nacos
    domain: 192.xxx.xx.31
    port: 8848
    nacosNamespaceId: 98ac6df3-xxxx-xxxx-xxxx-ab98115dfde4
    nacosGroups:
    - DEFAULT_GROUP

With this configuration, Higress can discover services from multiple registries (Nacos, Zookeeper, Eureka, Consul, etc.) and even multiple namespaces within Nacos, enabling a single gateway to serve many microservice domains.

Ingress Integration

Instead of the classic Ingress service backend, Higress uses a resource backend that references the McpBridge defined above. The annotation higress.io/destination specifies the final target service in the format serviceName.serviceGroup.namespaceId.nacos, with underscores converted to hyphens to satisfy DNS rules.

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

Advanced Gateway Capabilities

Higress supports many microservice‑gateway features. Two examples are highlighted:

Canary Release

Higress fully supports Nginx Ingress canary annotations. The following Ingress routes requests with HTTP header x-user-id: 100 to a canary deployment.

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

Integration with OpenKruise Rollout can further automate progressive delivery.

Custom Extensions via Wasm

Unlike traditional gateways that require Java filters, Higress allows developers to write Wasm plugins in multiple languages, load them dynamically, and apply changes without restarting the gateway. An example plugin blocks requests containing swagger.html:

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

The source code and build instructions are available at https://github.com/alibaba/higress/tree/main/plugins/wasm-go/extensions/request-block.

Gateway Evolution Trends

Trend 1: Unified API standards for cloud‑native microservice architectures – A single API abstraction decouples users from concrete implementations and bridges technology evolution. While Ingress remains the de‑facto standard for traffic routing, more complex gateway scenarios require custom CRDs (Contour, Emissary, Kong, APISIX), leading to fragmentation. The emerging Gateway API aims to unify these definitions, though it is still in beta and not production‑ready.

Trend 2: Merging security and traffic gateways toward DevSecOps – Traditional multi‑layer architectures (WAF → Ingress → Spring Cloud Gateway) incur high cost, operational overhead, and increased failure domains. A three‑in‑one approach—combining security, traffic, and microservice routing in a single cloud‑native gateway like Higress—reduces resource consumption, simplifies operations, and aligns with DevSecOps principles, shifting security responsibility to developers while maintaining centralized control.

Adopting Higress thus enables a gradual, low‑risk migration from legacy gateways to a Kubernetes‑native, cloud‑native architecture, supporting both external and internal services via Nacos discovery.

Community Involvement

The Higress open‑source community is actively recruiting contributors. Interested developers can join via the official site (https://higress.io) and community chat groups (QR codes provided in the original article).