关键概念
微服务：
从结构上：将原有的从技术角度拆分的组件，升级为从业务角度拆分的独立运行的服务，这些服务具备各自实现平台，并且独自占有数据，在服务之间以智能端点和哑管道方式通信。
在工程上：从产品而非项目角度进行设计、强调迭代、自动化和面向故障的设计方法。
服务网格Service Mesh
一代 原始通信时代
最初的时候，服务处理除了需要实现业务功能，还需要处理网络通信面临的丢包、乱序、重试等流控问题。
二代 tcp时代
将流量控制问题下移到网络层实现。
三代 第一代微服务
分布式系统兴起，其特有的通信语义，如熔断策略、负载均衡、服务发现、认证和授权、quota限制，trace和监控等等。服务除了业务逻辑还需要实现这些通信语义
四代 第二代微服务
将分布式通信语义通过面向微服务的开发框架来实现。屏蔽了这些通信细节。
五代 第一代Service Mesh
为了解决微服务框架出现的问题
如框架定位追踪难度大、框架语言限制、框架和服务强关联导致框架升级服务被迫升级等
以Linkerd、Envoy、NginxMesh为代表的代理模式side car出现。将分布式服务通信抽象为单独一层，实现负载均衡、服务发现、认证授权、监控追踪、流量控制等
分布式系统需要的功能，作为服务对等的代理服务和服务部署在一起，接管服务流量，通过代理之间通信完成服务间通信。
六代 第二代Service Mesh
为五代的Service Mesh提供运维管理平台，单机代理通过控制面板交互进行网络拓扑策略更新和单机数据汇报。
主要代表为istio
服务网格：是一个基础设施层，用于处理服务间通信。保证请求在服务拓扑中可靠穿梭。通常是一系列轻量级网络代理，与应用程序部署在一起，但对其透明。
Service Mesh问题：
通过代理模式转发请求，一定程度降低通信系统性能，并增加系统资源开销
Service Mesh接管了网络流量，服务稳定性依赖于Service Mesh，并且运维和管理也是一个挑战
一、服务网格的历史
如上
istio
linkerd
二、服务网格的基本特性
连接：对网格内部服务之间调用所产生的流量进行智能管理，并以此为基础，为微服务部署、测试和升级等操作提供有力保障。
安全：为网格内部服务之间调用提供认证、加密和鉴权支持，在不侵入代码的情况下，加固现有服务，提高安全性
策略：在控制面板定制策略，并在服务中实施。
观察：对服务之间的调用进行跟踪和测量，获取服务状态信息。
三、istio基本介绍
3.1、istio核心组件及其功能
Istio总体来说分为两个部分：控制面和数据面
数据面：称为SideCar，通过注入方式和业务容器共存于一个pod中，劫持业务容器的流量，接受控制面组件管理，并输出日志、跟踪及监控数据。
控制面：管理istio所有功能。
3.1.1、Pilot
Pilot是Istio主要控制点，istio流量就是由Pilot管理的。
任务
从k8s或其他平台的注册中心获取服务信息，完成服务发现过程。
读取istio各项控制配置，进行转换之后，发送给数据面进行实施。
Pilot的配置内容会被转换为数据面能理解的格式，下发给数据面的SideCar。SideCar根据Pilot指令，将路由、服务、监听、集群等定义信息转换为本地配置，
完成控制行为落地。
工作流程
1、用户通过kubectl或istioctl或者api在kubernetes上创建CRD资源，对istio控制平面发出指令。
2、Pilot监听CRD的config、rbac、networking以及authentication资源，在检测到资源对象变更之后，针对其中涉及的服务，发出指令给对应服务Sidecar
3、Sidecar根据指令更新自身配置，根据配置修改通信行为。
3.1.2、Mixer（1.6后废弃）
主要职责：预检和汇报
工作流程
1、用户将Mixer配置发送到Kubernetes中
2、Mixer通过对Kubernetes资源的监听，获知配置变化
3、网格中的服务在每次调用之前，都向Mixer发出预检请求，查看调用是否允许执行。每次调用之后，发出报告，向Mixer汇报调用过程中产生监控跟踪数据。
3.1.3、Citadel
早期版本被称为istio-ca，主要用于证书管理。在集群中启用服务间间后，Citadel负责为集群中各个服务在统一CA的条件下生成证书，并下发给各个服务的SideCar，
服务之间TLS依赖这些证书完成校验过程。
3.1.4、Sidecar（Envoy）
Sidecar就是istio的数据面，负责控制面对网格控制的实际执行
Istio中默认的Sidecar是由Envoy派生出来的，理论上，只要支持Envoy的xDS协议，就可以替代Envoy来担当这一角色。
Istio默认实现中，利用istio-init初始化容器中的iptables指令，对所有pod的流量进行劫持，从而接管pod中应用通信过程。
原来通信方式：源容器-目标容器
现在通信方式：源容器-Sidecar-Sidecar-目标容器
3.2、核心配置对象
Istio在安装过程中会进行CRD初始化，在k8s集群中注册一系列的CRD，在注册成功后，建立一些基础对象，完成istio初始设置。
Istio资源分为三组进行管理，分别是networking.istio.io、config.istio.io以及authentication.istio.io
3.2.1、networking.istio.io
Istio的流量管理就是通过这一组对象完成的
在networking.istio.io的下属资源中，VirtualService是一个控制中心。功能是：定义一组条件，将符合该条件的流量按照在对象中配置的对应策略进行处理，然后
将路由转到匹配目标中
流量访问流程的几个关键对象
Gateway-VirtualService-tcp/tls/http Route-DestinationWeight-Subset:Port
1、Gateway
无论是内部访问还是通过ingress进行网格的外部流量，首先要经过设施都是Gateway。Gateway描述了边缘接入设备的概念，
其中包含对开放端口、主机名以及可能存在的TLS证书的定义。
网络边缘的ingress通过Istio Ingress Gateway Controller进入
网络内部服务互访，通过虚拟的mesh网关进行
Pilot会根据Gateway和主机名进行检索，如果存在对应的VirtualService，则交由VirtualService处理，如果不存在，则尝试调用Kubernetes Service，如果都不存在，
发送404错误。
2、VirtualService
VirtualService主要由以下部分组成
(1）Host：该对象所负责的主机名称，如果在k8s集群，可以是服务名
(2) Gateway：流量的来源网管 默认为mesh
(3) 路由对象：网格中的流量
3、TCP/TLS/HTTP Route
路由对象可以是HTTP、TLS、TCP中的一个，分别针对不同协议进行工作
每个路由对象都至少包含两个部分：匹配条件和目的路由
HTTP Route包含用于匹配的HTTPMatchRequest对象数组，用于描述目标服务的DestinationWeight对象，并且HTTPMatchRequest对象匹配条件
更丰富，还包含专属额外特性，如超时控制、重试、错误注入等。
4、DestinationWeight
指到某个目标的流量权重
5、Destination
目标对象由Subset和Port两个元素组成。Subset就是服务的一个子集，在k8s中代表使用标签选择器区分的不同pod。port代表的是服务的端口
3.2.2、config.istio.io
用于为Mixer组件提供配置。
3.2.2、config.istio.io
3.2.2、config.istio.io
用于为Mixer组件提供配置。
Role
Match
Action->Instance
Handler<- Template
Adapter
1、Rule
Rule对象是Mixer的入口，其中包含一个match成员和一个逻辑表达式，只有符合表达式判断的数据才会被交给Action处理。逻辑表达式的变量被称为
attribute，其中的内容来自Envoy提交的数据
2、Action
负责解决的问题：将符合入口标准的数据，在用什么方式加工之后，交给哪个适配器进行处理。
Action包含两个成员对象，一个是Instance，使用Template对接收到数据进行处理，一个是Handler，代表一个适配器示例，用于接受处理后的数据
3、Instance
主要用于为进入的数据选择一个模板，并在数据中抽取某些字段作为模板参数，传输给模板进行处理。
4、Adapter
Adpater在Istio中只被定义为一个行为规范，而一些必要的实例化数据是需要再次进行初始化的
5、Template
用于对接收到的数据进行再加工，使Envoy提供的原始数据转化为符合适配器输入要求的数据格式
6、Handler
用于对Adapter进行实例化
3.2.3、authentication.istio.io
用于定义认证策略
1、Policy
用于指定服务一级的认证策略，如果命名为default，则默认采用这个认证策略
由两个部分组成：策略目标和认证方法
策略目标包含服务名称（或主机名称）以及服务端口号
认证方法由两个可选部分组成，分别是用于设置服务间认证的peers子对象以及用于设置终端认证的origins子对象
2、MeshPolicy
只能被命名为default，代表所有网格内部应用默认认证策略，其他部分内容和Policy一致
3.2.4、rbac.istio.io
基于角色的访问控制系统，主要对象为ServiceRole和ServiceRoleBinding
1、ServiceRole
由一系列规则组成，每条规则对于一条权限，描述了权限对于服务、服务路径以及方法，还包含一组可以进行自定义的约束
2、ServiceRoleBinding
和Kubernetes的RBAC类似，用于将用户主体和ServiceRole绑定。
四、istio快速入门
部署好服务后，通过istioctl kube-inject -f xxx.yaml|kubectl apply -f
这样就讲istio-proxy注入到服务了，接着就可以进行流量管控了
接着创建目标规则和默认路由
创建DestinationRule对象，将服务分为两个版本v1和v2。提交到k8s集群
创建VirtualService对象，将流量转发到v2。提交到k8s集群
查看流量管理是否生效
五、用helm部署istio
六、istio常用功能
自动注入评估顺序
Pod注解-NeverInjectSelector-AlwaysInjectSelector-命名空间策略
后续基本都是操作配置的操作，就不记录了。
感觉这本书在深入这块还差很多，组件间的运行原理和工作方式等底层的技术都没怎么涉及，希望下一版能加入这些东西吧。