1. Introduction

1.绪论

In this tutorial, we’ll go through the basics of service mesh architecture and understand how it complements a distributed system architecture.

在本教程中，我们将了解服务网状结构的基本知识，并理解它如何补充分布式系统架构。

We’ll primarily focus on Istio, which is an implementation of service mesh. In the process, we’ll cover the core architecture of Istio and understand how to benefit from it on Kubernetes.

我们将主要关注Istio，它是服务网格的一个实现。在这个过程中，我们将涵盖Istio的核心架构，并了解如何在Kubernetes上从它那里获益。

2. What Is a Service Mesh?

2.什么是服务网？

Over the past couple of decades, we’ve seen how monolithic applications have started to decompose into smaller applications. It has found unprecedented popularity with cloud-native computing and microservices architecture. Further, containerization technology like Docker and orchestration system like Kubernetes have only helped in this regard.

在过去的几十年里，我们已经看到单体应用如何开始分解成更小的应用。它在云原生计算和微服务架构下找到了空前的流行。此外，像Docker这样的容器化技术和Kubernetes这样的协调系统在这方面只起到了帮助作用。

While there are a number of advantages for adopting microservices architecture on a distributed system like Kubernetes, it has its fair share of complexities. Since distributed services have to communicate with each other, we have to think about discovery, routing, retries, and fail-over.

虽然在Kubernetes这样的分布式系统上采用微服务架构有很多优势，但它也有其复杂之处。由于分布式服务必须相互通信，我们必须考虑发现、路由、重试和故障转移等问题。

There are several other concerns like security and observability that we also have to take care of:

还有一些其他的问题，如安全和可观察性，我们也必须加以注意。

Now, building these communication capabilities within each service can be quite tedious — even more so when the service landscape grows and communication becomes complex. This is precisely where a service mesh can help us. Basically, a service mesh takes away the responsibility of managing all service-to-service communication within a distributed software system.

现在，在每个服务中建立这些通信能力可能是相当乏味的–当服务范围扩大和通信变得复杂时，情况就更糟糕了。这正是服务网状结构可以帮助我们的地方。基本上，服务网状结构消除了分布式软件系统中管理所有服务间通信的责任。

The way service mesh is able to do that is through an array of network proxies. Essentially, requests between services are routed through proxies that run alongside the services but sit outside in the infrastructure layer:

服务网格能够做到这一点的方式是通过网络代理阵列。从本质上讲，服务之间的请求是通过与服务一起运行但位于基础设施层之外的代理机构进行路由。

These proxies basically create a mesh network for the services — hence the name, service mesh! Through these proxies, a service mesh is able to control every aspect of service-to-service communication. As such, we can use it to address the eight fallacies of distributed computing, a set of assertions that describe false assumptions we often make about a distributed application.

这些代理基本上为服务创建了一个网状网络–因此被称为服务网!通过这些代理，服务网状网络能够控制服务与服务之间通信的每个方面。因此，我们可以用它来解决分布式计算的八大谬误，这是一组描述我们经常对分布式应用做出错误假设的断言。

3. Features of a Service Mesh

3.服务网的特点

Let’s now understand some of the features that a service mesh can provide us. Please note that the list of actual features depends upon the implementation of service mesh. But, in general, we should expect most of these features in all implementations.

现在让我们了解一下服务网状结构可以为我们提供的一些功能。请注意，实际功能的列表取决于服务网状结构的实现。但是，一般来说，我们应该在所有的实现中期待大部分的这些功能。

We can broadly divide these features into three categories: traffic management, security, and observability.

我们可以把这些功能大致分为三类：流量管理、安全和可观察性。

3.1. Traffic Management

3.1.交通管理

One of the fundamental features of a service mesh is traffic management. This includes dynamic service discovery and routing. It also enables some interesting use-cases like traffic shadowing and traffic splitting. These are very useful for performing canary releases and A/B testing.

服务网的基本特征之一是流量管理。这包括动态服务发现和路由。它还启用了一些有趣的用例，如流量阴影和流量分割。这些对于执行金丝雀发布和A/B测试非常有用。

As all service-to-service communication is handled by the service mesh, it also enables some reliability features. For instance, a service mesh can provide retries, timeouts, rate-limiting, and circuit breakers. These out-of-the-box failure recovery features make the communication more reliable.

