Istio(1):hello Istio!

1. 是什么？

Istio是一个用于服务治理的开放平台。

服务治理涉及连接（Connect）、安全 （Secure）、策略执行（Control）和可观察性（Observe）

• 连接：Istio 通过集中配置的流量规则控制服务间的流量和调用，实现负载均衡、熔断、故障注入、重试、重定向等服务治理功能。
• 安全：Istio 提供透明的认证机制、通道加密、服务访问授权等安全能力，可增强服务访问的安全性。
• 策略执行：Istio 通过可动态插拔、可扩展的策略实现访问控制、速率限制、配额管理、服务计费等能力。
• 可观察性：动态获取服务运行数据和输出，提供强大的调用链、监控和调用日志收集输出的能力。配合可视化工具，可方便运维人员了解服务的运行状况，发现并解决问题。

Istio 0.1 发布时 ，官方强调了Istio提供的重要能力。

• 服务运行可观察性：监控应用及网络相关数据，将相关指标与日志记录发送至任意收集、聚合与查询系统中以实现功能扩展，追踪分析性能热点并对分布式故障模式进行诊断。
• 弹性与效率：提供了统一的方法配置重试、负载均衡、流量控制和断路器等来解决网络可靠性低所造成的各类常见故障，更轻松地运维高弹性服务网格。
• 研发人员生产力：确保研发人员专注于基于已选择的编程语言构建业务功能，不用在代码中处理分布式系统的问题，从而极大地提升生产能力。
• 策略驱动型运营：解耦开发和运维团队的工作，在无须更改代码的前提下提升安全性、监控能力、扩展性与服务拓扑水平。运营人员能够不依赖开发提供的能力精确控制生产流量。
• 默认安全：允许运营人员配置TLS双向认证并保护各服务之间的所有通信，并且开发人员和运维人员不用维护证书，以应对分布式计算中经常存在的大量网络安全问题。
• 增量适用：允许团队按照自己的节奏和需求逐步使用各项功能，例如先观察服务运行情况再进行服务治理等。

2.示例

以天气预报应用中forecast服务对recommendation服务的访问为例。

在forecast服务的代码中通过域名访问recommendation服务，在两个服务中都不用包含任何服务访问管理的逻辑。

而Istio在其中都做了什么：

• 自动通过服务发现获取recommendation服务实例列表，根据负载均衡策略选择一个服务实例；
• 对服务双方启用双向认证和通道加密；
• 如果某个服务实例连续访问出错，则可以将该实例隔离一段时间，以提高访问质量；
• 设置最大连接数、最大请求数、访问超时等对服务进行保护；
• 限流；
• 对请求进行重试；
• 修改请求中的内容；
• 将一定特征的服务重定向；
• 灰度发布；
• 自动记录服务访问信息；
• 记录调用链，进行分布式追踪；
• 根据访问数据形成完整的应用访问拓扑；

这些功能都只需在 Istio 的控制面做些配置，并且动态生效。以灰度发布为例，通过简单配置即可实现，其核心工作是实现两个版本同时在线，并通过一定的流量策略将部分流量引到灰度版本上。无须修改业务代码，只要简单写一个配置就可以对任意一个服务进行灰度发布了

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: recommendation
spec:
  hosts:
  - recommendation
  http:
  - match:
    - headers:
      cookie:
        exact: "group-dev"
    route:
    - destination:
        name: v2
  - route:
    - destination:
        name: v1

Istio采用了与K8s类似的语法风格：将 group 是 dev 的流量转发到 recommendation服务的 v2版本，其他用户还是访问 v1版本，从而达到从 v1版本中切分少部分流量到灰度版本 v2的效果。

3. 与服务治理

Istio是一个服务治理平台，治理的是服务间的访问，只要有访问就可以治理，不在乎服务是不是微服务，也不要求跑在其上的代码是微服务化的。单体应用不满足微服务的若干哲学，用Istio 治理也是完全可以的。提起"服务治理"，大家最先想到的一定是"微服 务的服务治理"，就让我们从微服务的服务治理说起。

3.1 关于微服务

"微服务是以一组小型服务来开发单个应用的方法，每个服务都运行在自己的进程中，服务间采用轻量级通信机制（通常用 HTTP 资源API）。这些服务围绕业务能力构建并可独立部署，还共用一个最小型的集中式管理，可用不同的语言开发，并使用不同的数据存储技术"。微服务在本质上还是分而治之、化繁为简的哲学的体现。

微服务将复杂的单体应用分解成若干小的服务，服务间使用轻量级的协议进行通信。这种方式有很多好处：

• 开发视角：每个微服务的功能更内聚，可以在微服务内设计和扩展功能，并且采用不同的开发语言及开发工具；
• 运维视角：在微服务化后，每个微服务都在独立的进程里，可以自运维；更重要的是，微服务化是单一变更的基础，迭代速度更快，上线风险更小；
• 组织管理视角：将团队按照微服务切分为小组代替服务大组也有利于敏捷开发。

但微服务化也给开发和运维带来很大的挑战：业务本身的规模和复杂度变多。

在分布式系统中，网络可靠性、通信安全、网络时延、网络拓扑变化等都是要关注的内容。另外，微服务带来了大量的工作，比如服务如何请求目标服务，需要引入服务发现和负载均衡等，以及对跨进程的分布式调用栈进行分布式调用链 追踪，等等。

