istio核心特性

  • Istio 核心特性
    • 断路器
    • 超时
    • 重试
    • 多路由规则
  • Istio 架构
  • 写在最后

Istio 核心特性

1、流控(traffic management)
断路器(circuit breakers)、超时、重试、多路由规则、AB 测试、灰度发布、按照百分比分配流量等。

2、安全(security)
加密、身份认证、服务到服务的权限控制、K8S 里容器到容器的权限控制等。

3、可观察(observability)
追踪、监控、数据收集，通过控制后台全面了解上行下行流量，服务链路情况，服务运行情况，系统性能情况，国内微服务架构体系，这一块做得比较缺乏。

4、平台无关系(platform support)
K8s，物理机，自己的虚机都没问题。

5、集成与定制(integration and customization)
可定制化扩展功能。

断路器

举个生活中的例子解释断路器

当电路发生故障或异常时，伴随着电流不断升高，并且升高的电流有可能能损坏电路中的某些重要器件，也有可能烧毁电路甚至造成火灾。若电路中正确地安置了保险丝，那么保险丝就会在电流异常升高到一定的高度和热度的时候，自身熔断切断电流，从而起到保护电路安全运行的作用。

很多技术都是来源生活的，随着社会进步，科技发展，断路器也称为服务熔断，在多个服务调用的时候，服务 A 依赖服务 B，服务 B 依赖服务 C，如果服务C 响应时间过长或者不可用，则会让服务 B 占用太多系统资源，而服务 A 也依赖服 B，同时也在占用大量的系统资源，造成系统雪崩的情况出现。 Istio 断路器通过网格中的边车对流量进行拦截判断处理，避免了在代码中侵入控制逻辑，非常方便的就实服务熔断的能力。

在微服务架构中，在高并发情况下，如果请求数量达到一定极限（可以自己设置阈值），超出了设置的阈值，断路器会自动开启服务保护功能，然后通过服务降级的方式返回一个友好的提示给客户端（非计算机专业可能看不懂504这种错误码）。假设当 10 个请求中，有 10%失败时，熔断器就会打开，此时再调用此服务，将会直接返回失败，不再调远程服务。直到 10s 钟之后，重新检测该触发条件，判断是否把熔断器关闭，或者继续打开。

服务降级（提高用户体验效果）

比如电商平台，在针对 618、双 11 的时候会有一些秒杀场景，秒杀的时候请求量大，可能会返回报错标志“当前请求人数多，请稍后重试”等，如果使用服务降级，无法提供服务的时候，消费者会调用降级的操作，返回服务不可用等信息，或者返回提前准备好的静态页面写好的信息。

超时

什么时候需要用到超时？

在生产环境中经常会碰到由于调用方等待下游的响应过长，堆积大量的请求阻塞了自身服务，造成雪崩的情况，通过超时处理来避免由于无限期等待造成的故障，进而增强服务的可用性。通过例子来理解

nginx 服务设置了超时时间为 3 秒，如果超出这个时间就不在等待，返回超时错误
httpd 服务设置了响应时间延迟 5 秒，任何请求都需要等待 5 秒后才能返回
client 通过访问 nginx 服务去反向代理 httpd 服务，由于 httpd 服务需要 5 秒后才能返回，但 nginx 服务只等待 3 秒，所以客户端会提示超时错误。

重试

istio 重试机制就是如果调用服务失败，Envoy 代理尝试连接服务的最大次数。而默认情况下，Envoy 代理在失败后并不会尝试重新连接服务。
举个例子：

客户端调用 nginx，nginx 将请求转发给 tomcat。tomcat 通过故障注入而中止对外服务，nginx 设置如果访问 tomcat 失败则会重试 3 次。

多路由规则

1、HTTP 重定向（HTTPRedirect）

2、HTTP 重写（HTTPRewrite）

3、HTTP 重试（HTTPRetry）

4、HTTP 故障注入（HTTPFaultInjection）

5、HTTP 跨域资源共享（CorsPolicy）

Istio 架构

istio 服务网格从逻辑上分为数据平面和控制平面。

