为了加深对 Istio 的理解，尝试翻译部分Istio的官方文档。提供中英双语和有兴趣者一起学习。
An Istio service mesh is logically split into a data plane and a control plane.
The data plane is composed of a set of intelligent proxies (Envoy) deployed as sidecars. These proxies mediate and control all network communication between microservices along with Mixer, a general-purpose policy and telemetry hub.
The control plane manages and configures the proxies to route traffic. Additionally, the control plane configures Mixers to enforce policies and collect telemetry.
一个Istio服务网格逻辑上分成一个数据平面和一个控制平面。
数据平面由一组智能代理(Envoy)组成，这些代理以sidecar的方式进行部署。代理与Mixer一起，负责调节和控制微服务间的通信。Mixer是一个通用的策略和遥测中心。
控制平面负责管理和配置代理，以便对流量进行适当地路由。此外，控制平面也会配置Mixers，以确保策略的严格执行并收集遥测数据。
The following diagram shows the different components that make up each plane:
下图展示了构成每个平面的不同组件：
Traffic in Istio is categorized as data plane traffic and control plane traffic. Data plane traffic refers to the messages that the business logic of the workloads send and receive. Control plane traffic refers to configuration and control messages sent between Istio components to program the behavior of the mesh. Traffic management in Istio refers exclusively to data plane traffic.
Istio中的流量被分成数据平面流量和控制平面流量。数据平面流量指的是业务逻辑工作负载发出和接收的消息。控制平面流量则是指在Istio各组件间传送的配置和控制消息，这类消息用于编排网格的行为。当我们说Istio中的流量管理时，通常专门指数据平面流量。
Compoments 组件
The following sections provide a brief overview of each of Istio’s core components.
下面几节是对 Istio 核心组件的简要概述。
Envoy (「特使」、「使者」的意思)
Istio uses an extended version of the Envoy proxy. Envoy is a high-performance proxy developed in C++ to mediate all inbound and outbound traffic for all services in the service mesh. Envoy proxies are the only Istio components that interact with data plane traffic.
Istio使用了一个扩展版的Envoy代理。Envoy是一个使用C++开发的高性能代理，它能调节服务网格中所有服务的入站和出站流量。Envoy代理是惟一一个与数据平面流量打交道的Istio组件。
Envoy proxies are deployed as sidecars to services, logically augmenting the services with Envoy’s many built-in features, for example:
Dynamic service discovery
Load balancing
TLS termination
HTTP/2 and gRPC proxies
Circuit breakers
Health checks
Staged rollouts with %-based traffic split
Fault injection
Rich metrics
Envoy是作为服务的sidecars进行部署的，它利用自有的许多特性对服务进行逻辑增加，例如：
动态的服务发现
负载均衡
本地TLS终止
HTTP/2和gRPC代理
熔断
健康检查
分阶段发布，基于百分比的流量切割
故障注入
丰富的指标数据
This sidecar deployment allows Istio to extract a wealth of signals about traffic behavior as attributes. Istio can, in turn, use these attributes in Mixer to enforce policy decisions, and send them to monitoring systems to provide information about the behavior of the entire mesh.
基于sidecar的部署让Istio有能力提取关于流量行为的丰富数据(称为attributes)。进而，Istio利用这些attributes在Mixer中实施策略，并把它们发送给监控系统以提供整个网格的行为信息。
The sidecar proxy model also allows you to add Istio capabilities to an existing deployment with no need to rearchitect or rewrite code. You can read more about why we chose this approach in our Design Goals.
sidecar代理模型也让你能够将Istio的能力添加到已有的部署中，无需重构或重写代码。你可以阅读我们设计目标(https://istio.io/docs/ops/deployment/architecture/#design-goals，下文有翻译)，以了解我们这样做的原因。
Some of the Istio features and tasks enabled by Envoy proxies include:
Traffic control features: enforce fine-grained traffic control with rich routing rules for HTTP, gRPC, WebSocket, and TCP traffic.
Network resiliency features: setup retries, failovers, circuit breakers, and fault injection.
Security and authentication features: enforce security policies and enforce access control and rate limiting defined through the configuration API.
Envoy代理支持的Istio特性和任务包括：
流量控制功能：通过丰富的路由规则为HTTP、gRPC、WebSocke 和 TCP 流量实施细粒度的流量控制。
网络弹性：支持配置重试、故障转移、熔断以及故障注入。
安全和身份认证机制：通过配置API来实施安全策略、访问控制和限流。
Mixer (「混音器」)
Mixer is a platform-independent component. Mixer enforces access control and usage policies across the service mesh, and collects telemetry data from the Envoy proxy and other services. The proxy extracts request level attributes, and sends them to Mixer for evaluation. You can find more information on this attribute extraction and policy evaluation in our Mixer Configuration documentation.
Mixer是一个平台无关的组件(即不依赖于某个具体的平台)。Mixer实施整个服务网格的访问控制和使用策略，同时收集来自Envoy代理和其它服务的遥测数据。代理提取request级别的属性，将它们发给Mixer进行评估分析。你可以在 Mixer 配置文档 中找到更多关于属性提取和策略评估的信息(https://istio.io/docs/reference/config/policy-and-telemetry/mixer-overview/#configuration-model)。
Mixer includes a flexible plugin model. This model enables Istio to interface with a variety of host environments and infrastructure backends. Thus, Istio abstracts the Envoy proxy and Istio-managed services from these details.
Mixer包含了一个灵活的插件模型。此模型使Istio能够与各种主机环境和后端基础设施进行交互。因此，Istio 将Envoy代理和Istio托管服务 从这些细节中抽象了出来。
Pilot (「领航员」)
Pilot provides service discovery for the Envoy sidecars, traffic management capabilities for intelligent routing (e.g., A/B tests, canary rollouts, etc.), and resiliency (timeouts, retries, circuit breakers, etc.).
Pilot为Envoy sidecars提供服务发现能力、为智能路由提供流量管理功能(如A/B测试、金丝雀发布等)和为弹性网络提供支持(超时、重试、断路器等)。
Pilot converts high level routing rules that control traffic behavior into Envoy-specific configurations, and propagates them to the sidecars at runtime. Pilot abstracts platform-specific service discovery mechanisms and synthesizes them into a standard format that any sidecar conforming with the Envoy API can consume.
Pilot将控制流量行为的高级路由规则转换为特定于Envoy的配置，并在运行时将它们传播到sidecars。Pilot抽象了特定于平台的服务发现机制，并将其合成为任何符合Envoy API的sidecar都可以使用的标准格式。
The following diagram shows how the platform adapters and Envoy proxies interact.
下图展示了平台适配器和Envoy代理之间如何交互。
The platform starts a new instance of a service which notifies its platform adapter.
The platform adapter registers the instance with the Pilot abstract model.
Pilot distributes traffic rules and configurations to the Envoy proxies to account for the change.
平台启动服务的新实例，该实例通知其平台适配器。
平台适配器向Pilot抽象模型注册该服务实例。
Pilot将流量规则和配置分发给Envoy代理来响应变化。
This loose coupling allows Istio to run on multiple environments such as Kubernetes, Consul, or Nomad, while maintaining the same operator interface for traffic management.
这种松耦合设计，在为流量管理维持相同操作接口的同时，也让Istio多个环境上运行成为可能(如Kubernetes、Consul或Nomad)。
You can use Istio’s Traffic Management API to instruct Pilot to refine the Envoy configuration to exercise more granular control over the traffic in your service mesh.
你可以使用Istio的流量管理API指导Pilot来优化Envoy配置，以便对服务网格中的流量进行更细粒度的控制。
Citadel (「大本营」)
Citadel enables strong service-to-service and end-user authentication with built-in identity and credential management. You can use Citadel to upgrade unencrypted traffic in the service mesh. Using Citadel, operators can enforce policies based on service identity rather than on relatively unstable layer 3 or layer 4 network identifiers. Starting from release 0.5, you can use Istio’s authorization feature to control who can access your services.
Citadel 通过内置的身份和凭据管理实现了服务到服务和终端用户的强身份验证。你可以使用Citadel升级服务网格中的未加密流量。使用Citadel，运维人员可以基于服务标识而不是相对不稳定的第3层或第4层网络标识来实施策略。从0.5版本开始，你可以使用Istio的授权功能来控制谁可以访问你的服务。
Galley (「厨房」)
Galley is Istio’s configuration validation, ingestion, processing and distribution component. It is responsible for insulating the rest of the Istio components from the details of obtaining user configuration from the underlying platform (e.g. Kubernetes).
Galley是Istio的配置验证、接收、处理和分发组件。它负责将其余的Istio组件与从底层平台(例如Kubernetes)获取用户配置的细节中隔离开来。
Design Goals (设计目标)
A few key design goals informed Istio’s architecture. These goals are essential to making the system capable of dealing with services at scale and with high performance.
一些关键的设计目标影响着Istio的架构。这些目标对于使系统能够处理大规模和高性能的服务至关重要。
Maximize Transparency: To adopt Istio, an operator or developer is required to do the minimum amount of work possible to get real value from the system. To this end, Istio can automatically inject itself into all the network paths between services. Istio uses sidecar proxies to capture traffic and, where possible, automatically program the networking layer to route traffic through those proxies without any changes to the deployed application code. In Kubernetes, the proxies are injected into pods and traffic is captured by programming iptables rules. Once the sidecar proxies are injected and traffic routing is programmed, Istio can mediate all traffic. This principle also applies to performance. When applying Istio to a deployment, operators see a minimal increase in resource costs for the functionality being provided. Components and APIs must all be designed with performance and scale in mind.
最大化透明度：要采用Istio，运维或开发人员仅需要尽可能少的工作量就能获得来自系统的实际价值。为此，Istio能够自动将自己注入到服务之间的所有网络路径中。Istio使用sidecar代理来捕获流量，并在可能的情况下，自动编排网络层让流量通过代理，无需对已部署的应用程序代码进行任何更改。在Kubernetes中，代理被注入到pods中，通过更改iptables规则来捕获流量。一旦sidecar代理被注入并且流量路由设定完成，Istio可以调节所有流量。这一原则也被应用到性能方面。应用Istio后，就其提供的功能而言，资源成本只有微弱的增加。组件和API的设计都必须考虑性能和规模。
Extensibility: As operators and developers become more dependent on the functionality that Istio provides, the system must grow with their needs. While we continue to add new features, the greatest need is the ability to extend the policy system, to integrate with other sources of policy and control, and to propagate signals about mesh behavior to other systems for analysis. The policy runtime supports a standard extension mechanism for plugging in other services. In addition, it allows for the extension of its vocabulary to allow policies to be enforced based on new signals that the mesh produces.
可扩展性：随着运维和开发人员越来越依赖Istio提供的功能，系统必定会随着他们的需求一起增长。在我们继续添加新特性的同时，最大的需求必然是增加这些能力：能够扩展策略系统、能够与其他策略和控制源集成，并且能够将网格行为的信号传播到其他系统进行分析。策略运行时有一套支持插入其它服务的标准扩展机制。此外，它也允许你扩展它的词汇体系，以支持基于网格生成的新信号来实施策略。
Portability: The ecosystem in which Istio is used varies along many dimensions. Istio must run on any cloud or on-premises environment with minimal effort. The task of porting Istio-based services to new environments must be trivial. Using Istio, you are able to operate a single service deployed into multiple environments. For example, you can deploy on multiple clouds for redundancy.
可移植性：使用Istio的生态系统在许多方面都不同。Istio必须能够在任何云端或本地环境中运行，且只需你付出最小的努力。将基于Istio的服务移植到新环境的任务必须很简单。使用Istio，你可以操作部署到多个环境中的单个服务。例如，可以在多个云环境上部署以实现冗余。
Policy Uniformity: The application of policy to API calls between services provides a great deal of control over mesh behavior. However, it can be equally important to apply policies to resources which are not necessarily expressed at the API level. For example, applying a quota to the amount of CPU consumed by an ML training task is more useful than applying a quota to the call which initiated the work. To this end, Istio maintains the policy system as a distinct service with its own API rather than the policy system being baked into the proxy sidecar, allowing services to directly integrate with it as needed.
策略统一性：将策略应用于服务之间的API调用，提供了对网格行为的强大控制。但是，一些没必要在API层面表示的资源，将策略应用于它们也同等重要。例如，某个机器学习的训练任务，将配额应用于CPU的使用量上比应用于启动它要用的API调用上更有用。为此，Istio使用自己的API将策略系统维护为一个独立的服务，而不是将策略系统打包到代理sidecar中，允许服务在需要时直接与之集成。
(译者注：Istio的这些设计目标也可以作为我们开发软件时的目标参考。它的低耦合、平台无关的抽象值得我们学习)
