官方网站：https://istio.io/

Proxy

Proxy，就是SideCar，与应用程序部署在同一个主机上，应用程序之间的调用都通过Proxy来转发，目前支持HTTP/1.1、HTTP/2、gRPC以及TCP请求。
Istio的Proxy采用的是Envoy，Envoy既要作为服务消费者端的正向代理，又要作为服务提供者端的反向代理，一般需要具备服务发现、服务注册、负载均衡、限流降级、超时熔断、动态路由、监控上报和日志推送等功能，它主要包含以下几个特性：

  • 性能损耗低。因为采用了C++语言实现，Envoy能提供极高的吞吐量和极少的长尾延迟，而且对系统的CPU和内存资源占用也不大，所以跟业务进程部署在一起不会对业务进程造成影响。
  • 可扩展性高。Envoy提供了可插拔过滤器的能力，用户可以开发定制过滤器以满足自己特定的需求。
  • 动态可配置。Envoy对外提供了统一的API，包括CDS（集群发现服务）、RDS（路由发现服务）、LDS（监听器发现服务）、EDS（EndPoint发现服务）、HDS（健康检查服务）、ADS（聚合发现服务）等。通过调用这些API，可以实现相应配置的动态变更，而不需要重启Envoy。

Envoy是Istio中最基础的组件，所有其他组件的功能都是通过调用Envoy提供的API，在请求经过Envoy转发时，由Envoy执行相关的控制逻辑来实现的。

Control Plane

Control Plane，与Proxy通信，来实现各种服务治理功能，包括三个基本组件：Pilot、Mixer以及Citadel。

image.png

Pilot

Pilot主要包含以下几个部分：

  • Rules API，对外封装统一的API，供服务的开发者或者运维人员调用，可以用于流量控制。
  • Envoy API，对内封装统一的API，供Envoy调用以获取注册信息、流量控制信息等。
  • 抽象模型层，对服务的注册信息、流量控制规则等进行抽象，使其描述与平台无关。
  • 平台适配层，用于适配各个平台如Kubernetes、Mesos、Cloud Foundry等，把平台特定的注册信息、资源信息等转换成抽象模型层定义的平台无关的描述。

Istio - 图2
（图片来源：https://istio.io/docs/concepts/traffic-management/PilotAdapters.svg）
那么具体来讲，Pilot是如何实现流量管理功能的呢？

服务发现和负载均衡

就像下图所描述的那样，服务B也就是服务提供者注册到对应平台的注册中心中去，比如Kubernetes集群中的Pod，启动时会注册到注册中心etcd中。然后服务A也就是服务消费者在调用服务B时，请求会被Proxy拦截，然后Proxy会调用Pilot查询可用的服务提供者节点，再以某种负载均衡算法选择一个节点发起调用。
除此之外，Proxy还会定期检查缓存的服务提供者节点的健康状况，当某个节点连续多次健康检查失败就会被从Proxy从缓存的服务提供者节点列表中剔除。
Istio - 图3
（图片来源：https://istio.io/docs/concepts/traffic-management/LoadBalancing.svg）

请求路由

Pilot可以对服务进行版本和环境的细分，服务B包含两个版本v1.5和v2.0-alpha，其中v1.5是生产环境运行的版本，而v2.0-alpha是灰度环境运行的版本。当需要做A/B测试时，希望灰度服务B的1%流量运行v2.0-alpha版本，就可以通过调用Pilot提供的Rules API，Pilot就会向Proxy下发路由规则，Proxy在转发请求时就按照给定的路由规则，把1%的流量转发给服务B的v2.0-alpha版本，99%的流量转发给服务B的v1.5版本。
Istio - 图4
（图片来源：https://istio.io/docs/concepts/traffic-management/ServiceModel_Versions.svg）

超时重试

缺省状态下，Proxy转发HTTP请求时的超时是15s，可以通过调用Pilot提供的Rules API来修改路由规则，覆盖这个限制。比如下面这段路由规则，表达的意思是ratings服务的超时时间是10s。

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: VirtualService
  3. metadata:
  4.   name: ratings
  5. spec:
  6.   hosts:
  7.     - ratings
  8.   http:
  9.   - route:
  10.     - destination:
  11.         host: ratings
  12.         subset: v1
  13.     timeout: 10s

除此之外，还可以通过修改路由规则，来指定某些HTTP请求的超时重试次数，比如下面这段路由规则，表达的意思就是ratings服务的超时重试次数总共是3次，每一次的超时时间是2s。

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: VirtualService
  3. metadata:
  4.   name: ratings
  5. spec:
  6.   hosts:
  7.     - ratings
  8.   http:
  9.   - route:
  10.     - destination:
  11.         host: ratings
  12.         subset: v1
  13.     retries:
  14.       attempts: 3
  15.       perTryTimeout: 2s

故障注入

Istio还提供了故障注入的功能，能在不杀死服务节点的情况下，通过修改路由规则，将特定的故障注入到网络中。它的原理是在TCP层制造数据包的延迟或者损坏，从而模拟服务超时和调用失败的场景，以此来观察应用是否健壮。比如下面这段路由规则的意思是对v1版本的ratings服务流量中的10%注入5s的延迟。

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: VirtualService
  3. metadata:
  4.   name: ratings
  5. spec:
  6.   hosts:
  7.   - ratings
  8.   http:
  9.   - fault:
  10.       delay:
  11.         percent: 10
  12.         fixedDelay: 5s
  13.     route:
  14.     - destination:
  15.         host: ratings
  16.         subset: v1

