Istio - 读<<云原生网络Istio>> 笔记(一)

Istio - 读<<云原生网络Istio>> 笔记(一)

三月 06, 2020

利用几天时间,读了下<<云原生网络Istio>云原生网络Istio>。
发现它的强大之处,并且让我们能够更好的玩转微服务,所以做个笔记来梳理所看的就很有必要了。

Istio是什么?

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

服务治理的三种形态

  1. 应用程序中包含治理逻辑

    在微服务化的过程中,将服务拆分后会发现一堆麻烦事,连基本的业务连通都成为问题。  
    所以在处理一些治理逻辑,例如如何找到对端的服务实例,怎么选择一个对端实例请求时,  
    都需要自己用代码来实现。所以微服务越多,重复的代码越多,维护艰难,高度耦合。  
    这样不管是对治理逻辑升级还是对业务的升级,都要改同一段代码。如下图所示:  

    服务治理1形态

  2. 治理逻辑独立的代码

    在解决第一种形态的问题时,会很容易想到把治理的公共逻辑抽象成一个公用库,  
    让所有的微服务都适用这个公用库。也就是SDK模式(如下图),非常典型的框架就是spring cloud。  
    SDK模式虽然在代码上解耦了业务和治理逻辑,但业务代码和SDK还是要一起编译,还在同一个进程内。  
    所以会有几个问题:业务代码需要和SDK属于同一种语言。在治理逻辑升级时,还需要用户的整个服务升级。

    服务治理2形态

  3. 治理逻辑独立的进程

    SDK模式仍旧侵入了用户的代码,那就再解耦一层,把治理逻辑彻底从用户的业务代码中剥离出来,  
    就是如下图所示的Sidecar模式。  
    显然,在这种形态下面,用户的业务代码和治理逻辑都以独立的进程存在,  
    这样可以做到与开发语言无关,升级也相互独立。

    服务治理3形态

Service Mesh(服务网格)

实际上服务治理的第三种形态就可以认为是当前最流行概念Service Mesh的雏形。它有几个特点:

  • 治理能力独立(sidecar)
  • 应用程序无感知
  • 服务网格是一种处理服务通信的基础设施层

SerivceMesh

Istio问世

Istio功能
上图很好的归纳了Istio的一些功能点:
Istio关键能力
Istio关键能力

与Kubernetes完美结合

从场景上看Kubernetes已经提供了非常强大的应用负载的部署,升级,扩容等运行管理能力。K8s中的Service机制也已经可以做服务注册,服务发现和负载均衡,支持通过服务名访问到服务实例。
但是K8s对服务间访问的管理如服务的熔断,限流,动态路由,调用链追踪都不在它的能力范围内,所以Istio就成了K8s的最完美帮手。

完美帮手

Istio与Kubernetes架构关系

架构关系

  1. 数据面
    数据面Sidecar运行在Kubernetes的Pod里,作为一个Proxy和业务容器部署在一起。在服务网格的定义中要求应用程序在运行的时候感知不到Sidecar的存在。而基于Kubernetes的一个Pod多个容器的优秀设计使得部署运维对用户透明,用户甚至感知不到部署Sidecar的过程。用户还是用原有的方式创建负载,通过Istio的自动注入服务,可以自动给指定的负载注入Proxy。如果在另一种环境下部署和使用Proxy,则不会有这样的便利。

  2. 统一服务发现
    Istio的服务发现机制非常完美地基于Kubernetes的域名访问机制构建而成,省去了再搭一个类似Eureka的注册中心的麻烦,更避免了在Kubernetes上运行时服务发现数据不一致的问题。
    尽管Istio强调自己的可扩展性的重要性在于适配各种不同的平台,也可以对接其他服务发现机制,但在实际场景下,通过深入分析Istio几个版本的代码和设计,便可以发现其重要的能力都是基于Kubernetes进行构建的。

  3. 基于Kubernetes CRD描述规则
    Istio的所有路由规则和控制策略都是通过Kubernetes CRD实现的,因此各种规则策略对应的数据也被存储在Kube-apiserver中,不需要另外一个单独的APIServer和后端的配置管理。所以,可以说Istio的APIServer就是Kubernetes的APIServer,数据也自然地被存在了对应Kubernetes的etcd中。
    Istio非常巧妙地应用了Kubernetes这个好基座,基于Kubernetes的已有能力来构建自身功能。Kubernetes里已经有的,绝不再自己搞一套,避免了数据不一致和用户使用体验的问题。

好啦,后面会整理Istio中的一些基本概念和Demo。