在讲述Mixer的架构之前，我们先来了解下它的来源与背景。大家知道Google背后的API和服务管理系统，承载了来自全世界的数亿次QPS峰值的冲击。它的体系架构采用了共享的代理Proxy，由一个非常精简和高效的分布式Sidecar代理组成，它位于服务实例的旁边（顾名思义称为Sidecar代理），还有一组共享的分片式的控制平面，如图8-1所示。
图8-1 Mixer的架构
在此基础之上，Mixer汲取了它的核心经验，并进行了一定的优化改善，如图8-2所示，Mixer位于服务网格和支持它的后端基础设施之间的位置。
图8-2 Mixer位于服务网格和支持它的后端基础设施之间的位置
逻辑上，Envoy Sidecar会在每次请求之前调用Mixer，进行前置条件检查，每次请求之后还会进行指标数据的上报。Sidecar中包含本地缓存，一大部分的前置条件检查可以通过缓存来进行。另外，Sidecar会把待发送的指标数据进行缓冲，这样就可以在几千次请求之后再调用一次Mixer。尽管前置条件检查与请求处理是同步的，但遥测指标数据的上报则是使用f ire-and-forget模式异步完成的。
具体来说，Mixer扮演了两个角色：
·后端基础设施的抽象：Mixer把Istio组件和网格中的服务从基础设施细节中隔离开来。
·中介：Mixer让运维人员能够对所有网格和基础设施后端之间的交互进行不同粒度的控制。
当然，Mixer作为后端基础设施的唯一接入口，被认为可能会造成单点故障，从而导致整个网格的崩溃。事实并非如此，首先，Mixer是无状态的，不会管理任何自己的持久存储；其次，Mixer是一个高可用的组件，设计要求所有Mixer实例都要有超过99.999%的可靠性；此外，Mixer能够积累大量的短期状态数据，有助于对基础设施故障进行屏蔽，降低影响。
Sidecar代理伴随每个服务实例而运行，必须节约使用内存，这样就限制了本地缓存和缓冲的数量。但是Mixer是独立运行的，能使用更大的缓存和缓冲。因此Mixer为Sidecar提供了高伸缩性高可用的二级缓存服务。Istio Sidecar具备有效的一级缓存，在为流量服务时多数时间都可以使用缓存来完成。Mixer提供了更大的共享池作为二级缓存，这也有助于Mixer降低平均请求的延迟，并能降低服务网格到后端基础设施的请求数量，这样就能显著降低到后端基础设施的QPS。