由于所有服务与服务之间的通信都由服务网状结构处理，因此它还能实现一些可靠性功能。例如，服务网状结构可以提供重试、超时、速率限制和断路。这些开箱即用的故障恢复功能使通信更加可靠。

3.2. Security

3.2.安全问题

A service mesh typically also handles the security aspects of the service-to-service communication. This includes enforcing traffic encryption through mutual TLS (MTLS), providing authentication through certificate validation, and ensuring authorization through access policies.

服务网状结构通常还处理服务与服务之间通信的安全问题。这包括通过相互TLS（MTLS）执行流量加密，通过证书验证提供认证，并通过访问策略确保授权。

There can also be some interesting use cases of security in a service mesh. For instance, we can achieve network segmentation allowing some services to communicate while prohibiting others. Moreover, a service mesh can provide precise historical information for auditing requirements.

在服务网中还可以有一些有趣的安全使用案例。例如，我们可以实现网络分段，允许一些服务进行通信，同时禁止其他服务。此外，服务网可以为审计要求提供精确的历史信息。

3.3. Observability

3.3.可观察性

Robust observability is the underpinning requirement for handling the complexity of a distributed system. Because a service mesh handles all communication, it’s rightly placed to provide observability features. For instance, it can provide information about distributed tracing.

强大的可观察性是处理分布式系统复杂性的基础要求。因为服务网状结构处理所有的通信，所以它可以正确地提供可观察性功能。例如，它可以提供有关分布式跟踪的信息。

A service mesh can generate a lot of metrics like latency, traffic, errors, and saturation. Moreover, a service mesh can also generate access logs, providing a full record for each request. These are quite useful in understanding the behavior of individual services as well as the whole system.

服务网状结构可以产生大量的指标，如延迟、流量、错误和饱和度。此外，服务网还可以生成访问日志，为每个请求提供完整记录。这些对于理解单个服务以及整个系统的行为相当有用。

4. Introduction to Istio

4.Istio简介

Istio is an open-source implementation of the service mesh originally developed by IBM, Google, and Lyft. It can layer transparently onto a distributed application and provide all the benefits of a service mesh like traffic management, security, and observability.

Istio是服务网的开源实现，最初由IBM、Google和Lyft开发。它可以透明地分层到分布式应用上，并提供服务网状结构的所有优点，如流量管理、安全性和可观察性。

It’s designed to work with a variety of deployments, like on-premise, cloud-hosted, in Kubernetes containers, and in servicers running on virtual machines. Although Istio is platform-neutral, it’s quite often used together with microservices deployed on the Kubernetes platform.

它被设计用于各种部署，如内部部署、云托管、Kubernetes容器以及在虚拟机上运行的服务器。尽管Istio是平台中立的，但它经常与部署在Kubernetes平台上的微服务一起使用。

Fundamentally, Istio works by deploying an extended version of Envoy as proxies to every microservice as a sidecar:

从根本上说，Istio的工作方式是将扩展版的Envoy作为代理部署到每个微服务中，作为一个副车。

This network of proxies constitutes the data plane of the Istio architecture. The configuration and management of these proxies are done from the control plane:

这个代理网络构成了Istio架构的数据平面。这些代理的配置和管理是由控制平面完成的。

The control plane is basically the brain of the service mesh. It provides discovery, configuration, and certificate management to Envoy proxies in the data plane at runtime.

控制平面基本上是服务网的大脑。它在运行时向数据平面的Envoy代理提供发现、配置和证书管理。

Of course, we can only realize the benefit of Istio when we have a large number of microservices that communicate with each other. Here, the sidecar proxies form a complex service mesh in a dedicated infrastructure layer:

当然，只有当我们有大量的微服务相互通信时，我们才能实现Istio的好处。在这里，挎包代理在一个专门的基础设施层中形成了一个复杂的服务网。

Istio is quite flexible in terms of integrating with external libraries and platforms. For instance, we can integrate Istio with an external logging platform, telemetry, or policy system.

Istio在与外部库和平台的集成方面相当灵活。例如，我们可以将Istio与外部日志平台、遥测或策略系统集成。

5. Understanding Istio Components

5.了解Istio组件

We have seen that the Istio architecture consists of the data plane and the control plane. Further, there are several core components that enable Istio to function.

我们已经看到，Istio的架构由数据平面和控制平面组成。此外，还有几个核心组件使Istio能够运作。

In this section, we’ll go through the details of these core components.

