Overview
这篇文档介绍Istio：一个连接、管理、保护微服务的开源平台。Istio提供一种简单的方式创建已部署服务网络，而不需在服务代码中做任何改变，包含负载均衡、服务到服务认证、监控等。通过在整个环境中部署一个特定的sidecar代理来提供Istio服务支持，该代理拦截微服务间的所有网络流量，使用Istio功能控制平台来配置和管理。
Istio目前仅支持k8s上部署的服务，其他环境将在未来版本支持。
为何使用Istio？
Istio解决了由单一应用程序向分布式微服务框架过渡所带给开发人员和运维人员的大量挑战。术语service mesh 通常用于描述组成此类应用程序的微服务网络和它们间的交互。随着service mesh规格和复杂度的增加，它开始变得难以理解和管理。它需要包含服务发现，负载均衡，故障恢复，metrics，监控，以及更复杂的操作需要，如A/B测试，金丝雀部署，限流，权限控制及端对端认证。
Istio通过对服务网格的行为洞察及操作控制，提供了一个满足微服务应用不同需求的完整解决方案。它在服务网络中提供了很多统一功能：
1. 流量管理。 控制服务间的流量和API调用，使调用更加可靠，并且使网络在面对不利因素时更加健壮。
2. 可观测性。 了解服务及它们之间的流量的依赖关系，提供快速识别问题的能力。
3. 策略实施。 将组织策略应用于服务间的交互，确保访问策略的执行以及资源在消费者中的公平分配。策略更改是通过配置mesh来实现，而不是更改应用代码。
4. 服务标识和安全。 由于它流经不同程度的真实网络，所以要在网格中提供可验证身份的服务以及保护服务流量的能力。
为达到这些目的，Istio为满足不同部署需求而被设计为可扩展的：
1. 平台支持。 Istio被设计能在不同环境运行，包括跨域云，on-premise，k8s，Mesos等。我们首先专注与k8s，之后会支持其他环境。
2. 集成和定制。 策略实施组件可以扩展和定制，集成现有的ACL、日志、监控、配额、审计等解决方案。
这些功能极大减少了应用代码、底层平台和策略的耦合。这种耦合的减少不仅使服务更容易实现，而且使运维人员更容易在环境和新策略方案间迁移应用部署。应用更具可移植性。
Architecture
Istio服务网格逻辑上分为数据平面和控制平面。
数据平面由一组智能代理（Envoy）构成，这些代理部署为sidecars，控制微服务间的所有网络通信。
控制平面负责管理和配置代理来路由流量，以及在运行期执行策略。
下图展示每个平面的不同组件：
Envoy
Istio使用一个扩展版的Envoy代理，由C++实现的高性能代理，协调服务网格中所有服务的出入站流量。Istio利用了Envoy的内置功能，如动态服务发现，负载均衡，TLS终止，HTTP2&gRPC代理，熔断，健康检查，以%为基础的流量分割的分段发布，故障注入和丰富的metrics。
Envoy以sidecar形式和相关服务部署在同一个k8s pod中。这使得Istio将大量流量行为的信号当作属性提取出来，并在Mixer中作为策略使用，并且发送到监控系统，来提供整个网格的行为信息。sidecar代理模型同样允许你为已经部署的系统增加Istio能力，而不需要重构系统或重写代码。
Mixer
Mixer是一个独立于平台的组件，负责在整个网格中执行访问控制和策略，并且从Envoy代理和其他服务收集遥测数据。代理提取请求级别属性，且发送到Mixer进行评估。关于更多属性提取和策略实施的信息可以在Mixer Configuration中查看。Mixer包含一个灵活的插件模型，使它能够与不同主机环境和基础设施后端进行交互，并通过这些细节抽象出Evnoy代理和托管Istio的服务。
Pilot
Pilot为Envoy sidecars提供服务发现，智能路由的流量管理能力（如A/B测试、金丝雀部署等），灵活性（超时、重试、熔断等）。它将控制流量行为的高级路由规则转换为Envoy特定配置，并在运行期将它们传播到sidecars。Pilot抽象特定平台的服务发现机制，并将他们集成到符合Envoy数据平台APIs的任何sidecar标准格式。这种松耦合使得Istio能够在多种环境运行（如k8s，Consul/Nomad），同时保持相同的流量管理维护操作界面。
Istio-Auth
Istio-Auth通过使用TLS交互，内置的身份认证和证书管理提供了强大的服务到服务和终端用户的身份认证。它可以用来升级服务网格中的未加密流量，为运维人员提供基于服务认证的执行策略而非网络控制。未来的Istio版本将增加细粒度的访问控制和审计，来控制和监控谁访问你的服务、API或资源，使用多种访问控制机制，包括属性和基于角色的访问控制，以及授权钩子。
Design Goals
这篇主要介绍Istio的涉及目标。
Istio的架构是由几个关键的设计目标决定的，这些目标使系统能够在规模和高性能的情况下处理服务是至关重要的。
最大化透明度。 要采用Istio，要求运维或开发应该尽可能少的工作而从系统获取真正的价值。为此，Istio可以自动将自己注入所有服务间的网络路径中。Istio使用sidecar代理来捕获流量，并且在可能的情况下，自动对网络层进行编程，来为这些代理路由流量，同时不必对已部署应用代码做任何修改。在k8s中，代理被注入到pods中，并通过编程iptables规则来捕获流量。一旦sidecar代理被注入并调度了流量路由，Istio就能协调网格中所有流量。这一原则也适用于性能。当应用Istio到部署，运维应该看到可提供功能的资源成本的最小增长。组件和APIs必须在设计时考虑到性能和规模。
渐进性。 随着运维和开发变得越来越依赖Istio提供的功能，系统也需要随他们的需求增加。尽管我们希望自己增加新特性，但我们希望最大的需求是扩展策略系统的能力，集成其他策略和控制源，将网格行为信号传播到其他系统进行分析。策略运行时支持插入其他服务的标准扩展机制。另外，它允许扩展词汇表，来根据网格生成的新信号执行策略。
可移植性。 Istio使用的生态系统在很多方便都有不同。Istio必须以最小的努力在任何云环境或内部环境中运行。将基于Istio的服务移植到新环境中应该是微不足道的，同时应该可以使用Istio部署到多个环境中的单个服务（如在混合云上进行冗余）。
策略一致性。 服务间API调用的应用策略提供了对网格行为的大量控制，但将策略应用于未必在API级别表示的资源上也同样重要。例如，将所耗CPU数量配额应用到ML训练任务比应用到启动工作的调用会更加有用。为此，该策略系统作为一项独立服务与其自己的API保持在一起，而不是被纳入proxy/sidecar，允许服务根据需要与其直接整合。