[TOC]
Istio Mixer組件和服務(wù)的重要說明
Mixer的Service和Pod
三個(gè)Service【statsd倡怎、Policy、Telemetry】
Mixer分為Policy和Telemetry兩個(gè)子模塊。Policy用于向Envoy提供準(zhǔn)入策略控制猎物，黑白名單控制，速率限制等相關(guān)策略；Telemetry為Envoy提供了數(shù)據(jù)上報(bào)和日志搜集服務(wù)捂贿，以用于監(jiān)控告警和日志查詢。
Mixer Policy和Mixer Telemetry很容易成為整個(gè)集群的性能短板胳嘲，因?yàn)镋nvoy發(fā)起每個(gè)請求前都需要對Policy服務(wù)進(jìn)行Check請求厂僧，一方面增加了業(yè)務(wù)請求本身的延遲，一方面也給作為單點(diǎn)的Policy增大了負(fù)載壓力了牛。如果追求性能颜屠，可以裁剪一些功能如速率限制，全局配額等鹰祸，禁用Mixer的Policy
Istio 在 UAEK 中的實(shí)踐改造之路中有對這個(gè)的較多說明甫窟。
istio-statsd-prom-bridge 這個(gè)服務(wù)也是mixer會(huì)提供的，通過安裝參數(shù)--set mixer.enabled=false就禁能了這個(gè)組件蛙婴，禁能這個(gè)組件會(huì)導(dǎo)致envoy初始化失敗粗井，報(bào)錯(cuò)日志error initializing configuration '/etc/istio/proxy/envoy-rev0.json': malformed IP address: istio-statsd-prom-bridge
Policy、Telemetry 街图、statsd詳解
kubectl get svc -n istio-system可以發(fā)現(xiàn)會(huì)有兩個(gè)和Mixer相關(guān)的Service
-
istio-policy
Mixer相關(guān)組件浇衬，用于與envoy交互，check需要上報(bào)的數(shù)據(jù)餐济，確定緩存內(nèi)容耘擂，掛掉會(huì)影響check相關(guān)功能，除非設(shè)置為不進(jìn)行check
Envoy會(huì)在每次請求發(fā)送前向Mixer Policy發(fā)送Check請求檢查該請求是否收策略限制或者配額限制
不能直接關(guān)閉或者說禁能這個(gè)策略組件絮姆，因?yàn)槟J(rèn)請求都是要去policy pods進(jìn)行check檢測的梳星，如果失敗則會(huì)導(dǎo)致請求失敗赞赖，詳見
如果要禁能所有的policy策略檢查，需要重新編輯整個(gè)服務(wù)網(wǎng)格的配置冤灾，并且重啟pilot 容器
全局選項(xiàng)
--set global.disablePolicyChecks=true可以禁止策略檢查前域，然后對應(yīng)的helm install的value.yaml的配置這里修改disablePolicyChecks為true也是OK的。注意這些個(gè)策略的更改需要稍等一些時(shí)間才能全部生效韵吨。修改完需要重啟pilot匿垄。通過安裝參數(shù)
--set mixer.enabled=false禁能Mixer組件
-
istio-telemetry
Mixer相關(guān)組件的Service，用于采集envoy上報(bào)的遙測數(shù)據(jù)归粉，該組件掛掉將導(dǎo)致各監(jiān)控運(yùn)維插件無法采集到數(shù)據(jù)椿疗，同時(shí)，該組件在高并發(fā)情境下糠悼，會(huì)承受較大負(fù)荷届榄，建議設(shè)置為多實(shí)例，增強(qiáng)可靠性
Envoy每次請求接收后會(huì)向Mixer Telemetry上報(bào)本次請求的基本信息倔喂，如調(diào)用是否成功铝条、返回狀態(tài)碼、耗時(shí)數(shù)據(jù)席噩。
-
暴露9091班缰、9093、15004悼枢、42422端口
- 9093端口是Mixer組件本身的prometheus暴露的端口
- 42422是所有 Mixer 生成的網(wǎng)格指標(biāo)
通過安裝參數(shù)
--set mixer.enabled=false禁能Mixer組件
-
istio-statsd-prom-bridge
暴露9102埠忘、9125端口
這個(gè) statsd是一個(gè)轉(zhuǎn)換為prometheus的組件，用來統(tǒng)計(jì)envoy 生成的數(shù)據(jù)馒索，這個(gè)是必須的
-
通過安裝參數(shù)
--set mixer.enabled=false就禁能了這個(gè)組件莹妒，禁能這個(gè)組件會(huì)導(dǎo)致ingressgateway的envoy初始化失敗，報(bào)錯(cuò)日志error initializing configuration '/etc/istio/proxy/envoy-rev0.json': malformed IP address: istio-statsd-prom-bridge绰上，因?yàn)閟tatsdUdpAddress這個(gè)參數(shù)指定了地址為istio-statsd-prom-bridge:9125动羽，因此還需要修改istio這個(gè)configmap中的statsdUdpAddress地址- 這就需要外部的statsd_exporter支持，關(guān)于statsd exporter的更多信息查看這里
安裝選項(xiàng)global.proxy.envoyStatsd.enabled可以控制envoy是否直接通過statsd上報(bào)渔期，global.proxy.envoyStatsd.host和global.proxy.envoyStatsd.port可以設(shè)置statsd exporter的地址
-
整體而言运吓，完全禁用Mixer的話，需要配置：
- envoy的statsd exporter的地址【statsdUdpAddress】
- set global.disablePolicyChecks=true
- set mixer.enabled=false
如果直接通過安裝參數(shù)--set mixer.enabled=false禁能Mixer組件后疯趟，訪問會(huì)報(bào)錯(cuò)如下：
[2018-10-12T09:21:17.749Z] "GET /wudebao HTTP/1.1" 503 - 0 33 0 - "192.168.65.3" "curl/7.54.0" "457cf709-2396-953e-b9e0-c405c9c56544" "www.wudebao-web.com" "-"
[libprotobuf ERROR src/istio/mixerclient/report_batch.cc:83] Mixer Report failed with: UNAVAILABLE:Cluster not available
不過拘哨，這個(gè)異步的report上報(bào)不會(huì)影響使用，也就是不會(huì)影響正常流程信峻。只有同步的check才會(huì)影響到流程和功能使用倦青，設(shè)置全局選項(xiàng)不進(jìn)行check即可解決，但是需要注意envoy的statsdUdpAddress
修改 install/kubernetes/helm/istio/charts/mixer/templates/deployment.yaml 和 service.yaml 盹舞，刪除掉policy配置产镐，然后更新就不會(huì)再部署policy了 隘庄。或者直接將install/kubernetes/helm/istio/charts/mixer/templates/deployment.yaml 和 service.yaml文件移除癣亚，就都不會(huì)部署istio-telemetry 和 istio-policy丑掺，這個(gè)做法還會(huì)部署istio-statsd-prom-bridge ，其實(shí)這正是我們想要的述雾。
不過問題在于街州，無法通過選型參數(shù)來禁止istio-telemetry 和 istio-policy，這個(gè)后面還需要再研究研究玻孟。
Mixer的check和report
需要check的 policy 策略
envoy的每個(gè)前置請求都要到mixer中進(jìn)行check唆缴，這個(gè)check必然會(huì)導(dǎo)致一些性能的降低，拋開性能不談黍翎，先看看這個(gè)check的到底是哪些策略面徽，有些什么策略可以check，check完會(huì)如何匣掸？
首先要說明的是趟紊，這些策略的檢測，是人為控制的旺聚，也就是并非是istio自帶就有會(huì)這些策略需要檢測织阳，而是需要人為去配置一些策略眶蕉。
envoy發(fā)起check請求的時(shí)候砰粹，會(huì)根據(jù)收到的請求生成指定的attributes，然后attributes作為參數(shù)之一向Mixer發(fā)起Check rpc請求造挽。Mixer中如果有對應(yīng)的adapter碱璃，則會(huì)進(jìn)行處理然后返回響應(yīng)結(jié)果，然后envoy根據(jù)結(jié)果決定是否執(zhí)行請求或拒絕請求饭入。
一些常見的check策略如：白名單檢查嵌器、ACL檢查、速率限制等谐丢，其實(shí)這些功能都是相對來說對業(yè)務(wù)更為友好的一些功能爽航，所以，如果性能問題不是一個(gè)大的瓶頸下的話乾忱，這個(gè)組件最好還是保留較好讥珍。
需要report的Telemetry遙測報(bào)告
Mixer提供了一個(gè)GRPC接口，這個(gè)接口負(fù)責(zé)接收Envoy上報(bào)的數(shù)據(jù)窄瘟，Envoy會(huì)向Mixer上報(bào)日志衷佃、監(jiān)控（log、metrics）等數(shù)據(jù)蹄葱，Envoy上報(bào)的原始數(shù)據(jù)都是一些屬性詞匯氏义，然后Mixer會(huì)轉(zhuǎn)換锄列，最終會(huì)分發(fā)到logentry 和 Metric，Mixer后端的adapter（如prometheus）會(huì)基于遙測數(shù)據(jù)做進(jìn)一步處理惯悠。
Proxy代理（Envoy sidecar）是在執(zhí)行請求之后才需要Report邻邮，調(diào)用Mixer進(jìn)行上報(bào)，這個(gè)屬于后置上報(bào)吮螺，是異步的處理流程饶囚，模式是fire-and-forget，當(dāng)然如果后端adapter處理不過來鸠补，無法Response給Envoy的話同樣還是會(huì)影響到Envoy的性能萝风。
從一些Default Metrics中可以看到提供給外界的一些監(jiān)控指標(biāo)是非常重要的，有助于我們?nèi)シ治稣麄€(gè)系統(tǒng)和后端adapter
遙測相關(guān)的后端包含：
- Tracing
- prometheus
- grafana
- serviceGraph
- Metrics
- Fluentd
當(dāng)然紫岩，prometheus规惰、grafana、Tracing等可以直接通過envoy泉蝌，而不經(jīng)過Mixer歇万；經(jīng)過Mixer可以查詢到更豐富的數(shù)據(jù)，當(dāng)然缺陷就在于多了一層降低性能勋陪。
問題 & TODO
無法通過選項(xiàng)參數(shù)來禁止istio-telemetry 和 istio-policy贪磺，這個(gè)后面還需要再研究研究∽缬蓿可以將helm install下的相關(guān)的Service和Deployment文件移除寒锚，然后helm install 或者 upgrade
【"歡迎關(guān)注我的微信公眾號：Linux 服務(wù)端系統(tǒng)研發(fā)，后面會(huì)大力通過微信公眾號發(fā)送優(yōu)質(zhì)文章"】
