【云原生 | 从零开始学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 的各组件的功能及相互之间的协作方式。

• 自动注入：在创建应用程序时自动注入 Sidecar 代理 Envoy 程序。在 Kubernetes 中创建 Pod 时，Kube-apiserver 调用控制面组件的 Sidecar-Injector 服务，自动修改应用程序的描述信息并注入Sidecar。在真正创建 Pod 时，在创建业务容器的 Pod 中同时创建 Sidecar 容器。
  
• 流量拦截：在 Pod 初始化时设置 iptables 规则，基于配置的 iptables 规则拦截业务容器的 Inbound 流量和 Outbound 流量到 Sidecar 上。而应用程序感知不到 Sidecar 的存在，还以原本的方式举行相互访问。上图中，流出 frontend 服务的流量会被frontend 服务侧的 Envoy 拦截，而当流量到达 forecast 容器时，Inbound 流量被 forecast 服务侧的 Envoy 拦截。
  
• 服务发现：服务发起方的 Envoy 调用控制面组件 Pilot 的服务发现接口获取目标服务的实例列表。上图中，frontend 服务侧的 Envoy 通过 Pilot 的服务发现接口得到 forecast 服务各个实例的地点。
  
• 负载平衡：服务发起方的 Envoy 根据配置的负载平衡策略选择服务实例，并连接对应的实例地点。上图中，数据面的各个 Envoy 从 Pilot 中获取 forecast 服务的负载平衡配置，并执行负载平衡动作。
  
• 流量治理：Envoy 从 Pilot 中获取配置的流量规则，在拦截到 Inbound（入境） 流量和 Outbound 流量时执行治理逻辑。上图中， frontend 服务侧的 Envoy 从 Pilot 中获取流量治理规则，并根据该流量治理规则将不同特性的流量分发到 forecast 服务的 v1 或 v2 版本。
  
• 访问安全：在服务间访问时通过两边的 Envoy 举行双向认证和通道加密，并基于服务的身份举行授权管理。上图中，Pilot 下发安全相关配置，在 frontend 服务和 forecast 服务的 Envoy 上自动加载证书和密钥来实现双向认证，其中的证书和密钥由另一个管理面组件 Citadel 维护。
  
• 服务监测：在服务间通信时，通信两边的 Envoy 都会连接受理面组件 Mixer 上报访问数据，并通过 Mixer 将数据转发给对应的监控后端。上图中，frontend 服务对 forecast 服务的访问监控指标、日记和调用链都可以通过这种方式收集到对应的监控后端。
  
• 策略执行：在举行服务访问时，通过 Mixer 连接后端服务来控礼服务间的访问，判定对访问是放行还是拒绝。上图中，Mixer 后端可以对接一个限流服务对从 frontend 服务到 forecast 服务的访问举行速率控制等操纵。
  
• 外部访问：在网格的入口处有一个 Envoy 饰演入口网关的角色。上图中，外部服务通过 Gateway 访问入口服务 frontend，对 frontend 服务的负载平衡和一些流量治理策略都在这个 Gateway 上执行。
  

sidecar 和 proxy 相生相伴，就像汽车与车轮。未来，sidecar 和 proxy 就指微服务历程解耦成两个历程之后，提供基础本领的谁人代理历程。
写在最后

创作不易，如果觉得内容对你有帮助，麻烦给个三连关注支持一下我！如果有错误，请在评论区指出，我会及时更改！
现在正在更新的系列：从零开始学istio
感谢各位的观看，文章掺杂个人明白，如有错误请接洽我指出~

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。