这需要一些工具来做一些通用的工作，包括服务注册、服务发现、负载均衡等。在未微服务化时，单体应用的多模块之 间不需要进程间通信，也不需要服务发现。所以这些工具集仅用于解决微服务化带来的新问题，却并没有带来更多的业务收益。

3.2 服务治理的三种形态

1. 在业务代码中包含治理逻辑，服务越多，重复代码越多
2. 抽象成公共库，但还是对业务进程有侵入
3. 以sidecar的形式进行：将治理逻辑放在单独进程内

4. 与服务网格

• 基础设施：服务网格是一种处理服务间通信的基础设施层。
• 云原生：服务网格尤其适用于在云原生场景下帮助应用程序在复杂的服务拓扑间可靠地传递请求。
• 网络代理：服务网格一般是通过一组轻量级网络代理来执行治理逻辑的。
• 对应用透明：轻量网络代理与应用程序部署在一起，但应用感知不到代理的存在，还是使用原来的方式工作。

天下没有免费的午餐，sidecar在服务的访问链路上多引入的两跳也是不容回避的问题。

从forecast服务到recommendation服务的一个访问必须要经过forecast的 Sidecar拦截 Outbound流量执行治理动作；再经过 recommendation的 Sidecar拦截Inbound流量，执行治理动作。这就引入两个问题：

1. 增加了两处延迟和可能的故障点；
2. 多出来的这两跳对于访问性能、整体可靠性及整个系统的复杂度都带来了新的挑战。

后者本来就属于基础设施层面可维护性、可靠性的范畴，产品都用各自的方式在保证。而前者引入的性能和资源损耗，通过保证转发代理的轻量和高性能降低时延影响，而后端应用一般比代理更重，叠加代理并不会明显影响应用的访问性能

5. 与k8s

5.1 istio：k8s的好帮手

K8s提供了非常强大的应用负载的部署、升级、扩容等能力。它的 Service 机制也已经可以做服务注册、服务发现和负载均衡，支持通过服务名访问到服务实例。它本身是支持微服务的架构，在Pod中部署微服务很合适，也解决了微服务的互访互通问题，但对服务间访问的管理如服务的熔断、限流、动态路由、调用链追踪等都不在K8s的能力范围内。那如何提供一套从底层的负载部署运行到上层的服务访问治理端到端的解决方案？目前最完美的答案就是在K8s上叠加Istio

K8s的Service基于每个节点的Kube-proxy从Kube-apiserver上获取Service和Endpoint 的信息，并将对 Service 的请求经过负载均衡转发到对应的 Endpoint 上。但K8s只提供了4层负载均衡能力，无法基于应用层的信息进行负载均衡，更不会提供应用层的流量管理，在服务运行管理上也只提供了基本的探针机制，并不提供服务访问指标和调用链追踪这种应用的服务运行诊断能力。

Istio复用了Service的定义，在实现上进行了更细粒度的控制 。 Istio的服务发现就是从 Kube-apiserver 中获取 Service 和 Endpoint ，将其转换成 Istio 服务模型的 Service 和 ServiceInstance，但是其数据面组件不再是 Kube-proxy，而是在每个 Pod 里部署的 Sidecar，也可以将其看作每个服务实例的 Proxy。这样 Proxy 的粒度就更细了，和服务实例的联系也更紧密了，可以做更多更细粒度的服务治理。

通过拦截Pod的Inbound流量和Outbound流量，并在Sidecar上解析各种应用层协议，Istio可以提供真正的应用层治理、监控和安全等能力。

5.2 k8s：istio的好基座

Istio最大化地利用了K8s这个基础设施，与之形成了一个更强大的用于进行服务运行和治理的基础设施，并提供了更 透明的用户体验。

1. 数据面
   数据面Sidecar运行在K8s的Pod里，作为一个Proxy和业务容器部署在一起。在服务网格的定义中要求应用程序在运行时感知不到Sidecar的存在。而基于K8s的一个 Pod 多个容器的优秀设计使得部署运维对用户透明，用户甚至感知不到部署 Sidecar的过程。
   用户还是用原有的方式创建负载，通过 Istio 的自动注入服务，自动给指定的负载注入Proxy。
2. 统一服务发现
   Istio的服务发现机制非常完美地基于K8s的域名访问机制构建而成，省去了再搭一个注册中心的麻烦，更避免了在 K8s 上运行时服务发现数据不一致的问题。
3. 基于K8s CRD描述规则
   Istio的所有路由规则和控制策略都是通过 K8s CRD实现的，因此各种规则策略对应的数据也被存储在 Kube-apiserver 中，不需要另外的 APIServer 和后端的配置管理。可以说Istio 的APIServer就是K8s的APIServer，数据也自然地被存在了对应 K8s的etcd中。 Istio巧妙地应用了K8s这个基座，基于其已有能力来构建自身功能，避免了数据不一致和用户使用体验的问题。

Istio不仅数据面Envoy跑在K8s的Pod里，其控制面也运行在K8s 集群中，控制面组件本身存在的形式也是K8s Deployment和 Service，基于K8s扩展和构建

总结