Mixer 和 SPOF 神话
提高可用性并降低延迟。
由于 Mixer 位于请求路径中，自然会质疑它如何影响整体系统可用性和延迟。人们在第一次看到 Istio 架构图时，经常听到一个常见的反驳是：“这不是在引入单点故障吗？”
在这篇文章中，我们将深入探讨 Mixer 背后的设计原则，以及令人惊讶的事实：Mixer 实际上提高了整体网格可用性并降低了平均请求延迟。
Istio 使用 Mixer 在整体系统可用性和延迟方面具有两大主要优势
提高 SLO。Mixer 使代理和服务与基础设施后端故障隔离，从而实现更高的有效网格可用性。与 Mixer 不存在的情况相比，整个网格在与基础设施后端交互时，故障率往往更低。
降低延迟。通过积极使用共享的多级缓存和分片，Mixer 降低了整个网格中观察到的平均延迟。
我们将在下面详细解释。
我们是如何走到这一步的
多年来，我们在 Google 一直使用内部 API 和服务管理系统来处理 Google 公开的众多 API。该系统一直是世界上最大的服务（Google 地图、YouTube、Gmail 等）的前端，并维持着每秒数亿次的峰值请求量。虽然该系统一直为我们服务良好，但它难以跟上 Google 的快速增长，并且很明显，为了抑制不断膨胀的运营成本，需要一种新的架构。
在 2014 年，我们开始了一个倡议，旨在创建一个更具扩展性的替代架构。结果证明非常成功，并已逐渐部署到整个 Google，并在运营成本方面每月节省了数百万美元。
旧系统构建在相当繁重的中央代理集群的基础上，所有传入流量都会流经这些代理，然后再转发到进行实际工作的服务。新架构摒弃了共享代理设计，而是由一个非常精简高效的分布式边车代理组成，该代理位于服务实例旁边，以及一个共享的分片控制平面中介集群。
看起来熟悉吗？当然：它就像 Istio！Istio 被设想为这种分布式代理架构的第二代。我们汲取了该内部系统的核心经验教训，通过与合作伙伴合作将许多概念泛化，并创建了 Istio。
架构回顾
如下图所示，Mixer 位于网格和支持它的基础设施后端之间。
Envoy 边车在每个请求之前逻辑上调用 Mixer 以执行前提条件检查，并在每个请求之后报告遥测数据。边车具有本地缓存，因此可以从缓存中执行相对较大的百分比的前提条件检查。此外，边车会缓冲传出的遥测数据，这样它实际上只需要为每几千个请求调用一次 Mixer。前提条件检查与请求处理同步，而遥测报告则是异步进行，采用“发布即忘”模式。
总的来说，Mixer 提供了
后端抽象。Mixer 使 Istio 组件和网格中的服务与各个基础设施后端的实现细节隔离。
中介。Mixer 允许运营商对网格与基础设施后端之间所有交互进行细粒度控制。
然而，即使超越这些纯粹的功能方面，Mixer 还具有其他特性，这些特性为系统提供了额外的优势。
Mixer：SLO 助推器
与 Mixer 是 SPOF 并因此可能导致网格中断的说法相反，我们相信它实际上提高了网格的有效可用性。这怎么可能呢？这里涉及三个基本特征。
无状态性。Mixer 是无状态的，因为它不管理任何自己的持久存储。
硬化。Mixer 本身被设计为一个高度可靠的组件。设计意图是为任何单个 Mixer 实例实现 > 99.999% 的正常运行时间。
缓存和缓冲。Mixer 被设计为积累大量瞬态短暂状态。
位于网格中每个服务实例旁边的边车代理在内存消耗方面必须节俭，这限制了可能的本地缓存和缓冲量。然而，Mixer 独立运行，可以使用更大的缓存和输出缓冲区。因此，Mixer 充当边车的超大规模、高可用性二级缓存。
Mixer 的预期可用性明显高于大多数基础设施后端（后端通常的可用性可能只有 99.9%）。它的本地缓存和缓冲区有助于掩盖基础设施后端故障，因为它即使在后端无响应时也能继续运行。
Mixer：延迟削减器
如上所述，Istio 边车通常具有相当有效的首级缓存。它们可以从缓存中提供大部分流量。Mixer 提供了一个更大的共享二级缓存池，这有助于 Mixer 降低每个请求的平均延迟。
在降低延迟的同时，Mixer 本质上也减少了网格对基础设施后端的调用次数。根据您支付这些后端的方式，这可能会通过降低对后端的有效 QPS 来为您节省一些资金。
展望未来
我们有机会在许多方面继续改进系统。
配置金丝雀
Mixer 规模很大，因此通常能够抵抗单个实例故障。但是，如果部署了中毒配置，导致所有 Mixer 实例基本同时崩溃（是的，那将是糟糕的一天），Mixer 仍然容易受到级联故障的影响。为了防止这种情况发生，可以将配置更改金丝雀化到一小部分 Mixer 实例，然后更广泛地推出。
Mixer 尚未进行配置更改的金丝雀化，但我们预计这将作为 Istio 在可靠配置分发方面持续工作的一部分上线。
缓存调整
我们还没有对边车和 Mixer 缓存的大小进行微调。这项工作将专注于使用最少的资源来实现可能的最高性能。
缓存共享
目前，每个 Mixer 实例都独立于所有其他实例运行。由一个 Mixer 实例处理的请求不会利用另一个实例中缓存的数据。我们最终将尝试使用分布式缓存（例如 memcached 或 Redis），以提供更大的网格范围共享缓存，并进一步减少对基础设施后端的调用次数。
分片
在非常大的网格中，Mixer 上的负载可能很大。可能存在大量的 Mixer 实例，每个实例都在努力保持缓存处于启动状态以满足传入流量。我们预计最终将引入智能分片，这样 Mixer 实例在处理特定数据流方面变得略微专业化，以提高缓存命中率。换句话说，分片通过随着时间的推移将相关流量路由到同一个 Mixer 实例，而不是随机调度到任何可用的 Mixer 实例，从而提高缓存效率。
结论
Google 的实际经验表明，精简边车代理和大型共享缓存控制平面中介的模型达到了最佳效果，提供了出色的感知可用性和延迟。我们汲取了那里的经验教训，并在 Istio 中应用它们，创建了更复杂有效的缓存、预取和缓冲策略。我们还优化了通信协议，以减少发生缓存未命中时的开销。
Mixer 仍然很年轻。在 Istio 0.3 中，我们还没有在 Mixer 本身进行重要的性能工作。这意味着当请求错过边车缓存时，我们花费在 Mixer 中的时间比应该花费的时间更多，以响应请求。我们正在做很多工作来改进这一点，以便在未来几个月减少 Mixer 在同步前提条件检查情况下带来的开销。
我们希望这篇文章让您了解 Mixer 为 Istio 带来的固有优势。请随时将评论或问题发布到 istio-policies-and-telemetry@。