在本节中，我们将介绍这些核心组件的细节。

5.1. Data Plane

5.1.数据平面

The data plane of Istio primarily comprises an extended version of the Envoy proxy. Envoy is an open-source edge and service proxy that helps decouple network concerns from underlying applications. Applications simply send and receive messages to and from localhost, without any knowledge of the network topology.

Istio的数据面主要包括Envoy代理的扩展版本。Envoy是一个开源的边缘和服务代理，有助于将网络问题与底层应用解耦。应用程序只需向localhost发送和接收消息，而无需了解网络拓扑结构。

At the core, Envoy is a network proxy operating at the L3 and L4 layers of the OSI model. It works by using a chain of pluggable network filters to perform connection handling. Additionally, Envoy supports an additional L7 layer filter for HTTP-based traffic. Moreover, Envoy has first-class support for HTTP/2 and gRPC transports.

在核心方面，Envoy是一个在OSI模型的L3和L4层运行的网络代理。它通过使用一连串的可插拔网络过滤器来执行连接处理。此外，Envoy还支持一个额外的L7层过滤器，用于处理基于HTTP的流量。此外，Envoy对HTTP/2和gRPC传输有一流的支持。

Many of the features that Istio provides as a service mesh are actually enabled by the underlying built-in features of the Envoy proxies:

Istio作为服务网提供的许多功能实际上是由Envoy代理的底层内置功能实现的。

Traffic Control: Envoy enables the application of fine-grained traffic control with rich routing rules for HTTP, gRPC, WebSocket, and TCP traffic
Network Resiliency: Envoy includes out-of-the-box support for automatic retries, circuit breaking, and fault injection
Security: Envoy can also enforce security policies and apply access control and rate-limiting on communication between underlying services

One of the other reasons Envoy works so well with Istio is its extensibility. Envoy provides a pluggable extension model based on WebAssembly. This is quite useful in custom policy enforcement and telemetry generation. Further, we can also extend the Envoy proxy in Istio using the Istio extensions based on the Proxy-Wasm sandbox API.

Envoy与Istio配合得如此默契的另一个原因是其可扩展性。Envoy 提供了一个基于WebAssembly的可插拔扩展模型。这在自定义策略执行和遥测生成方面相当有用。此外，我们还可以使用基于Proxy-Wasm沙盒API的Istio扩展来扩展Istio中的Envoy代理。

5.2. Control Plane

5.2. 平面控制

As we’ve seen earlier, the control plane is responsible for managing and configuring the Envoy proxies in the data plane. The component that is responsible for this in the control plane is istiod. Here, istiod is responsible for converting high-level routing rules and traffic control behavior into Envoy-specific configurations and propagating them to sidecars at runtime.

正如我们前面看到的，控制平面负责管理和配置数据平面的Envoy代理。在控制平面中负责这项工作的组件是istiod。在这里，istiod负责将高层路由规则和流量控制行为转化为Envoy特定的配置，并在运行时将其传播到侧车。

If we recall the architecture of the Istio control plane from some time back, we’ll notice that it used to be a set of independent components working together. It comprised components like Pilot for service discovery, Galley for configuration, Citadel for certificate generation, and Mixer for extensibility. Due to complexity, these individual components were merged into a single component called istiod.

如果我们回忆一下前段时间Istio控制平面的架构，我们会发现它曾经是一组独立的组件在一起工作。它由服务发现的Pilot、配置的Galley、证书生成的Citadel和可扩展性的Mixer等组件组成。由于复杂性，这些独立的组件被合并成一个叫做istiod的组件。

At the core, istiod still uses the same code and APIs as the individual components earlier. For instance, Pilot is responsible for abstracting platform-specific service discovery mechanisms and synthesizing them into a standard format that sidecars can consume. Hence, Istio can support discovery for multiple environments like Kubernetes or Virtual Machines.

在核心部分，istiod仍然使用与前面各个组件相同的代码和API。例如，Pilot负责抽象出特定平台的服务发现机制，并将其合成为一个标准的格式，让侧设备可以消费。因此，Istio可以支持对Kubernetes或虚拟机等多种环境的发现。

In addition, istiod also provides security, enabling strong service-to-service and end-user authentication with built-in identity and credential management. Moreover, with istiod, we can enforce security policies based on service identity. The process istiod also acts as a Certificate Authority (CA) and generates certificates to facilitate mutual TLS (MTLS) communication in the data plane.

