聊聊istio服务网格
微服务的缺点：
注意：不能说拆分太细，导致分布式问题，因为服务网格也仍然有这个问题；
正是微服务架构的缺点，而演进的服务网格新架构，是一种新型的微服务架构；
服务网格本质上是服务于微服务的，主要是作为一个基础设施层，将流控负载等数据面操作从微服务中解耦出来；
抽离的基础设施是sideCar（边车），看做是微服务的一个代理。
service Mesh，也就是服务网格：如istio来说，解决了服务与服务之间通讯的问题。通讯包括服务发现、负载均衡、监控、AB测试、速率限制、访问控制；
服务网格负责与云原生进行可靠性的传递；
相比推特的linked服务网格产品，istio多了控制平台组件，用于管理side car（每个服务的通信功能拆成一个side car，这样开发只需服务中的业务即可，但维护成本变高了）
还可将其他治理功能从业务代理中剥离开来，放到sideCar中治理，如下图腾讯云的服务网格：
istio_15">istio介绍
特点：非侵入性；
解决了服务与服务之间通讯的问题。通讯包括服务发现、负载均衡、监控、AB测试、速率限制、访问控制；
引入istio，可以做到用户代码几乎不需要改动，而且可以做到用户代码与服务治理无感；
微服务改进前后
左边是传统微服务，右边是引入istio后的架构。数据平面就是业务代码，而控制平面是控制数据平面的组件；
特征：连接、安全、策略（控制接收流量的策略）、观察；
连接是指网格内服务之间的通信，面临以下问题：
而istio正是来解决这些问题；
istio_29">istio与服务治理
平时的springcloud，微服务与服务治理组件在同一个进程。弊端是，使用sentinel还是侵入性比较强，而且需要与微服务用同一种语言开发。
所以引入istio的治理方式：
istiok8s_33">istio与k8s的关系
k8s为云原生提供基础设施平台；
k8s部署的容器服务，已提供了网络互通，但是k8s没有对服务进行服务治理，而istio就帮助k8s实现服务治理。
而k8s帮istio的工作，画图如下：
（数据平面，是一个pod中部署了service容器和对应的side car容器）
如上图就是介绍在k8s实现数据平面、统一服务发现、基于CRD规则扩展自定义资源（CRD 的核心思想是通过声明式的 API 来扩展 Kubernetes 的功能。你可以定义自己的资源结构，然后像操作 Kubernetes 内建资源一样操作这些自定义资源）；
istio_41">istio的整体架构
istio分为控制平面和数据平面；
引入istio后的访问流程：
请求经过gateway后，转发到pod里服务，由同一个pod的另一个代理容器envoy拦截，会调用控制平面的pilot接口获取服务的提供者列表以及负载均衡配置（所以说pilot实现了服务发现机制），才能选出一个具体的服务提供者。而且为了访问安全性，在调用服务提供者之前，还需在控制平面的citadel组件获取服务提供者的证书与秘钥。而通信双方的envoy还要上报访问的数据给控制平面的Mixer组件，便于控制平面的监控。
①：对于side car（代理容器）是自动注入的，在创建pod时，是k8s的控制平面的api server接收kube命令，它会修改yaml文件，在资源配置后添加创建代理的配置，接着按正常创建pod；
②流量拦截，envoy接收数据包后，是由iptables来对数据包进行校验以及转发；
③服务发现，由envoy流量拦截后，就会请求控制平面的pilot组件去发现服务提供者里的列表；
④负载均衡，从发现的服务提供者列表中负载到一个具体的提供者；
⑤每个pod的envoy从pilot获取流量调用规则；
⑥关注的是调用双方的安全；
⑦调用双方的envoy都会各自上报数据给控制平面的Mixer，这样控制平面就能采集双方调用日志；
⑧策略的执行，控制服务与服务之间的访问，是拒绝调用服务，还是允许，控制权限也来自Mixer；
调用另一个pod的服务时，先访问控制平面的Mixer，看是否具有访问权限；
⑨外部访问，就是外部请求到gateway，然后转发请求给前端的pod服务；
