原文連結  譯者:carvendy

請求路由

  本頁描述，在Istio服務網格中，服務間的請求是如何被路由的。

服務模型和服務版本

  領航員的職責是，在原始網格中維護的權威服務。Istio的服務模型是如何依賴底層的平臺（Kubernetes、 Mesos、Cloud Foundry等）。平臺特定介面卡負責通過平臺中 提取的元資料欄位，來構成基本的模型代表。   Istio引進了服務版本概念，是一種細粒度的方式，通過版本（v1,v2）或者環境(預上線,生產)來在分拆服務。這些形式不是不同的版本：它們的更新迭代可以在相同的服務，併發布到不同的環境（生產，預上線，開發等）。通用的場景是在A/B測試或者灰度釋出中使用。Istio的流量路由規則可以參考服務版本，在服務間所提供的額外控制。

服務通訊

  根據上圖，服務的客戶端有很多不知道版本的服務。它們使用host名字或則IP地址來不斷使用其他服務。使者邊車/代理攔截，並在客戶端和服務之間轉發所有請求/響應。
基於運維人員使用領航者所制定的路由規則，使者可以動態地來決定實際選擇的服務版本。這模型可以讓服務依賴的演變從程式程式碼之中分離，也提供了其他的好處（請看Mixer）。路由規則允許使者根據請求頭、源/目標或者權重來來選擇一個版本。   Istio為多個例項的相同服務，也提供了流量的負載均衡。你看可以在服務發現和負載均衡中找到更多資訊。
Istio沒有提供DNS功能。而你的應用程式可以嘗試全限定域名,即在底層平臺（kube-dns, mesos-dns等）中使用DNS服務。

入口和出口

  Istio假定了所有流量是通過使者代理進入和離開服務網格。在前端的服務釋出使者代理，運維人員可以對於面向使用者的服務進行A/B測試，金絲雀釋出等。同樣地，通過邊車使者路由流量指向外部的web服務（例如，地圖API,或者多媒體API），運維人員可以加入故障恢復特性，例如超時、重試、熔斷等，並且可以根據這些服務的連線來獲取詳細的指標度量。