此外，istiod还提供了安全性，通过内置的身份和证书管理，实现了强大的服务对服务和终端用户认证。此外，通过istiod，我们可以根据服务身份来执行安全策略。这个过程istiod也作为一个证书颁发机构（CA），并生成证书以促进数据面的相互TLS（MTLS）通信。

6. How Istio Works

6.Istio如何工作

We’ve learned what the typical features of a service mesh are. Further, we’ve gone through the basics of Istio architecture and its core components. Now, it’s time to understand how Istio provides these features through the core components in its architecture.

我们已经了解了服务网的典型特征是什么。此外，我们还了解了Istio架构的基本知识和它的核心组件。现在，是时候了解Istio如何通过其架构中的核心组件提供这些功能了。

We’ll focus on the same categories of features that we went through earlier.

我们将重点关注我们之前经历过的相同类别的功能。

6.1. Traffic Management

6.1.交通管理

We can exercise granular control over the traffic in the service mesh by using Istio traffic management API. We can use these APIs to add our own traffic configurations to Istio. Further, we can define the API resources using Kubernetes custom resource definitions (CRDs). The key API resources that help us control the traffic routing are virtual services and destination rules:

我们可以通过使用Istio流量管理API对服务网中的流量进行细化控制。我们可以使用这些API向Istio添加我们自己的流量配置。此外，我们可以使用Kubernetes自定义资源定义（CRD）定义API资源。帮助我们控制流量路由的关键API资源是虚拟服务和目标规则。

Basically, a virtual service lets us configure how requests are routed to a service within the Istio service mesh. Hence, a virtual service consists of one or more routing rules that are evaluated in order. After the routing rules of a virtual service are evaluated, the destination rules are applied. The destination rules help us to control the traffic to a destination — for instance, grouping service instances by version.

基本上，虚拟服务让我们可以配置请求如何被路由到Istio服务网中的服务。因此，一个虚拟服务由一个或多个路由规则组成，这些规则按顺序被评估。在虚拟服务的路由规则被评估后，目标规则被应用。目的地规则帮助我们控制前往目的地的流量–例如，按版本将服务实例分组。

6.2. Security

6.2.安全问题

Security in Istio begins with the provisioning of strong identities to every service. The Istio agents running alongside every Envoy proxy work with istiod to automate key and certificate rotation:

Istio的安全始于为每个服务提供强大的身份。与每个Envoy代理一起运行的Istio代理与istiod合作，自动进行密钥和证书轮换。

Istio provides two types of authentication — peer authentication and request authentication. Peer authentication is used for service-to-service authentication where Istio offers mutual TLS as a full-stack solution. Request authentication is used for end-user authentication where Istio offers JSON Web Token (JWT) validation using a custom authentication provider or an OpenID Connect (OIDC) provider.

Istio 提供两种类型的认证 – 对等认证和请求认证。对等认证用于服务对服务的认证，Istio提供相互TLS作为全栈解决方案。请求认证用于终端用户认证，Istio使用自定义认证提供商或OpenID Connect（OIDC）提供商提供JSON Web Token（JWT）验证。

Istio also allows us to enforce access control to services by simply applying an authorization policy to the services. The authorization policy enforces access control to the inbound traffic in the Envoy proxy. With this, we can apply access control at various levels: mesh, namespace, and service-wide.

Istio还允许我们对服务实施访问控制，只需对服务应用授权策略即可。授权策略对Envoy代理中的入站流量实施访问控制。有了它，我们可以在不同的层面上应用访问控制：网状、命名空间和服务范围。

6.3. Observability

6.3.可观察性

Istio generates detailed telemetry like metrics, distributed traces, and access logs for all service communication within the mesh. Istio generates a rich set of proxy-level metrics, service-oriented metrics, and control plane metrics.

Istio为网格内的所有服务通信生成详细的遥测数据，如指标、分布式跟踪和访问日志。Istio 生成丰富的代理级指标、面向服务的指标和控制面指标。

Earlier, the Istio telemetry architecture included Mixer as a central component. But starting with Telemetry v2, features provided by Mixer were replaced with the Envoy proxy plugins:

早些时候，Istio遥测架构包括Mixer作为一个中心组件。但从遥测v2开始，Mixer提供的功能被Envoy代理插件所取代。

