Istio的控制平面和Envoy的数据平面共同构成了一个引人注目的服务网格实现。两者都拥有蓬勃发展和充满活力的社区，并且面向下一代服务架构。Istio是独立于平台的，可运行于各种环境中，包括跨云、内部部署、Kubernetes、Mesos等。你可以在Kubernetes上部署Istio或在具有Consul的Nomad上部署。Istio目前支持在Kubernetes上部署的服务、使用Consul注册的服务以及在虚拟机上部署的服务。
其中，控制平面部分包括了Pilot、Mixer、Citadel和Galley四个组件。参见图3-1。
1.Pilot
Istio的Pilot组件用于管理流量，可以控制服务之间的流量流动和API调用，通过Pilot可以更好地了解流量，以便在问题出现之前发现问题。这使得调用更加可靠、网络更加强健，即使遇到不利条件也能让应用稳如磐石。借助Istio的Pilot，你能够配置熔断器、超时和重试等服务级属性，并设置常见的连续部署任务，如金丝雀发布、A/B测试和基于百分比拆分流量的分阶段发布。Pilot为Envoy代理提供服务发现功能，为智能路由和弹性能力（如超时、重试、熔断器等）提供流量管理功能。Pilot将控制流量行为的高级路由规则转换为特定于Envoy代理的配置，并在运行时将它们传播到Envoy。此外，Istio提供了强大的开箱即用故障恢复功能，包括超时、支持超时预算和变量抖动的重试机制、发往上游服务的并发连接和请求数限制、对负载均衡池中的每个成员进行的定期主动运行状况检查，以及被动运行状况检查。
Pilot将平台特定的服务发现机制抽象化并将其合成为标准格式，符合数据平面API的任何Sidecar都可以使用这种标准格式。这种松散耦合使得Istio能够在多种环境下运行（例如Kubernetes、Consul、Nomad），同时可保持用于流量管理的操作界面相同。
2.Mixer
Istio的Mixer组件提供策略控制和遥测收集功能，将Istio的其余部分与各个后端基础设施后端的实现细节隔离开来。Mixer是一个独立于平台的组件，负责在服务网格上执行访问控制和使用策略，并从Envoy代理和其他服务收集遥测数据。代理提取请求级属性，发送到Mixer进行评估。
Mixer中包括一个灵活的插件模型，使其能够接入到各种主机环境和后端基础设施，从这些细节中抽象出Envoy代理和Istio管理的服务。利用Mixer，你可以精细控制网格和后端基础设施后端之间的所有交互。
与必须节省内存的Sidecar代理不同，Mixer独立运行，因此它可以使用相当大的缓存和输出缓冲区，充当Sidecar的高度可伸缩且高度可用的二级缓存。
Mixer旨在为每个实例提供高可用性。它的本地缓存和缓冲区可以减少延迟时间，还有助于屏蔽后端基础设施后端故障，即使后端没有响应也是如此。
3.Citadel
Istio Citadel安全功能提供强大的身份验证功能、强大的策略、透明的TLS加密以及用于保护服务和数据的身份验证、授权和审计（AAA）工具，Envoy可以终止或向网格中的服务发起TLS流量。为此，Citadel需要支持创建、签署和轮换证书。Istio Citadel提供特定于应用程序的证书，可用于建立双向TLS以保护服务之间的流量，如图3-4所示。
图3-4 Istio Citadel架构
借助Istio Citadel，确保只能从经过严格身份验证和授权的客户端访问包含敏感数据的服务。Citadel通过内置身份和凭证管理提供了强大的服务间和最终用户身份验证。可用于升级服务网格中未加密的流量，并为运维人员提供基于服务标识而不是网络控制的强制执行策略的能力。Istio的配置策略在服务器端配置平台身份验证，但不在客户端强制实施该策略，同时允许你指定服务的身份验证要求。Istio的密钥管理系统可自动生成、分发、轮换与撤销密钥和证书。
Istio RBAC为Istio网格中的服务提供命名空间级别、服务级别和方法级别的访问权限控制，包括易于使用的基于角色的语义、服务到服务和最终用户到服务的授权，并在角色和角色绑定方面提供灵活的自定义属性支持。
Istio可以增强微服务及其通信（包括服务到服务和最终用户到服务的通信）的安全性，且不需要更改服务代码。它为每个服务提供基于角色的强大身份机制，以实现跨集群、跨云端的交互操作。
4.Galley
Galley用于验证用户编写的Istio API配置。随着时间的推移，Galley将接管Istio获取配置、处理和分配组件的顶级责任。它负责将其他的Istio组件与从底层平台（例如Kubernetes）获取用户配置的细节中隔离开来。
总而言之，通过Pilot，Istio可在部署规模逐步扩大的过程中帮助你简化流量管理。通过Mixer，借助强健且易于使用的监控功能，能够快速有效地检测和修复问题。通过Citadel，减轻安全负担，让开发者可以专注于其他关键任务。
Istio的架构设计中有几个关键目标，这些目标对于系统应对大规模流量和高性能的服务处理至关重要。
·最大化透明度：要采用Istio，应该让运维和开发人员只需付出很少的代价就可以从中获得实际价值。为此，Istio将自身自动注入到服务间所有的网络路径中。Istio使用Envoy代理来捕获流量，并且在可能的情况下自动对网络层进行编程，以便通过这些代理路由流量，而无需对已部署的应用程序代码进行太多的更改，甚至不需要任何更改。在Kubernetes中，Envoy代理被注入到pod中，通过iptables规则来捕获流量。一旦注入Envoy代理到pod中并且修改路由规则，Istio就能够调节所有流量。这个原则也适用于性能。当将Istio用于部署时，运维人员可以发现，为提供这些功能而增加的资源开销是很小的。所有组件和API在设计时都必须考虑性能和规模。
·可扩展性：随着运维人员和开发人员越来越依赖Istio提供的功能，系统必然和他们的需求一起成长。在我们继续添加新功能的同时，最需要的是能够扩展策略系统，集成其他策略和控制来源，并将网格行为信号传播到其他系统进行分析。策略运行时支持标准扩展机制以便插入到其他服务中。此外，它允许扩展词汇表，以允许基于网格生成的新信号来强制执行策略。
·可移植性：使用Istio的生态系统在很多方面都有所不同。Istio必须能够以最少的代价运行在任何云或本地环境中。将基于Istio的服务移植到新环境应该是轻而易举的，而使用Istio将一个服务同时部署到多个环境中也是可行的，例如可以在混合云上部署以实现冗余灾备。
·策略一致性：策略应用于服务之间的API调用，可以很好地控制网格行为。但对于无需在API级别表达的资源来说，对资源应用策略也同样重要。例如，将配额应用到机器学习训练任务消耗的CPU数量上，比将配额应用到启动这个工作的调用上更为有用。因此，Istio将策略系统维护为具有自己的API的独特服务，而不是将其放到代理中，这允许服务根据需要直接与其集成。