Istio的架构与技术

一. Service Mesh

假设我们部署一个web 应用的服务，除了应用本身的功能之外， 可能还需要监控，日志采集，服务间的通讯等功能，如果将这些功能统一放到一个容器中，web应用的体积会变得很大，不便于维护，这种情况下， 我们可以将监控，日志采集，服务间的通讯等功能单独部署在这个Pod 中的另外一个container（容器）中， 这种将应用程序的功能划分为单独的进程可以被视为 Sidecar 模式，Sidecar 在软件系统架构中特指边车模式，这个模式的灵感来源于我们生活中的边三轮：即在两轮摩托车的旁边添加一个边车的方式扩展现有的服务和功能。这个模式的精髓在于实现了数据面（业务逻辑）和控制面的解耦：原来两轮摩托车的驾驶者集中注意力跑赛道，边车上的领航员专注周围信息和地图，专注导航。随着微服务越来越多，sidecar也就越来越多，自然就形成了一个网格，即service mesh。

二. Istio 架构基础

Istio是一个Service Mesh开源项目（serviceMesh理解抽象概念，istio实现这种概念）

1. istio能力

灰度发布：灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B测试，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度，降低风险。
故障注入：一种可靠性验证技术，通过受控实验向系统中刻意引入故障，并观察系统中存在故障时的行为。

2. istio和kubernetes的互补

Kubernetes 具有强大的容器编排与调度能力，但是他的服务治理能力极其有限。istio很好的补充了k8s的缺陷，使二者进行了完美的互补（两者都属于谷歌，完美互补也很正常）

名称和图标：istio(起航) kubernetes(领航员)

3. Istio架构

Istio 服务网格从逻辑上分为数据平面和控制平面：
istio-proxy：istio 的sidecar（istio-proxy）是开源项目envoy的扩展版，Envoy是用C++开发的非常有影响力的轻量级高性能开源服务代理。作为服务网格的数据面，是istio架构中唯一的数据面组件， Envoy 提供了动态服务发现、负载均衡、TLS , HTTP/2 及gRPC 代理、熔断器、健康检查、流量拆分、灰度发布、故障注入等功能。
pilot: 是istio的控制中枢, 有两个作用，一是服务发现，获取被调用服务的实例，二是负责将各种规则转换成Envoy 可识别的格式，下发给Envoy。
Mixer：Pilot 负责将各种规则转换成Envoy 可识别的格式