Moreover, Istio generates distributed traces through the Envoy proxies. Istio supports a number of tracing backends like Zipkin, Jaeger, Lightstep, and Datadog. We can also control the sampling rate for trace generation. Further, Istio also generates access logs for service traffic in a configurable set of formats.

此外，Istio通过Envoy代理生成分布式跟踪。Istio支持许多跟踪后端，如Zipkin、Jaeger、Lightstep，以及Datadog。我们还可以控制跟踪生成的采样率。此外，Istio还能以一组可配置的格式为服务流量生成访问日志。

7. Hands-on With Istio

7.Istio的实践

Now that we’ve gone through enough background, we’re ready to see Istio in action. To begin with, we’ll install Istio within a Kubernetes cluster. Further, we’ll use a simple microservices-based application to demonstrate the capabilities of Istio on Kubernetes.

现在我们已经了解了足够的背景，我们准备看看Istio的实际情况。首先，我们将在一个Kubernetes集群中安装Istio。此外，我们将使用一个简单的基于微服务的应用程序来演示Kubernetes上Istio的功能。

7.1. Installation

7.1.安装

There are several ways to install Istio, but the simplest of them is to download and extract the latest release for a specific OS like Windows. The extracted package contains the istioctl client binary in the bin directory. We can use istioctl to install Istio on the target Kubernetes cluster:

有几种安装Istio的方法，但其中最简单的是下载并解压用于特定操作系统（如Windows）的最新版本。解压后的软件包在bin目录下包含istioctl客户端二进制。我们可以使用istioctl来在目标Kubernetes集群上安装Istio。

istioctl install --set profile=demo -y

This installs Istio components on the default Kubernetes cluster with the demo profile. We can also use any other vendor-specific profile instead of the demo.

这将在默认的Kubernetes集群上安装Istio组件，并使用演示配置文件。我们也可以使用任何其他厂商的配置文件来代替演示。

Finally, we need to instruct Istio to automatically inject Envoy sidecar proxies when we deploy any application on this Kubernetes cluster:

最后，我们需要指示Istio在这个Kubernetes集群上部署任何应用程序时自动注入Envoy挎包代理。

kubectl label namespace default istio-injection=enabled

We’re using kubectl here with an assumption that a Kubernetes cluster like Minikube and the Kubernetes CLI kubectl are already available on our machine.

我们在这里使用kubectl，假设我们的机器上已经有Minikube这样的Kubernetes集群和Kubernetes CLI kubectl。

7.2. Sample Application

7.2.应用样本

For the purpose of demonstration, we’ll imagine a very simple application for placing online orders. This application comprises three microservices that interact with each other to fulfill an end user’s request for order:

为了演示的目的，我们将设想一个非常简单的在线下单的应用。这个应用由三个微服务组成，它们相互作用以满足最终用户的订单要求。

We’re not going into the details of these microservices, but they can be fairly simple to create using Spring Boot and REST APIs. Most importantly, we create a Docker image for these microservices so that we can deploy them on Kubernetes.

我们不打算讨论这些微服务的细节，但使用Spring Boot和REST APIs可以相当简单地创建这些微服务。最重要的是，我们为这些微服务创建一个Docker镜像，以便我们可以在Kubernetes上部署它们。

7.3. Deployment

7.3.部署

Deploying a containerized workload on the Kubernetes cluster like Minikube is fairly straightforward. We’ll be using the Deployment and Service resource types to declare and access the workload. Typically, we define them in a YAML file:

在Kubernetes集群上部署容器化的工作负载（如Minikube）是相当简单的。我们将使用Deployment和Service资源类型来声明和访问工作负载。通常情况下，我们在YAML文件中定义它们。

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: order-service
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: order-service
        version: v1
    spec:
      containers:
      - name: order-service
        image: kchandrakant/order-service:v1
        resources:
          requests:
            cpu: 0.1
            memory: 200
---
apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: order-service

This is a very simple definition for the Deployment and Service for the order-service. Similarly, we can define the YAML file for the inventory-service and the shipping-service.

这是对部署和服务的一个非常简单的定义，用于订单服务。同样，我们可以为库存服务和运输服务定义YAML文件。

Deploying these resources using kubectl is fairly straightforward as well:

使用kubectl部署这些资源也是相当直接的。

kubectl apply -f booking-service.yaml -f inventory-service.yaml -f shipping-service.yaml

