Mixer FAQ
为什么 Istio 需要 Mixer？
Mixer 为 Istio 组件和服务之间提供了丰富的中介层，Mixer 作为基础设施后端服务可用于访问控制检查控制和遥测数据采集。Mixer 提供的中介层可在不修改服务二进制的情况下，帮助运维人员获得对服务内部机制的洞悉力和控制力。
Mixer 被设计为独立组件，这与 Envoy 不同。这样的设计有很多好处：
- 可伸缩性 。 Mixer 和 Envoy 的功能本质上不同，这也导致了对于可伸缩性要求不同。保持组件分离可实现独立的组件适当扩展。
- 资源使用 。 Istio 依赖于部署代理的实例，因此最小化代理的成本是非常重要的。将 Mixer 的复杂逻辑移动到独立的组件中实现可以保证 Envoy 功能的轻量和灵活。
- 可靠性 。 Mixer 及其开放式扩展性模型代表了数据路径处理流水线最复杂部分。在 Mixer 而不是 Envoy 中实现此功能，是因为这样可以达到故障域隔离，使得 Envoy 在 Mixer 失败的情况下也能正常运行，避免宕机。
- 隔离性 。 Mixer 在 Istio 和 基础设施后端之间提供了一定程度的隔离。每个 Envoy 实例都可配置为非常小范围内的互动操作，限制了潜在攻击的影响。
- 可扩展性 。 为使得 Istio 进行互操作的后端保持足够的健壮性，必须要求模型的简单和可扩展性。归功于其设计和语言选择，Mixer 比 Envoy 具备更好的扩展性。功能点的分离也使得 Istio 策略和遥测处理的功能可以采用不同的代理实现，例如 Envoy 和 NGINX 的混合。
Envoy 实现了复杂的缓存，批处理和预取策略，从而在很大程度上减轻了在请求路径上与 Mixer 交互的延迟影响。
如何查看 Mixer 配置？
instances、 handlers 和 rules 的相关配置以 Kubernetes Custom Resources 的方式进行存储。相关配置可以通过 kubectl 命令从 Kubernetes API server 查询获取。
Rules
查看所有 rule 的列表，执行以下命令：
$ kubectl get rules --all-namespaces
NAMESPACE NAME AGE
istio-system kubeattrgenrulerule 20h
istio-system promhttp 20h
istio-system promtcp 20h
istio-system stdiohttp 20h
istio-system stdiotcp 20h
istio-system tcpkubeattrgenrulerule 20h
查看单个 rule 配置，执行以下命令：
$ kubectl -n <namespace> get rules <name> -o yaml
Handlers
Handlers 是基于 adapter 的 Kubernetes CRD 定义的。
首先，查看 adapter 类型列表：
$ kubectl get crd -listio=mixer-adapter
NAME AGE
adapters.config.istio.io 20h
bypasses.config.istio.io 20h
circonuses.config.istio.io 20h
deniers.config.istio.io 20h
fluentds.config.istio.io 20h
kubernetesenvs.config.istio.io 20h
listcheckers.config.istio.io 20h
memquotas.config.istio.io 20h
noops.config.istio.io 20h
opas.config.istio.io 20h
prometheuses.config.istio.io 20h
rbacs.config.istio.io 20h
servicecontrols.config.istio.io 20h
signalfxs.config.istio.io 20h
solarwindses.config.istio.io 20h
stackdrivers.config.istio.io 20h
statsds.config.istio.io 20h
stdios.config.istio.io 20h
然后，对列表中的每个 adapter 类型，执行以下命令：
$ kubectl get <adapter kind name> --all-namespaces
stdios 的输出类似于：
NAMESPACE NAME AGE
istio-system handler 20h
查看单个 handler 配置，执行以下命令：
$ kubectl -n <namespace> get <adapter kind name> <name> -o yaml
Instances
Instances 是基于 instance 的 Kubernetes CRD 定义的。
首先，查看 instance 类型列表：
$ kubectl get crd -listio=mixer-instance
NAME AGE
apikeys.config.istio.io 20h
authorizations.config.istio.io 20h
checknothings.config.istio.io 20h
edges.config.istio.io 20h
instances.config.istio.io 20h
kuberneteses.config.istio.io 20h
listentries.config.istio.io 20h
logentries.config.istio.io 20h
metrics.config.istio.io 20h
quotas.config.istio.io 20h
reportnothings.config.istio.io 20h
servicecontrolreports.config.istio.io 20h
tracespans.config.istio.io 20h
然后，对列表中的每个 instance 类型，执行以下命令：
$ kubectl get <instance kind name> --all-namespaces
metrics 的输出类似于：
NAMESPACE NAME AGE
istio-system requestcount 20h
istio-system requestduration 20h
istio-system requestsize 20h
istio-system responsesize 20h
istio-system tcpbytereceived 20h
istio-system tcpbytesent 20h
查看单个 instance 配置，执行以下命令：
$ kubectl -n <namespace> get <instance kind name> <name> -o yaml
Mixer 支持的全部属性表达式有哪些？
Mixer 支持的全部属性表达式参见表达式语言参考。
Mixer 是否提供内部监控？
Mixer 提供了监控端点（默认端口：10514）。Mixer 提供的性能和审计功能的服务路径如下：
/metrics提供有关 Mixer 处理的 Prometheus 指标、 API 调用相关的 gRPC 指标和 adapter 调度指标。/debug/pprof提供了性能剖析相关的数据，格式为 pprof。/debug/vars提供了服务器指标，数据为 JSON 格式。
可通过 kubectl logs 命令访问 Mixer 的日志，如下所示：
- 关于
istio-policy服务：
$ kubectl -n istio-system logs -lapp=policy -c mixer
- 关于
istio-telemetry服务：
$ kubectl -n istio-system logs -lapp=telemetry -c mixer
Mixer 追踪功能由以下命令行参数控制：trace_zipkin_url、trace_jaeger_url 和 trace_log_spans。如果设置了以上参数中的任何一个，则追踪数据将上报至配置的相关服务地址。如果未提供追踪相关设置参数，则 Mixer 将不会产生应用程序级别的追踪信息。
如何为 Mixer 编写自定义适配器？
了解如何为 Mixer 实现新的 adapter，可参考 Adapter Developer’s Guide。