istio简介和知识_springcloud网格服务istio

istio是一种服务网格概念技术。

背景和简介：

springcloud 痛点：

 1侵入性强：会和业务代码混在一块，如放jar包，需要加自定义注解等
 2 升级成本高：一旦修改jar包，即使跟业务无关都要整体测试
 3 版本碎片化严重： 服务越多越分散，很难统一管理
 4 中间件演变难： 需要兼容老版本逻辑
 5 治理功能不全： 灰度发布不支持，需要自己写
1
2
3
4
5

service mesh 服务网格都能完成

service mesh：是一个专门处理服务通信的基础设施层，将原本复杂的请求变的简单，且对应用服务透明化
总结：

• 由一堆紧挨着各项服务的用户代理，外加一组任务管理流程组成。如一个业务服务会伴随着一个sidecar
• 两部分组成：数据平面和控制平面。用户代理称为数据层或数据平面（Data Plane），管理流程称为控制层或控制平面（Control Plane）
• 一个专用的基础设施层，在微服务架构中实现可靠，快速安全的服务间调用
• 服务不能直接通过网络调用服务，而是调用他们的sidecar代理，有sidecar来管理请求
• 将SDK大部分功能剥离出来，拆解为独立进程，以sidecar模型进行部署，完全与业务解耦。比如traceId也可以剥离
• 异构系统统一治理，由于与业务剥离，一些jdk jvm也会剥离，从而跨语言
• 服务的流入和流出的流量由sidecar代理进行转发，把手流入和流出网格的流量，也称入口网关和出口网关

数据平面和控制平面

控制平面特点：

 不直接解析数据包
 下发策略和配置
 负责网络行为的可视化
 提供api或者命令行工具，可配置版本化，便于持续集成和部署
1
2
3
4

数据平面特点：

 处理入站和出站数据包，如转发，路由，健康检查，负载均衡，认证，监控数据
 对应用无感知
1
2

服务网格优势（称为第二代微服务架构）：

可观察性： 以前日志都在日志文件里，现在再基础设施层，方便查看
流量控制： 只能路由（蓝绿部署，金丝雀发布，AB测试），超时重试，熔断，故障注入等
安全：服务认证，服务间通信加密，以前服务间调用http形式容易被攻击
1
2
3

k8s原生通过kube-proxy通信，服务网格有一层控制平面进行通信

k8s ingress 与 istio gateway说明

ingress：是接收外部请求的，属于南北流量，只适用于http流量。无法路由mysq，redis这样的tcp流量，只能到业务服务比如8080端口
istio gateway： 和ingress功能类似，负责南北流量，使用的xDS协议

xDS协议由Envoy提出，一个服务发现，配置路由，监听路由关系的协议,支持http和tcp协议
istio的sidecar用的就是 envoy

istio包含功能：

流量管理：基本功能
策略控制： 通过Mixer组件控制遥测捕获，配额管理，计费等
可观测性：通过Mixer实现
安全认证： 通过Citadel组件做秘钥和证书管理
定义了CRD来进行流量管理（下面类型就是资源文件）
           Gateway:  负载均衡器，接收传入传出的http/tcp连接（网关）
           VirtualService：将k8s服务连接到istio gateway上。定义一组路由 ，（虚拟服务）
           DestinationRule：定义路由策略（目标规则）
           EnvoyFilter： 过滤器
           ServiceEntry：手动加入mesh以外的服务（服务入口）
1
2
3
4
5
6
7
8
9
10

总结：istio4个重要大功能（流量，安全，监控）

   为http，grpc，websocker，tcp流量自动负载均衡
   通过路由规则，重试，故障转移，故障注入对流量进行精细控制
   完善的可观察性功能，日志记录和追踪
   提供身份认证实现安全的服务间通信
1
2
3
4

核心功能

流量控制：主要3个方面

  请求路由和流量转移
  弹性功能 熔断，超时和重试
  调试能力，故障注入和流量镜像
1
2
3

理论：

金丝雀发布：发布新服务，让5%的流量进入新服务，没问题后在慢慢加大比重

