Mixer 與單點故障迷思
提高可用性並降低延遲。
由於 Mixer 位於請求路徑中，很自然會質疑它如何影響整體系統的可用性和延遲。當人們第一次看到 Istio 架構圖時，經常聽到的疑問是「這不就是引入單點故障嗎？」
在這篇文章中，我們將深入探討並涵蓋 Mixer 的設計原則，以及一個令人驚訝的事實，即 Mixer 實際上提高了整體網格的可用性並降低了平均請求延遲。
Istio 使用 Mixer 在整體系統可用性和延遲方面有兩個主要好處
提高 SLO。Mixer 使代理和服務免受基礎架構後端故障的影響，從而實現更高的有效網格可用性。當與基礎架構後端交互時，如果沒有 Mixer，整個網格的故障率往往會較低。
降低延遲。透過積極使用共享的多層快取和分片，Mixer 降低了整個網格中觀察到的平均延遲。
我們將在下面更詳細地解釋這一點。
我們是如何走到這一步的
多年來，在 Google，我們一直使用內部 API 和服務管理系統來處理 Google 公開的許多 API。該系統一直為世界上最大的服務（Google 地圖、YouTube、Gmail 等）提供前端服務，並維持每秒數億次的峰值請求率。儘管這個系統對我們很有幫助，但它在跟上 Google 的快速增長方面遇到了問題，並且很明顯需要一種新的架構來抑制不斷膨脹的營運成本。
在 2014 年，我們啟動了一項計劃，以創建一個可以更好地擴展的替代架構。結果證明非常成功，並已逐漸在 Google 中部署，在此過程中每月節省了數百萬美元的營運成本。
較舊的系統圍繞著一個集中式的相當重的代理群構建，所有傳入的流量都會流向該代理群，然後再轉發到執行實際工作的服務。較新的架構摒棄了共享代理設計，而是由一個非常精簡且高效的分散式 Sidecar 代理與服務實例並排運行，以及一個共享的分片控制平面中介組成的。
看起來很熟悉嗎？當然：它就像 Istio！Istio 被構想為這種分散式代理架構的第二代。我們從這個內部系統中汲取了核心經驗教訓，透過與合作夥伴合作，概括了許多概念，並創建了 Istio。
架構回顧
如下圖所示，Mixer 位於網格和支援網格的基礎架構後端之間
Envoy Sidecar 在每次請求之前邏輯上呼叫 Mixer 以執行前提檢查，並在每次請求之後報告遙測。Sidecar 具有本機快取，因此可以從快取中執行相對較大比例的前提檢查。此外，Sidecar 會緩衝傳出的遙測資料，因此實際上每幾千個請求才需要呼叫一次 Mixer。前提檢查與請求處理同步，而遙測報告則使用發後不理的模式非同步完成。
在較高層次上，Mixer 提供
後端抽象。Mixer 使網格內的 Istio 組件和服務免受個別基礎架構後端的實作細節的影響。
中介。Mixer 允許營運人員對網格和基礎架構後端之間的所有互動進行細粒度控制。
然而，即使除了這些純粹的功能方面之外，Mixer 還具有其他特性，可為系統帶來額外的好處。
Mixer：SLO 增強器
與 Mixer 是單點故障並因此可能導致網格中斷的說法相反，我們認為它實際上提高了網格的有效可用性。這怎麼可能呢？有三個基本特性在起作用
無狀態性。Mixer 是無狀態的，因為它不管理任何自己的持久儲存。
強化。Mixer 本身被設計為一個高度可靠的組件。設計意圖是為任何單個 Mixer 實例實現 > 99.999% 的正常執行時間。
快取和緩衝。Mixer 被設計為累積大量的暫時性臨時狀態。
網格中與每個服務實例並排運行的 Sidecar 代理必須在記憶體消耗方面非常節儉，這限制了可能的本機快取和緩衝量。然而，Mixer 獨立存在，可以使用相當大的快取和輸出緩衝區。因此，Mixer 充當 Sidecar 的高度擴展且高度可用的第二層快取。
Mixer 的預期可用性遠高於大多數基礎架構後端（這些後端的可用性通常可能為 99.9%）。它的本機快取和緩衝區有助於掩蓋基礎架構後端故障，即使後端變得無回應，它也能繼續運作。
Mixer：延遲削減器
正如我們上面所解釋的，Istio Sidecar 通常具有相當有效的第一層快取。它們可以從快取中處理大多數流量。Mixer 提供了一個更大的共享第二層快取池，這有助於 Mixer 降低每個請求的平均延遲。
當它忙於減少延遲時，Mixer 本質上也減少了網格對基礎架構後端的呼叫次數。根據您為這些後端付費的方式，這可能會透過減少對後端的有效 QPS 來節省一些現金。
未來的方向
我們未來有機會透過多種方式繼續改進系統。
組態金絲雀
Mixer 是高度擴展的，因此通常可以抵抗個別實例故障。但是，當部署導致所有 Mixer 實例幾乎同時當機的有毒組態時（是的，那將是糟糕的一天），Mixer 仍然容易受到級聯故障的影響。為了防止這種情況發生，組態變更可以先向一小部分 Mixer 實例進行金絲雀部署，然後再更廣泛地推出。
Mixer 尚未對組態變更進行金絲雀部署，但我們希望這將作為 Istio 正在進行的可靠組態分配工作的一部分上線。
快取調整
我們尚未對 Sidecar 和 Mixer 快取的大小進行微調。這項工作將著重於使用最少的資源實現盡可能高的效能。
快取共享
目前，每個 Mixer 實例都獨立於所有其他實例運作。由一個 Mixer 實例處理的請求不會利用不同實例中快取的資料。我們最終將嘗試使用分散式快取，例如 memcached 或 Redis，以便提供更大的網格範圍共享快取，並進一步減少對基礎架構後端的呼叫次數。
分片
在非常大的網格中，Mixer 的負載可能很大。可能會有大量的 Mixer 實例，每個實例都在努力保持快取的準備狀態以滿足傳入的流量。我們希望最終引入智慧分片，以便 Mixer 實例稍微專門處理特定的資料流，以增加快取命中的可能性。換句話說，分片有助於透過將相關流量隨時間路由到同一個 Mixer 實例，而不是隨機分派到任何可用的 Mixer 實例來提高快取效率。
結論
在 Google 的實務經驗表明，精簡的 Sidecar 代理和大型共享快取控制平面中介的模型達到了一個最佳點，提供了出色的感知可用性和延遲。我們在那裡汲取的教訓，並將它們應用於在 Istio 中創建更複雜和有效的快取、預取和緩衝策略。我們還最佳化了通訊協定，以減少發生快取未命中時的負擔。
Mixer 仍然很年輕。截至 Istio 0.3，我們尚未在 Mixer 本身內進行重要的效能工作。這意味著當請求未命中 Sidecar 快取時，我們在 Mixer 中花費的時間比我們應該花費的時間更多來回應請求。我們正在努力在未來幾個月內改善這一點，以減少 Mixer 在同步前提檢查案例中帶來的負擔。
我們希望這篇文章能讓您了解 Mixer 為 Istio 帶來的固有好處。請隨時將評論或問題發布到 istio-policies-and-telemetry@。