Since we’ve enabled auto-injection of Envoy sidecar proxies for the default namespace, everything will be taken care of for us. Alternatively, we can use the kube-inject command of istioctl to manually inject the Envoy sidecar proxies.

由于我们已经启用了默认命名空间的Envoy sidecar代理的自动注入功能，所以一切都会被我们处理好。另外，我们也可以使用kube-inject的istioctl命令来手动注入Envoy sidecar代理。

7.4. Accessing the Application

7.4.访问该应用程序

Now, Istio is primarily responsible for handling all the mesh traffic. Hence, any traffic to or from outside of the mesh is not permitted by default. Istio uses gateways to manage inbound and outbound traffic from the mesh. This way, we can precisely control the traffic that enters or leaves the mesh. Istio provides some preconfigured gateway proxy deployments: istio-ingressgateway and istio-egressgateway.

现在，Istio主要负责处理所有的网格流量。因此，默认情况下不允许任何来自网状结构之外的流量。Istio使用网关来管理网状结构的入站和出站流量。这样，我们就可以精确控制进入或离开网状结构的流量。Istio提供了一些预配置的网关代理部署。istio-ingressgateway和istio-egressgateway。

We’ll create a Gateway and a Virtual Service for our application to make this happen:

我们将为我们的应用程序创建一个网关和一个虚拟服务来实现这一目标。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: booking-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: booking
spec:
  hosts:
  - "*"
  gateways:
  - booking-gateway
  http:
  - match:
    - uri:
        prefix: /api/v1/booking
    route:
    - destination:
        host: booking-service
        port:
          number: 8080

Here, we’re making use of the default ingress controller provided by Istio. Moreover, we’ve defined a virtual service to route our requests to the booking-service.

在这里，我们利用了Istio提供的默认入口控制器。此外，我们还定义了一个虚拟服务，将我们的请求路由到订票服务。

Similarly, we can also define an egress gateway for the outbound traffic from the mesh as well.

同样地，我们也可以为网状结构的出站流量定义一个出口网关。

8. Common Use Cases With Istio

8.Istio的常见用例

Now, we’ve seen how to deploy a simple application on Kubernetes with Istio. But, we are still not making use of any interesting feature that Istio enables for us. In this section, we’ll go through some common use-cases of a service mesh and understand how to use Istio to achieve them for our simple application.

现在，我们已经看到如何用Istio在Kubernetes上部署一个简单的应用程序。但是，我们仍然没有利用Istio为我们提供的任何有趣的功能。在这一节中，我们将通过服务网的一些常见使用情况，了解如何使用Istio为我们的简单应用实现这些功能。

8.1. Request Routing

8.1.请求路由

There are several reasons why we may want to handle request routing in a specific manner. For instance, we may deploy multiple versions of a microservice like shipping-service and wish to route only a small percentage of requests to the new version.

我们可能希望以特定方式处理请求路由，这有几个原因。例如，我们可能会部署多个版本的微服务，如shipping-service，并希望只将一小部分请求路由到新版本。

We can use the routing rules of the virtual service to achieve this:

我们可以使用虚拟服务的路由规则来实现这一点。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: shipping-service
spec:
  hosts:
    - shipping-service
  http:
  - route:
    - destination:
        host: shipping-service
        subset: v1
      weight: 90
    - destination:
        host: shipping-service
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: shipping-service
spec:
  host: shipping-service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

The routing rules also allow us to define match conditions based on attributes like a header parameter. Further, the destination field specifies the actual destination for traffic that matches the condition.

路由规则还允许我们根据头参数等属性来定义匹配条件。此外，目的地字段指定了符合条件的流量的实际目的地。

8.2. Circuit Breaking

8.2.断路

A circuit breaker is basically a software design pattern to detect failures and encapsulate the logic of preventing a failure from cascading further. This helps in creating resilient microservice applications that limit the impact of failures and latency spikes.

断路器基本上是一种软件设计模式，用于检测故障并封装防止故障进一步级联的逻辑。这有助于创建有弹性的微服务应用程序，限制故障和延迟峰值的影响。

In Istio, we can use the trafficPolicy configuration in DestinationRule to apply circuit breaking when calling a service like inventory-service:

在Istio中，我们可以使用DestinationRule中的trafficPolicy配置，在调用inventory-service等服务时应用电路中断。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: inventory-service
spec:
  host: inventory-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100

