Istio：快速入门

第 9 章 网格中的 Mixer 和策略

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在使用 Mixer 的各种方式中，我们可以将其职责分为两类：遥测和策略执行。 当你查看 Mixer 公开的 API 时，这些责任领域会变得更加具体，因为 Mixer 有两个主要的 API： check (用于前提条件测试）和report （用于收集遥测数据）。 反映这两个重点领域的事实是，默认情况下，Istio 部署有两个 Mixer pod 在控制平面中运行--一个 Mixer pod 用于遥测，另一个用于策略执行。

考虑到 Mixer 作为遥测聚合点的作用，它经常被描述为属性处理引擎，因为它从服务代理处摄取遥测属性，并将其转换和输送到外部系统（通过适配器）。考虑到 Mixer 作为策略评估器的作用，它还被描述为（二级）缓存，因为它会响应检查流量策略的请求并缓存评估结果。混合器从不同来源接收不同配置，并将它们混合在一起。

架构

Mixer 位于控制平面，在数据平面和管理平面之间进行联络。与图 9-1 中显示的 Mixer 不同，它不是单点故障，因为 Istio 的默认配置包括一组用于 HA 的 pod 复制（HorizontalPodAutoscaler ）。 Mixer 是一个无状态组件，它使用缓存和缓冲技术以及加固设计，旨在实现 99.999% 的可用性。

图 9-1. 混合器架构概览

之所以称 Mixer 为单一实体，是因为尽管 API 表面按责任划分，但两个功能使用相同的 Docker 镜像运行相同的二进制文件。 它们只是根据实例要处理的功能（策略或遥测）进行了不同的配置。分成多个部署可以让每个责任区独立扩展，而不会影响到另一个责任区的性能。应用策略与生成遥测的负载特性不同，因此优化它们的运行时间很有帮助。通过这种方式，不仅可以独立扩展，还可以跟踪资源使用情况，了解遥测与策略的专用程度。虽然这些兄弟姐妹并不完全是邻居，但它们仍然可以相互喧闹；不过，如果你希望根据环境对 Mixer 的负载来优化资源使用，是否将它们合并为一个单元进行部署则取决于你。您可以将两者合并为一个部署单元。

Mixer 是遥测处理、策略评估和可扩展性的中心点。 Mixer 通过通用插件模型实现高度可扩展性。Mixer 插件被称为适配器。在 Istio 部署中可以运行任意数量 的适配器。 适配器扩展了 Mixer 的两个职责范围：

策略评估（检查）

适配器可添加前提条件检查（如 ACL、身份验证）和配额管理（如速率限制）。

遥测收集（报告）

适配器可添加指标（如请求流量统计）、日志和跟踪（即跨服务的性能或其他上下文）。

服务代理通过客户端库与 Mixer 交互。 根据 Mixer 是在其check 还是report API 上接收请求属性，要决定请求是否授权继续（前提条件检查），或者请求属性是否为遥测数据，以便路由进行请求后分析。

执行策略

istio-policy 公开的check API 可处理不同类型的策略，如身份验证和配额的策略。 考虑到check API 是在服务代理处理每个请求时在线（同步）查询的，因此check API 的性能和可用性非常重要。根据呈现的请求属性，check API ...