1、数据平面由一组以 Sidecar（边车）方式部署的智能代理(Envoy+Polit-agent)组成。这些代理承载并控制微服务之间的所有网络通信，管理入口和出口流量，类似于一线员工。 Sidecar 一般和业务容器绑定在一起（在 Kubernets 中以自动注入的方式注入到到业务 pod 中），来劫持业务应用容器的流量，并接受控制面组件的控制，同时会向控制面输出日志、跟踪及监控数据，Envoy 和 pilot-agent 打在同一个镜像中，即 sidecar Proxy。

2、control plane 控制平面负责管理和配置代理来路由流量。
istio1.5+中使用了一个全新的部署模式，重建了控制平面，将原有的多个组件整合为一个单体结构istiod，这个组件是控制平面的核心，管理 Istio 的所有功能，主要包括 Pilot、Mixer、Citadel 等服务组件。

istiod 是新版本中最大的变化，以一个单体组件替代了原有的架构，降低了复杂度和维护难度，但原有的多组件并不是被完全移除，而是在重构后以模块的形式整合在一起组成了 istiod。

结合下图我们来理解 Istio 的各组件的功能及相互之间的协作方式。

  1. 自动注入：在创建应用程序时自动注入 Sidecar 代理 Envoy 程序。在 Kubernetes 中创建 Pod 时，Kube-apiserver 调用控制面组件的 Sidecar-Injector 服务，自动修改应用程序的描述信息并注入Sidecar。在真正创建 Pod 时，在创建业务容器的 Pod 中同时创建 Sidecar 容器。

  2. 流量拦截：在 Pod 初始化时设置 iptables 规则，基于配置的 iptables 规则拦截业务容器的 Inbound 流量和 Outbound 流量到 Sidecar 上。而应用程序感知不到 Sidecar 的存在，还以原本的方式进行互相访问。上图中，流出 frontend 服务的流量会被frontend 服务侧的 Envoy 拦截，而当流量到达 forecast 容器时，Inbound 流量被 forecast 服务侧的 Envoy 拦截。

  3. 服务发现：服务发起方的 Envoy 调用控制面组件 Pilot 的服务发现接口获取目标服务的实例列表。上图中，frontend 服务侧的 Envoy 通过 Pilot 的服务发现接口得到 forecast 服务各个实例的地址。

  4. 负载均衡：服务发起方的 Envoy 根据配置的负载均衡策略选择服务实例，并连接对应的实例地址。上图中，数据面的各个 Envoy 从 Pilot 中获取 forecast 服务的负载均衡配置，并执行负载均衡动作。

  5. 流量治理：Envoy 从 Pilot 中获取配置的流量规则，在拦截到 Inbound（入境） 流量和 Outbound 流量时执行治理逻辑。上图中， frontend 服务侧的 Envoy 从 Pilot 中获取流量治理规则，并根据该流量治理规则将不同特征的流量分发到 forecast 服务的 v1 或 v2 版本。

  6. 访问安全：在服务间访问时通过双方的 Envoy 进行双向认证和通道加密，并基于服务的身份进行授权管理。上图中，Pilot 下发安全相关配置，在 frontend 服务和 forecast 服务的 Envoy 上自动加载证书和密钥来实现双向认证，其中的证书和密钥由另一个管理面组件 Citadel 维护。

  7. 服务监测：在服务间通信时，通信双方的 Envoy 都会连接管理面组件 Mixer 上报访问数据，并通过 Mixer 将数据转发给对应的监控后端。上图中，frontend 服务对 forecast 服务的访问监控指标、日志和调用链都可以通过这种方式收集到对应的监控后端。

  8. 策略执行：在进行服务访问时，通过 Mixer 连接后端服务来控制服务间的访问，判断对访问是放行还是拒绝。上图中，Mixer 后端可以对接一个限流服务对从 frontend 服务到 forecast 服务的访问进行速率控制等操作。

  9. 外部访问：在网格的入口处有一个 Envoy 扮演入口网关的角色。上图中，外部服务通过 Gateway 访问入口服务 frontend，对 frontend 服务的负载均衡和一些流量治理策略都在这个 Gateway 上执行。

sidecar 和 proxy 相生相伴，就像汽车与车轮。未来，sidecar 和 proxy 就指微服务进程解耦成两个进程之后，提供基础能力的那个代理进程。

写在最后

创作不易，如果觉得内容对你有帮助，麻烦给个三连关注支持一下我！如果有错误，请在评论区指出，我会及时更改！

目前正在更新的系列：从零开始学istio

感谢各位的观看，文章掺杂个人理解，如有错误请联系我指出~