istio組件mixer初學篇

 袁小花 360雲計算

女主宣言

隨着項目代碼量的不斷增長，冗餘的代碼量就像屋裏的雜物越積越多，項目的維護和交接變得愈來愈困難。微服務的思想油然而生，將來微服務的數量將會很是龐大，如何治理微服務也變得很是重要。本文做者將帶領你們對微服務管理工具istio進行初探，並對其組件mixer進行了詳細分析。

PS：豐富的一線技術、多元化的表現形式，盡在「360雲計算」，點關注哦！

咱們如今正在嘗試將業務微服務化，對如今熱門的微服務治理istio也開始研究並試用。今天咱們就對istio的mixer組件作一些初步的學習介紹。

既然是初學篇，先簡單說一下istio的由來。

1

背景簡介

單體應用的歷史悠長，咱們嘗過它的優點，也吃過它的苦頭。在業務不太大的時候，人力也有限的狀況下。 單體應用只用一個tar包就能夠搞定全部。mvc是經典的模式。 可是隨着項目的擴大，人員的更替。項目的代碼量不斷增長，接替的人員更容易寫新的邏輯，冗餘的代碼量就像屋裏的雜物，越積越多。致使後來，沒人敢大膽的修改代碼，將修改的代碼上線也是異常驚心的旅程。因此咱們想用微服務從根本上解決這樣的問題，它輕便，鬆耦合，不限技術棧，給咱們帶來了但願。

固然咱們知道採用微服務化，將來微服務的數量將會龐大。因此須要一個得力的工具能幫助咱們治理微服務，就比如如今的k8s對容器。咱們通過調研，最終選擇istio作嘗試。

咱們今天主要學習mixer組件，採用撥洋蔥的方式分析mixer和監控的那點關係。

2

mixer主要有兩個做用

• 策略：每次請求來，須要check是經過仍是拒絕。

• 遙測： 每次請求的狀態相關數據上報。

  
  

3

mixer使用

策略對應pod的名字是Policy，能夠登錄容器，看一下進程的啓動參數。

策略的優點明顯，缺點也明顯，即損失性能。 由於Envoy會在每次請求發送前向Mixer Policy發送Check請求，檢查該請求是否受策略限制或者配額限制。

解決方式：

1. 一種是關閉check，不用每次請求都check一下。--set global.disablePolicyChecks=true 能夠關閉策略檢查。

2. 一種是官方策略：mixer cache。

   
   

遙測對應pod的名字是telemetry，能夠登錄容器，看一下進程的啓動參數，和policy的差異。

遙測的優點明顯，收集到全部的數據。也有一個缺點，即負載問題。 由於Envoy每次請求接收後會向Mixer Telemetry上報本次請求的基本信息，如調用是否成功、返回狀態碼、耗時數據。

解決方式：

1. telemetry 起多個pods，分擔壓力。

2. 官方策略：Envoy report 採用異步模式，Envoy會向Mixer上報日誌、監控（log、metrics）等原始數據。

4

mixer原理

策略緩存的原理

緩存結構定義：

• referenced_map 用來保存哪些屬性組合已經被緩存，好比 {"k1": "a,b,c"} 這樣表示當前只有一個屬性組合」a,b,c」被保存。

• cache用來保存輸入的簽名(簡單理解爲有效輸入內容」a=1,b=2,c=3」的hash結果)和check 結果（簡化爲true/false表示是否經過），好比 { "a=1,b=2,c=3": "true" }。

• 引入一個重要概念：absence key。 第一層緩存 referenced_map 能夠爲 {「k1」: 「a,b,c」, 「k2」: 「a,b,c不存在」 }。

更詳細的緩存過程，後面會有一篇單獨的文章講它。

遙測上報監控原理

上報的結構體定義。

經過日誌查看，上報的數據格式爲一些原始的屬性值。

數據到達mixs 端。再作一些加工處理。

而後把數據分發對應的 Template 裏。Flush再讓 logentry 和 Metric 等調用各自的 adapter 對數據進行處理，因爲各自的 adapter沒有依賴關係，因此這裏使用了golang的協程進行異步處理。

這時候，登錄istio自帶的grafana，就能看到istio系統的監控。