Here, we’ve configured the DestinationRule with maxConnections as 1, httpMaxPendingRequests as 1, and maxRequestsPerConnection as 1. This effectively means that if we exceed the number of concurrent requests by more than 1, the circuit breaker will start to trap some of the requests.

在这里，我们将DestinationRule配置为maxConnections为1，httpMaxPendingRequests为1，maxRequestsPerConnection为1。这实际上意味着，如果我们超过并发请求数1以上，断路器将开始捕获一些请求。

8.3. Enabling Mutual TLS

8.3.启用相互的TLS

Mutual authentication refers to a situation where two parties authenticate each other at the same time in an authentication protocol like TLS. By default, all traffic between services with proxies uses mutual TLS in Istio. However, services without proxies still continue to receive traffic in plain text.

相互认证是指双方在TLS等认证协议中同时认证对方的情况。默认情况下，在Istio中，带有代理的服务之间的所有流量都使用相互TLS。然而，没有代理的服务仍然继续接收纯文本的流量。

While Istio automatically upgrades all traffic between services with proxies to mutual TLS, these services can still receive plain-text traffic. We have an option to enforce mutual TLS mesh-wide with a PeerAuthentication policy:

虽然Istio会自动将带有代理的服务之间的所有流量升级为相互TLS，但这些服务仍然可以接收纯文本流量。我们有一个选项可以通过PeerAuthentication策略在全网范围内强制执行相互TLS。

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT

We also have options to enforce mutual TLS per namespace or service instead of mesh-wide. However, a service-specific PeerAuthentication policy takes precedence over the namespace-wide policy.

我们也可以选择在每个命名空间或服务中强制执行相互TLS，而不是在整个网状范围内。然而，特定于服务的PeerAuthentication策略优先于全命名空间的策略。

8.4. Access Control With JWT

8.4.用JWT进行访问控制

JSON Web Token (JWT) is a standard for creating data whose payload holds JSON that asserts a number of claims. This has come to be widely accepted for passing the identity and standard or custom claims of authenticated users between an identity provider and a service provider.

JSON网络令牌（JWT）是一种创建数据的标准，其有效载荷持有JSON，以证明一些主张。这已被广泛接受，用于在身份提供者和服务提供商之间传递认证用户的身份和标准或自定义索赔。

We can enable authorization policy in Istio to allow access to a service like booking-service based on JWT:

我们可以在Istio中启用授权策略，允许根据JWT访问像booking-service的服务。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: booking-service
  action: ALLOW
  rules:
  - from:
    - source:
       requestPrincipals: ["testing@baeldung.com/testing@baeldung.io"]

Here, the AuthorizationPolicy enforces all requests to have a valid JWT with requestPrincipal set to a specific value. Istio creates the requestPrincipal attribute by combining the claims iss and sub of JWT.

在这里，AuthorizationPolicy强制要求所有请求都有一个有效的JWT，并将requestPrincipal设置为一个特定值。Istio通过结合JWT的索赔iss和sub来创建requestPrincipal属性。

9. Afterthoughts

9.事后感想

So, we’ve seen by now how a service mesh like Istio makes our life easier to handle a number of common concerns in a distributed architecture like microservices. But in spite of everything, Istio is a complex system that increases the complexity of the resulting deployment. Like every other technology, Istio is not a silver bullet and must be used with due considerations.

所以，我们现在已经看到了像Istio这样的服务网是如何让我们的生活更轻松地处理像微服务这样的分布式架构中的一些常见问题的。但尽管如此，Istio是一个复杂的系统，增加了由此产生的部署的复杂性。像其他技术一样，Istio不是银弹，在使用时必须充分考虑。

9.1. Should We Always Use a Service Mesh?

9.1.我们应该总是使用服务网吗？

While we’ve seen enough reasons to use a service mesh, let’s cite some reasons which may prompt us against using it:

虽然我们已经看到了足够的理由来使用服务网，但让我们举出一些可能促使我们反对使用它的理由。

Service mesh handles all service-to-service communication at the additional cost of deploying and operating the service mesh. For simpler applications, this may not be justifiable
Since we’re quite used to handling some of these concerns like circuit breaking in application code, it may lead to duplicate handling in the service mesh
Increasing dependency on an external system like service mesh may prove to be detrimental to application portability, especially as there are no industry standards for service mesh
Since a service mesh typically works by intercepting the mesh traffic through a proxy, it can potentially add undesirable latency to requests
Service mesh adds a lot of additional components and configurations that require precise handling; this requires expertise and adds to the learning curve
Finally, we may end up mixing operational logic – which should be there in the service mesh – with business logic, which should not be in the service mesh