而下面这段路由规则意思是对v1版本的ratings服务流量中的10%注入HTTP 400的错误。

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: VirtualService
  3. metadata:
  4.   name: ratings
  5. spec:
  6.   hosts:
  7.   - ratings
  8.   http:
  9.   - fault:
  10.       abort:
  11.         percent: 10
  12.         httpStatus: 400
  13.     route:
  14.     - destination:
  15.         host: ratings
  16.         subset: v1

Mixer

Mixer的作用是实现策略控制和监控日志收集等功能，实现方式是每一次Proxy转发的请求都要调用Mixer，它的架构请见下图。而且Mixer的实现是可扩展的，通过适配层来适配不同的后端平台，这样的话Istio的其他部分就不需要关心各个基础设施比如日志系统、监控系统的实现细节。
Istio - 图5
（图片来源：https://istio.io/docs/concepts/policies-and-telemetry/topology-without-cache.svg）
理论上每一次的服务调用Proxy都需要调用Mixer，一方面检查调用的合法性，一方面要上报服务的监控信息和日志信息，所以这就要求Mixer必须是高可用和低延迟的，那么Mixer是如何做到的呢？下图是它的实现原理，从图中你可以看到Mixer实现了两级的缓存结构：

  • Proxy端的本地缓存。为了减少Proxy对Mixer的调用以尽量降低服务调用的延迟，在Proxy这一端会有一层本地缓存，但由于Proxy作为SideCar与每个服务实例部署在同一个节点上，所以不能对服务节点有太多的内存消耗，所以就限制了Proxy本地缓存的大小和命中率。
  • Mixer的本地缓存。Mixer是独立运行的，所以可以在Mixer这一层使用大容量的本地缓存，从而减少对后端基础设施的调用，一方面可以减少延迟，另一方面也可以最大限度减少后端基础设施故障给服务调用带来的影响。

Istio - 图6
（图片来源：https://istio.io/docs/concepts/policies-and-telemetry/topology-with-cache.svg）
那么Mixer是如何实现策略控制和监控日志收集功能呢？
1.策略控制
Istio支持两类的策略控制，一类是对服务的调用进行速率限制，一类是对服务的调用进行访问控制，它们都是通过在Mixer中配置规则来实现的。具体来讲，速率限制需要配置速率控制的yaml文件，每一次Proxy转发请求前都会先调用Mixer，Mixer就会根据这个yaml文件中的配置，来对调用进行速率限制。比如下面这段配置表达的意思是服务默认访问的速率限制是每秒5000次，除此之外还定义了两个特殊限制，第一个是v3版本的reviews服务请求ratings服务的速率限制是每5秒1次，第二个是其他服务请求ratings服务的速率限制是每10秒5次。

  1. apiVersion: config.istio.io/v1alpha2
  2. kind: memquota
  3. metadata:
  4.   name: handler
  5.   namespace: istio-system
  6. spec:
  7.   quotas:
  8.   - name: requestcount.quota.istio-system
  9.     maxAmount: 5000
  10.     validDuration: 1s
  11.     overrides:
  12.     - dimensions:
  13.         destination: ratings
  14.         source: reviews
  15.         sourceVersion: v3
  16.       maxAmount: 1
  17.       validDuration: 5s
  18.     - dimensions:
  19.         destination: ratings
  20.       maxAmount: 5
  21.       validDuration: 10s

而访问控制需要配置访问控制的yaml文件，每一次Proxy转发请求前都会先调用Mixer，Mixer就会根据这个yaml文件中的配置，来对调用进行访问控制。比如下面这段配置表达的意思是v3版本的reviews服务调用ratings服务就会被拒绝。

  1. apiVersion: "config.istio.io/v1alpha2"
  2. kind: rule
  3. metadata:
  4.   name: denyreviewsv3
  5. spec:
  6.   match: destination.labels["app"] == "ratings" && source.labels["app"]=="reviews" && source.labels["version"] == "v3"
  7.   actions:
  8.   - handler: denyreviewsv3handler.denier
  9.     instances: [ denyreviewsv3request.checknothing ]

2.监控和日志收集
跟策略控制的实现原理类似，Mixer的监控、日志收集功能也是通过配置监控yaml文件来实现的，Proxy发起的每一次服务调用都会先调用Mixer，把监控信息发给Mixer，Mixer再根据配置的yaml文件来决定监控信息该发到哪。示例yaml文件可以参考这个链接。

Citadel

Citadel的作用是保证服务之间访问的安全，它的工作原理见下图，可见实际的安全保障并不是Citadel独立完成的，而是需要Proxy、Pilot以及Mixer的配合，具体来讲，

  • Citadel里存储了密钥和证书。
  • 通过Pilot把授权策略和安全命名信息分发给Proxy。
  • Proxy与Proxy之间的调用使用双向TLS认证来保证服务调用的安全。
  • 最后由Mixer来管理授权和审计。

Istio - 图7
（图片来源：https://istio.io/docs/concepts/security/architecture.svg）

参考

https://makeoptim.com/tags#Istio