Download links for books in English https://developers.redhat.com/books/introducing-istio-service-mesh-microservices/, author Burr Sutter and Posta Christian .
Chapter 1 Overview
Chinese translation Liu Shimin @ 2020.02
If you are looking for information about Istio introductory document with detailed examples, that this book is just right for you. This book is suitable for micro-reading service based on cloud architecture development of native applications application architects and developers are team leader. This book assumes you already have Docker experience; because Istio has been used in more than Linux containers choreography project, the book focuses on the use of Istio Kubernetes and OpenShift in. In this book, we'll indiscriminate use Kubernetes and OpenShift two terms (OpenShift is Red Hat released Kubernetes release).
If you need an introduction letter service-based Java Micro Spring Boot and Thorntail (previously known as WildFly Swarm), I recommend you read a book by a Christian Posta writing Microservices for Java Developers (O'Reilly).
If you are interested in the response to the decline of service (reactive microservice), then I recommend you make Build Reactive Microservices from reading Clement Escoffier in Java (O'Reilly) start a book. This book details the Vert.x, this is a response to the JVM using micro-service programming kit.
In addition, the book also assumes you already have some of the Kubernetes / OpenShift experience; if not, then I recommend you read the Grant Shipley and Graham Dumpletion writing OpenShift for Developers (for developers OpenShift, O'Reilly) a book. We will deploy in OpenShift environment, configure and use Istio; however, most of the commands we used can be used directly in Kubernetes in.
We now look at Istio can help developers solve the difficulties, and then introduce its main components.
1.1 The challenge ahead
Currently, the field of software development is in the digital age transformation, are seeking better serve our customers and users. Today's digital creator, that is, application programmers, not only has entered a faster development cycle through the use of Agile standards, but also the constant pursuit of faster development. Although there may be a month or a single application deployment once a week, however, by the large single application split into smaller units, large development teams will be split into smaller groups, the use of non-dependence between group work flow, management model and development pipeline, we may get faster product delivery speed. Industry call this micro-services architecture.
On the use of micro challenges facing the service it would have been many reports, bear the brunt, and it is distributed computing (distributed computing) confused. The biggest illusion is "network is reliable." Micro-services effectively communicate over a network (i.e., a connection between the micro-services). This is a fundamental change over the past few decades, most enterprise software production methods. When you add a network to the logic of the application-dependent, it will lead to many potential risks, the number of these risks connected with the application relies on exponential growth, rather than multiplied.
It is easy to understand that when the deployment cycle and may even dozens of times a day from once every few months to significantly improve the weekly challenges are endless.
Some large Internet companies have developed special frameworks and libraries to help ease unreliable network, volatile cloud hosting massive amount of code as well as the challenges. For example, companies such as Netflix creates Ribbon, Hystrix Eureka and other projects to solve this problem. Other companies such as Twitter and Google has done a similar thing. These frameworks they create a very strong language and platform-dependent, therefore, when using these frameworks are not supported programming language, the lingua franca of these frameworks will be difficult. These updated whenever a frame, further applications need to be updated accordingly. Finally, even when they run for each language in the framework we have increased support, in the course there will be a lot of overhead. At least in Netflix, the creation of these libraries are in a virtual machine (VM) as the main unit can be deployed scenarios, they can standardize on the (Java Virtual Machine) in a single platform and a single cloud application is running. Most companies can not do so.
Linux container (e.g. Docker) and Kubernetes / OpenShift occurs, so that the team DevOps be obtained by using higher speed fast moving mirror immutable highly automated pipeline. Now, the team management in a pipelined manner independent of the language or operating within the framework of the container. OpenShift enables us to provide greater flexibility and overall management is a complex set of distributed multi-lingual workloads. OpenShift ensure that developers can easily deploy and manage hundreds or even thousands of micro-services. These services are packaged in a container Kubernetes Pod run in, and with their respective language runtime (e.g. Java Virtual Machine, CPython and V8) and all the necessary dependent libraries, usually in the form of a frame of a particular language ( such as Spring or Express) and libraries (eg jar or npms). However, OpenShift not involved in the interaction between the application components running in each Pod. This is the challenge architects and developers face. Rapid deployment and management of multi-language services tools and infrastructure has matured, but when dealing with the interaction between these services, but we lack a similar function. Here, Istio this service grid will enable you as an application developer can build better software and deliver it faster than ever.
1.2 Initial Istio
Istio is a grid (service mesh) implementation of a service. The connection between the service grid service organization, with some additional features, such as flow control, service discovery, load balancing, resilient, observability and security. Service Grid allows applications to offload these functions from the code to allow developers to focus on business logic.
Istio the outset was designed to be deployed cross-platform work, and it has first-class support for the integration of Kubernetes.
Like Kubernetes ecosystem of many open source projects, Istio Greek nautical term, meaning "sail" as Kubernetes itself is "helmsman" or "boat driver" as Greek. Once you have Istio, people's interest in the concept of grid services growing, and Kubernetes / local OpenShift leave is Istio starting point. Istio provides a wealth of declarative service discovery and routing capabilities for developers and architects. When component provides default polling (round-robin) for you Kubernetes / OpenShift service (-Service) load balancing, Istio grained and allows the introduction of a unique among all your service routing rules within the grid. Istio also provides a powerful observability for us to be able to more in-depth study of the network topology between distributed micro-services, understand the flow between them (track) and the ability to instantly view key indicators.
In fact, since the network is not always reliable, then you need to key link between micro service more stringent monitoring and operation. Istio provides us with an elastic network layer, for example, retry, timeout, and various circuit-breaker function.
Istio also provides the ability to practice engineering chaos for developers and architects. In Chapter 5, we describe the ability Istio promote chaos injected, so that you can see the flexibility and robustness of the entire application and its potential micro dozens of interdependent services.
Before starting the discussion, we want to make sure that you have a basic understanding of Istio. The following section outlines the basic components Istio.
1.3 Components understand Istio
Istio service network mainly comprises two planes: plane data (data plane) and control plane (control plane), shown in Figure 1-1.
FIG. 1-1 Istio data and control planes
1.3.1 Data plane
数据平面的实现方式是拦截所有入站（ingress，入口）和出站（egress，出口）网络流量。你的业务逻辑、应用程序和微服务都不会觉察到这种拦截。你的微服务可使用简单框架在整个网络上调用远程HTTP端点（例如Spring RestTemplate或JAX-RS客户端），并且大多数情况下对这种拦截带来的众多有趣能力全然不知。图1-2描述了Istio出现之前的典型微服务。
图1-2 Istio出现前的微服务架构
Istio服务网格的数据平面由以边车容器（sidecar container）形式运行的istio-proxy实例组成，如图1-3所示。
图1-3 Evoy边车（istio-proxy）
服务代理
服务代理（Service proxy）增强了应用程序服务。每当需要通过网络进行通信时，应用程序服务就会通过服务代理进行调用。服务代理充当中介或拦截器，可以添加诸如自动重试、断路器、服务发现和安全性等功能。Istio的默认服务代理基于Envoy代理。
Envoy代理是Lyft开发的第7层（L7）代理（请参阅Wiki上的OSI模型），目前Lyft在生产环境中使用该代理每秒处理数百万个请求。它使用C ++编写，经过了实战测试，性能高和轻量级。它提供诸如HTTP1.1，HTTP2和gRPC的负载平衡功能。它具有收集请求级别指标和跟踪范围（trace span）能力，提供服务发现和注入故障等功能。你可能会注意到Istio的某些功能与Envoy重叠。由于Istio使用Envoy来实现这些功能，因此这一点很好理解。
但是Istio如何将Envoy部署为服务代理呢？Istio使用一种称为边车（sidecar）的部署技术，使服务代理功能与应用程序代码尽可能靠近。
边车（Sidecar）
当Kubernetes / OpenShift诞生时，它们并没有像人们原本期望的那样将Linux容器用作可运行和可部署单元。相反，它创造了Pod概念，这是在Kubernetes / OpenShift世界中被管理的主要目标。为什么需要Pod呢？有人认为这借鉴了1956年的电影《Invasion of the Body Snatchers》，但实际上借鉴了家庭或鲸鱼概念。鲸鱼是与Docker开源项目相关联的早期映像，该项目是那个时代最流行的Linux容器解决方案。Pod可以是一组Linux容器。Sidecar是另一个Linux容器，直接与你的业务逻辑应用程序或微服务容器并存。在现实世界中，边车被固定在摩托车的一侧作为一简单附属品；与之不同的是，Istio中的边车可以接管车把和油门。
使用Istio，可以将第二个Linux容器“ istio-proxy”（也称为Envoy服务代理）手动或自动注入到容纳你的应用程序或微服务的pod中。该边车负责拦截来自业务逻辑容器的所有入站（入口）和出站（出口）网络流量，这意味着可以应用新策略来重新路由传入或传出的流量，还可以应用诸如访问控制列表之类的策略（ ACL）或速率限制，还会抓取监视和跟踪数据（Mixer），甚至引入一些混乱，例如网络延迟或HTTP错误。
1.3.2 控制平面
控制平面负责成为配置和策略的中心，并使数据平面在群集中变得可操作，该群集可能由分散在多个节点上的数百个Pod组成。Istio的控制平面包括Istio的三项主要服务：Pilot，Mixer和Citadel。
Pilot
Pilot是一个Istio组件，它负责管理在Kubernetes / OpenShift集群中运行的所有微服务的边车。Istio Pilot将每个独立的istio-proxy微服务包装成Linux容器并在应用程序pod中运行，并具有整体拓扑的实时视图和保持更新的“路由表”。Pilot提供了服务发现等功能，以及对VirtualService的支持。VirtualService使你可以进行细粒度的请求分发、重试、超时等。我们将在第3章和第4章中对此进行详细介绍。
Mixer
顾名思义，Mixer是将事物整合在一起的Istio服务。每个分布式istio-proxy将遥测数据传递回Mixer。此外，Mixer维护整个微服务套件使用和访问策略的规范模型。使用Mixer，你可以创建策略，应用速率限制规则，甚至抓取自定义指标。Mixer具有可插拔的后端体系结构，并随着新插件和合作伙伴的发展而迅速发展，这些插件和合作伙伴以许多新颖有趣的方式扩展了Mixer的默认功能。Mixer的许多功能超出了本书的范围，但我们会在第6章中介绍可观察性，在第7章中介绍了安全性。
Citadel
Istio Citadel组件（以前称为Istio CA或Auth）负责证书签名、颁发、吊销及轮换。Istio向所有微服务颁发X.509证书，从而允许服务间进行双向传输层安全（mTLS）通信并透明地加密所有流量。它使用内置在基础平台中的身份，并将其构建到证书中。此身份使你可以执行策略。第7章讨论了设置mTLS的示例。
本英文译稿版本由本人所有。水平有限，错误肯定是有的，还请海涵。
感谢您的阅读，欢迎关注我的微信公众号：