Hence, as we can see, the story of a service mesh is not all about benefits, but that doesn’t mean they aren’t true. The important thing for us is to carefully evaluate our requirements and the complexity of our application, and then weigh the benefits of a service mesh against their added complexity.

因此，正如我们所看到的，服务网状结构的故事并不全是关于好处的，但这并不意味着它们不是真的。对我们来说，重要的是仔细评估我们的要求和我们应用的复杂性，然后权衡服务网的好处与它们增加的复杂性。

9.2. What Are the Alternatives to Istio?

9.2.Istio的替代品有哪些？

While Istio is quite popular and backed by some of the leaders in the industry, it’s certainly not the only option available. While we can’t do a thorough comparison here, let’s go through a couple of these options, Linkerd and Consul.

虽然Istio相当受欢迎，并得到了一些行业领导者的支持，但它肯定不是唯一的选择。虽然我们不能在这里做一个彻底的比较，但让我们来看看这些选项中的几个，即Linkerd和Consul。

Linkerd is an open-source service mesh that has been created for the Kubernetes platform. It’s also quite popular and has the status of an incubating project in CNCF at present. Its working principles are similar to any other service mesh like Istio. It also makes use of TCP proxies to handle the mesh traffic. Linkerd uses a micro-proxy that is written in Rust and known as the Linkerd-proxy.

Linkerd是一个开源的服务网，它是为Kubernetes平台创建的。它也相当受欢迎，目前在CNCF具有孵化项目的地位。它的工作原理与Istio等任何其他服务网状结构相似。它还利用了TCP代理来处理网状流量。Linkerd使用了一个用Rust编写的微型代理，被称为Linkerd-proxy。

Overall, Linkerd is less complex than Istio, considering that it only supports Kubernetes. But, apart from that, the list of features that are available in Linkerd is very similar to those available in Istio. The core architecture of Linkerd also closely resembles that of Istio. Basically, Linkerd comprises three primary components: a user interface, a data plane, and a control plane.

总的来说，考虑到Linkerd只支持Kubernetes，它没有Istio那么复杂。但是，除此之外，Linkerd所提供的功能列表与Istio中的功能非常相似。Linkerd的核心架构也与Istio非常相似。基本上，Linkerd包括三个主要组件：一个用户界面、一个数据平面和一个控制平面。

Consul is an open-source implementation of service mesh from HashiCorp. It has the benefit of integrating well with the suite of other infrastructure management products from HashiCorp to provide wider capabilities. The data plane in Consul has the flexibility to support a proxy as well as a native integration model. It comes with a built-in proxy but can work well with Envoy as well.

Consul是HashiCorp推出的服务网状结构的开源实现。它的优点是可以与HashiCorp的其他基础设施管理产品套件很好地集成，以提供更广泛的功能。Consul中的数据平面可以灵活地支持代理以及本地集成模型。它配备了一个内置的代理，但也可以与Envoy很好地配合。

Apart from Kubernetes, Consul is designed to work with other platforms like Nomad. Consul works by running the Consul agent on every node to perform health checks. These agents talk to one or more Consul servers that store and replicate data. While it provides all the standard features of a service mesh like Istio, it’s a more complex system to deploy and manage.

除Kubernetes外，Consul还被设计为可与其他平台一起使用，如Nomad。Consul通过在每个节点上运行Consul代理来执行健康检查。这些代理与一个或多个存储和复制数据的Consul服务器对话。虽然它提供了像Istio这样的服务网的所有标准功能，但它是一个需要部署和管理的更复杂的系统。

10. Conclusion

10.结语

To sum up, in this tutorial, we went through the basic concepts of the service mesh pattern and the features that it provides us. In particular, we went through the details of Istio. This covered the core architecture of Istio and its basic components. Further, we went through the details of installing and using Istio for some of the common use-cases.

总而言之，在本教程中，我们经历了服务网状模式的基本概念和它所提供的功能。特别是，我们经历了Istio的细节。这涵盖了Istio的核心架构和它的基本组件。此外，我们还讨论了安装和使用Istio的细节，以满足一些常见的使用情况。