请求路由和流量转移：

  istio引入服务版本（version）概念，通过版本打标记，istio就可以灵活的定义路由规则，实现流量控制。如上诉的金丝雀发布。版本很灵活可以是环境+版本号，如pod-v1.5test
1

弹性功能: 支持超时，重试和熔断

  超时：响应时间超过时间上限，就直接返回快速失败。在路由配置中添加timeout
  重试：由于网络抖动活程序导致失败，再来一次 。在路由配置中添加retry
  熔断：一共3个状态，关闭状态（程序没问题），开启状态（失败次数超过失败计数器上限），半开状态（设置一个超时时钟，过段时间后开启状态改为半开状态。让请求进来，程序成功则关闭状态，失败则继续开启）。
         通过设置DestinationRule的Traffic Policy来完成
1
2
3
4

调试能力：对流量进行调试快速定位问题

  故障注入：给某个服务注入一个延迟或中断的故障，看下游服务调用时的表现。从而来看整个数据平面的抗压性。配置路由中添加fault关键字
 流量镜像： 复制流量，复制一份请求发送到镜像服务中，进行问题排查。把线上的正式请求原班到流量镜像里，还原现象，在打开debug日志看详细信息。配置路由中添加mirror关键字
1
2

流量控制的实现：

实现流量控制的6个自定义资源
VirtualService ：用于网格内路由的设置
DestinationRule：定义路由的目标服务和流量策略
ServiceEntry： 注册外部服务到网格内，并对其流量进行管理
Gateway： 控制进出网格的流量，包括入口，出口网关
Sidecar: 对Sidecar代理进行整体设置
WorkLoadEntry/WorkLoadGroup: 将虚拟机接入网格
istio通过这些自定义资源，实现了对网格内部，外部和进出网络边界流量的全面控制。所有与网格交互流量全被控制

可观察性

对服务进行监控，上报分析快速定位问题，提供可靠性。提供3种不同类型的数据进行观察

• 指标（Metrics）：检测服务，将响应延迟，流量大小，饱和度写入到prometheus，来看变化趋势。说白了看服务的各项指标
• 日志（Access Logs）：istio会记录请求的完整记录，包括请求源，目标，元数据，放到elk去查看
• 分布式追踪（Distribeted traces）：istio通过traceid将日志串联起来，通过zipkin查看调用流程

istio的架构组成

数据平面：由一个个sidecar代理组成，一个sidecar和一个应用该服务一块部署，管理流量
控制平面：管理sidecar，完成配置分发，服务发现，授权鉴权
架构特点：

• 1对应用透明：服务和网络彻底分开
• 2 可扩展性：定义Mixer组件（策略控制器）公共化，开发人员可以通过接入各种适配器实现多样化的策略需求
• 3 可移植性：可移植到其他k8s上
• 4 策略一致性：istio使用API将策略独立出来，而不是在sidecar中，使的sidecar的规则都一致而且复用

总结

控制平面：主要为数据包的快速转发准备必要信息，如路由协议，设备管理信息，ARP
数据平面： 主要负责高速处理和转发数据包

控制平面

管理sidecar ，三大组件pilot,Citedel 和 Galley
pilot：管理配置部署所有sidecar实例，管理sidecar之间的路由流量规则，并配置故障恢复功能，如超时，重试熔断
 
  抽象模型：实现注册中心，记录hostname(service名称)，Port（端口），Address ClusterIP虚拟IP，Resolution负载均衡策略
1
2
3
4

平台适配器：适配k8s
XDS API：一套数据平面API，将服务信息和流量规则下发到Sidecar。Sidecar通过xDS API可以动态获取Listener（监听器），Route路由，Cluster集群，Endpoint集群成员（XDS 就是discovery service 发现服务，专门注册各种信息服务）
LDS: Listener发现服务
RDS：Route路由发现服务
CDS：Cluster发现服务，用于动态获取Cluster信息
EDS：动态维护端点信息，包括负载均衡权重，金丝雀状态等
用户API：提供面向业务的高级抽象，给开发人员使用。将该API定义的规则下发到Pilot中，从而下发到sidecar实例进行精细化控制，如版本分流，断路器，故障注入，灰度发布

暂时介绍这些概念和大致功能，到后面章节会一步步深入！