目前，雲原生網關支援多種路由方式，包括單服務、多服務、標籤路由、服務Mock和重新導向。
單服務路由
在該模式下，可以將請求轉寄到後端某個具體的服務。關於雲原生網關服務的設定，請參見管理服務。
網關根據配置的路由規則進行匹配，例如：
匹配/user路由規則的請求，轉寄到使用者服務。
匹配/order路由規則的請求，轉寄到訂單服務。
多服務路由
在該模式下，可以將請求轉寄到後端多個不同的服務，流量按照配置的權重進行分流。您可以在以下情境中選擇多服務類型：
不同的註冊中心
在業務發展過程中，內部架構對於註冊中心的選型可能隨著新技術的迭代而進行更換。在註冊中心選型遷移的過程中，為了保證流量無損，平滑穩定的升級，一般會冗餘部署服務並將服務的註冊中心更換為新的註冊中心，同時保留舊服務和舊註冊中心。之後逐步將流量從舊服務分流到新服務，這個過程一般耗時較久，待新服務穩定後，就可以將流量全部轉寄到採用新註冊中心的服務。同時，要支援可復原，一旦新服務的狀態不符合預期，您可以隨時將流量復原到舊服務。
例如，以下應用系統中的使用者服務原來使用的是Nacos中心，現在希望將註冊中心切換到K8s內建的CoreDNS方案（需結合Service資源一起使用）。
不同的營運體系
傳統的商務服務大多數部署在虛擬機器上，例如阿里雲ECS。隨著易營運、高彈性的K8s技術的興起，越來越多的業務開始將業務逐步遷移至K8s營運平台，例如阿里雲ACK。為了保證遷移過程中流量無損，一般會在K8s叢集上冗餘部署服務，以新的服務名註冊到註冊中心上。此時，註冊中心會出現兩個功能相同的服務，ECS上部署啟動並執行使用者服務以及K8s上部署啟動並執行使用者服務。之後逐步將流量從ECS上的服務分流到K8s上的服務，期間可以隨時調整流量權重和復原。
例如，以下應用系統中的以Nacos作為註冊中心的使用者服務，希望將ECS上的使用者服務遷移至阿里雲ACK平台。
標籤路由
在該模式下，可以將請求轉寄到相同或不同服務的不同版本，流量按照配置的權重進行分流。關於雲原生網關服務版本的設定，請參見管理服務版本。您可以在以下情境中選擇多服務類型：
金絲雀發布
在服務持續迭代發展過程中，頻繁存在服務新版本發布上線的需求，為了確保流量在服務升級過程中平穩無損，開發人員經常會使用金絲雀發布手段來將小部分流量分發到新版本進行驗證，驗證符合預期後，逐步將流量從老版本完全遷移至新版本。
例如，以下應用系統中以K8sContainer Service作為服務發現的使用者服務，服務的目前的版本為v1，現在服務的新版本v2要發布上線。有兩種方式可以進行金絲雀發布：
按比例
現有的路由/user，目標服務類型為標籤路由，轉寄至使用者服務v1版本。在服務管理中為使用者服務添加v2版本，之後在當前路由的標籤路由中新增一個目標服務（使用者服務v2版本），您可以配置權重來決定轉寄至v2版本的流量比例。
按內容
現有的路由/user，目標服務類型為標籤路由，轉寄至使用者服務v1版本。新增一條路由/user，添加灰階標識，例如Header名為stage，Header值為gray，轉寄至使用者服務v2版本。
標籤路由
在實際業務中，有的服務本身長期存在多個版本，各個版本之間功能也有差異，分別應用於有特定資訊的請求。例如對於同一個API，帶有某個Header值的請求必須訪問服務的某個版本。另一個情境是多套開發環境（測試、預發和生產），利用服務版本可以根據請求的資訊來決定分發到哪個開發環境。
例如，以下應用系統中以K8sContainer Service作為服務發現的使用者服務，有三套開發環境（test、pre和online）。對於/user的請求設定如下：
Header stage的值為test，流量轉寄至使用者服務的測試版本。
Header stage的值為pre，流量轉寄至使用者服務的預發版本。
Header stage的值為online，流量轉寄至使用者服務的正式版本。
高可用部署
為了保證服務的可用性，服務可以部署在不同的K8s叢集中，我們可以根據節點上與叢集相關的中繼資料資訊對服務所有執行個體按叢集維度進行版本管理，並且可以調整分發到各個叢集（各個服務版本）的流量權重。當某個叢集出現故障時，設定分發到該叢集的流量權重為0，即可達到流量切換目的。
例如，以下應用系統中以K8sContainer Service作為服務發現的使用者服務，部署在兩個不同的ACK叢集中，叢集A和叢集B。對於/user的路由請求流量，希望80%的流量轉寄至叢集A中部署的使用者服務，20%的流量轉寄至叢集B中部署的使用者服務。
Mock路由
該模式多用於調試的情境，通過為路由設定一個固定的響應來驗證請求的匹配條件是否符合預期，方便前端和後端並行開發，加快業務迭代速度。
例如，以下應用系統的使用者服務，在後端使用者服務未開發完成之前，可以對使用者服務的API設定一個固定的響應，方便前端開發用來調試。待後端的使用者服務開發完畢之後，可以將Mock類型改為真實的使用者服務，從而完成真正的前後端聯調。
重新導向路由
在該模式下，可以將請求重新導向到另一個網域名稱或另一個Path。通常用於業務的網域名稱遷移、API變動的情境。
例如，業務網域名稱為old.example.com，Path為/test的請求訪問雲原生網關，被網關重新導向為new.example.com/dev。
