1.1简单介绍istio
与k8s紧密结合，适用于云原生场景，service mesh形态，服务治理的开放平台
服务治理，包括：连接、安全、策略执行和可观察性。
连接：通过配置的流量规则控制服务间的流量和调用，实现负载均衡，熔断，故障注入，重试，重定向等服务治理
安全：提供认证机制、通道加密、服务访问授权等，增强服务访问的安全性
策略执行：通过可动态插拔，可扩展的策略，实现访问控制，速率限制，配额管理，服务计费等能力
可观察性:动态获取服务运行数据和输出，提供强大的调用链，监控，和调用日志收集与输出的能力。
1.2istio使用示例
istio通过配置实现灰度发布的实例：
apiVersion: networking.istio.io/vlalpha3
kind: VirtualService
metadata:
name: recommendation
spec:
hosts:
- recommendation
http:
- match:
- headers:
cookie:
exact: "group=dev"
route:
- destination:
name: v2
- route:
- destination:
name: v1
含义：
group是dev的流量转发到recommendation服务的v2版本，其他用户访问v1版本，从而实现灰度。
1.3 istio与服务治理
服务治理，比如一般经常提到的微服务治理，实际上只要有服务与访问就可以治理。
1.3.1 关于微服务
为什么出现微服务：
1）发布成本变高，如编译更多的代码，某一个小的点修改，要发布整个项目
2）合作成本变高，如 代码冲突增加
3）服务之间相互影响，如某个服务发生OOM，导致所有的服务不可用
微服务的本质：化繁为简 分而治之
微服务带来的好处：
开发：服务内聚，微服务内易于设计和扩展，可以采用不同的语言和开发工具
运维：每个服务可以自运维；迭代速度快，上线风险小
组织管理：微服务角度切分小组，利于敏捷开发
引入的问题：
服务注册、发现、调用、负载均衡，跨进程的分布式调用栈和链式追踪。
解决上面的问题就需要服务治理。
1.3.2 服务治理的形态演变
第一种形态：在应用程序中包含治理逻辑，如rpc服务调用、重试机制等。
特点：简单，但会有大量重复代码，业务代码和治理逻辑耦合，后期难以维护。
第二种形态：治理逻辑独立的代码
sdk模式：即把治理的公共逻辑抽象成一个公共库，让所有的微服务使用这个公共库。典型的框架爱就是springCloud
特点：代码上解耦了业务和治理的逻辑，但是两者还是在一个进程内，存在如下问题：
1）业务代码必须和SDK是同一种语言
2）因为多个服务分别引用治理的sdk，所以治理逻辑升级时需要整个服务一起升级
3）sdk有一定的学习门槛
第三种形态：治理逻辑是独立的进程
业务和治理代码彻底解耦。
评价：对开发语言无限制，原服务也无需做任何修改，可以对老系统渐进式升级改造。
从三个形态整体来看：服务治理组件的位置在持续下沉，对应用的侵入主键减少
1.3.3 istio与微服务关系
微服务是一种架构风格，是一种方法论。istio是一种服务治理的完整实践，但istio绝不是微服务方法论的落地。
场景上，istio管理的大部分对象是微服务过的，但是也可以管理单体应用。特别适用于传统行业的用户业务需要在容器化后进行的服务治理。
能力上，istio包含微服务情调的负载均衡、熔断、限流等治理能力，还包含可插拔的服务安全、控制策略、服务运行的可观察性等更广泛的能力。
谈论istio和微服务的关系，不如关注istio和k8s的关系。k8s和云原生实际上已经改变和重新定义了软件开发的很多方面。
1.4 istio与服务网格
服务网格的特点
基础设施：处理服务间通信的基础设施
云原生：适用于云原生场景下的服务间的通信
网络代理：轻量级的网络代理来执行治理逻辑
对应用透明：应用程序网络代理部署在一起，但应用感知不到代理的存在
1.4.1 为什么会选择服务网格
为什么服务网格这么火？
1）进入了云原生时代，服务剧增，应用间的访问拓扑更加复杂，治理需求越来越多。与应用代码混合或进程混合的服务治理方式已经不再可以满足要求
2）单个应用上，对应用完全无侵入，与开发语言无关
3）全局来看，关注的是sideCar组成的网格，对网格间的服务访问进行管理，应用还是按照原本的方式进行互相访问。
4）sidecar是网格动作的执行体，全局的管理规则和网格内的元数据通过一个统一的控制面实现，应用感知不到sideCar。
从forecast访问recommendation看sidecar导致的问题
如图：
需要先经过forecast服务的sidecar拦截outbound流量执行治理动作，再经过recommendation服务的sidecar拦截inbound流量执行治理工作。
从上图可以看出，会引入如下问题：
1）服务间访问增加了两跳，则增加了两处延迟和可能的故障点 解决：加大计算资源投入保证转发代理的轻量和高性能，降低延迟
2) 多出来的两跳对整体可靠性和复杂度都带来了新的挑战。 解决：基础设施层面的可靠性、可维护性范畴，服务网格产品自身可以满足
1.4.2 为什么选择istio
控制面上，基于xDs协议提供了一套标准的控制面规范，向数据面传递服务信息和治理规则。全新的设计，采用了gRPC协议，功能强大。
数据面上，采用了envoy，采用c++语言实现的轻量高性能的代理；支持更多协议，有服务发现、健康检查、高级LB、前端代理等能力；架构上是一个可高度定制化的程序，提供了高度扩展性，支持热重启，模块化编码，已与测试。
大厂支持上，istio由ibm和谷歌共同推出，定位上，将容器作为核心，k8s作为管理容器的编排系统，istio管理容器上服务之间的交互。
1.5 istio与k8s
k8s：管理容器的平台
1.5.1 istio是k8s的好帮手
k8s提供的功能：应用负载的部署、升级、扩容等运行管理能力
k8s中的service机制可以实现服务注册、发现和负载均衡，并通过服务名访问服务实例
k8s中的pod部署微服务也很合适，解决了微服务的互访互通的问题。
k8s的不足（为什么引入istio）：
无法管理服务间的访问，如服务的熔断 限流 动态路由 调用链追踪等
istio实现的简单说明
k8s的service基于节点的kube-proxy从kube-apiserver上获取service和endpoint信息，将对service的请求经过负载均衡后转发到对应的endpoint上。但无法基于应用层的信息进行负载均衡、无法进行流量管理、无法进行指标和调用链的跟踪。
istio复用了k8s service的定义，istio的服务发现就是中kube-apiserver中获取service和endpoint，然后将其转换成istio服务模型的service和serviceInstance，但是其数据面组件不再是kupe-proxy，而是每个pod里面部署的sidecar，可以看做是每个服务实例的proxy。所以proxy的粒度更细，通过拦截Pod的流量，并在sidecar上解析各种应用层协议，提供真正的应用层治理、监控和安全等能力。
1.5.2 k8s是istio的好基座
1.数据面
sidecar运行在k8s的pod中，应用完全无感知。
2.统一服务发现
istio的服务发现机制非常完美的基于k8s的域名访问机制构建而成。不需要新搭注册中心，且避免了服务发现中的数据不一致的问题
3.易于k8s CRD描述规则
istio的所有路由规则和控制策略都是通过k8s CRD实现的，因此各种规则策略对应的数据也被存储在kube-apiserver中
1.6 总结
微服务化的服务与容器在轻量、敏捷、快速部署运维等特征上的匹配
k8s在容器编排领域已经称为无可争辩的事实标准
istio与k8s的天然融合且基于k8s构建，也补充了k8s的治理能力
云原生采用k8s的服务编排能力，采用istio的服务治理能力，将逐渐称为企业转型的标准配置。