带你玩转Istio-第1篇---原理篇

 Kubernetes我们学了一个大概，现在学习Istio加深一下我们对Kubernetes的认识。

 

自本篇起，Istio 的学习之旅就正式开始了。本篇主要介绍 Istio 的功能特性及工作原理，呈现Istio丰富的流量治理、策略与遥测、访问安全等功能，以及Sidecar机制和多集群服务治理方面的内容。结合后面的实践内容，读者可以掌握 Istio 的使用方法，例如怎样使用 Istio 的流量规则、怎样配置安全策略、怎样使用 Istio 的 Adapter 来做策略控制和收集服务运行的遥测数据等。

您好，Istio

本章简要介绍Istio的一些背景知识，包括Istio是什么、能干什么，以及Istio项目的诞生及发展历史，并尝试梳理Istio与微服务、服务网格、Kubernetes这几个云原生领域炙手可热的技术概念的关系。希望读者能通过本章对 Istio 有一个初步的认识，并带着问题与思考进入后续的学习中。

Istio是什么？

Istio是什么？我们试着用迭代方式来说明。
◎ Istio是一个用于服务治理的开放平台。
◎ Istio是一个Service Mesh形态的用于服务治理的开放平台。
◎ Istio是一个与Kubernetes紧密结合的适用于云原生场景的Service Mesh形态的用于服务治理的开放平台。

这里的关键字“治理”不局限于“微服务治理”的范畴，任何服务，只要服务间有访问，如果需要对服务间的访问进行管理，就可以使用 Istio。根据 Istio 官方的介绍，服务治理涉及连接（Connect）、安全（Secure）、策略执行（Control）和可观察性（Observe），如图1-1所示。

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

在 Istio 0.1 发布时，Istio 官方的第 1 篇声明（https：//istio.io/blog/2017/0.1-announcement/）强调了Istio提供的重要能力。

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

通过示例看看Istio能做什么

首先看看 Istio 在服务访问的过程中都做了什么，简单起见，这里以一个天气预报应用中forecast服务对recommendation服务的访问为例，如图1-2所示。本书后面的大部分功能都会基于该应用来介绍。

                                                    图1-2 Istio服务访问示例

这个示例对两个服务的业务代码没有任何要求，可以用任何语言开发。在这个示例中，forecast服务是用Node.js开发的，recommendation服务是用Java开发的。在forecast服务的代码中通过域名访问recommendation服务，在两个服务中都不用包含任何服务访问管理的逻辑。

我们看看Istio在其中都做了什么：
◎ 自动通过服务发现获取recommendation服务实例列表，并根据负载均衡策略选择一个服务实例；
◎ 对服务双方启用双向认证和通道加密；
◎ 如果某个服务实例连续访问出错，则可以将该实例隔离一段时间，以提高访问质量；
◎ 设置最大连接数、最大请求数、访问超时等对服务进行保护；

◎ 限流；
◎ 对请求进行重试；
◎ 修改请求中的内容；
◎ 将一定特征的服务重定向；
◎ 灰度发布；
◎ 自动记录服务访问信息；
◎ 记录调用链，进行分布式追踪；
◎ 根据访问数据形成完整的应用访问拓扑；
◎……

所有这些功能，都不需要用户修改代码，用户只需在 Istio 的控制面做些配置即可，并且动态生效。以灰度发现为例，在 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采用了与Kubernetes类似的语法风格，即使不了解语法细节，也很容易明白其功能大意：将 group是 dev的流量转发到 recommendation服务的 v2版本，其他用户还是访问 recommendation服务的 v1版本，从而达到从 v1版本中切分少部分流量到灰度版本 v2的效果。对Istio提供的功能都进行类似配置即可，无须修改代码，无须额外的组件支持，也无须其他前置和后置操作。

Istio与服务治理

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

关于微服务

Martin Fowler对微服务的描述是“微服务是以一组小型服务来开发单个应用程序的方法，每个服务都运行在自己的进程中，服务间采用轻量级通信机制（通常用 HTTP 资源API）。这些服务围绕业务能力构建并可通过全自动部署机制独立部署，还共用一个最小型的集中式管理，可用不同的语言开发，并使用不同的数据存储技术”，参见 https：//martinfowler.com/articles/microservices.html。

可以看出，微服务在本质上还是分而治之、化繁为简的哲学智慧在计算机领域的一个体现。

如图1-3所示，微服务将复杂的单体应用分解成若干小的服务，服务间使用轻量级的协议进行通信。

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

                                                                 图1-3 微服务化

但是，微服务化也给开发和运维带来很大的挑战，因为微服务化仅仅是一种分而治之的方法，业务本身的规模和复杂度并没有变少，反而变多。如图1-4所示，在分布式系统中，网络可靠性、通信安全、网络时延、网络拓扑变化等都成了我们要关注的内容。另外，微服务机制带来了大量的工作，比如服务如何请求目标服务，需要引入服务发现和负载均衡等，以及对跨进程的分布式调用栈进行分布式调用链追踪，等等。总之，简单的事情突然变得复杂了。

                                                 图1-4 微服务化带来的分布式问题

这就需要一些工具集来做一些通用的工作，包括服务注册、服务发现、负载均衡等。在原来未微服务化的时候，单体应用的多模块之间根本不需要进程间通信，也不需要服务发现。所以，我们将这些工具集理解为用于解决微服务化带来的新问题似乎更合理一些，但是这些工具集本身并没有带来更多的业务收益。

服务治理的三种形态

服务治理的演变至少经过一下三种形态。

第1中形态：在应用程序中包含治理逻辑
       在微服务化的过程中，将服务拆分后会发现一堆麻烦事儿，连基本的业务连通都成了问题。如图1-5所示，在处理一些治理逻辑，比如怎么找到对端的服务实例，怎么选择一个对端实例发出请求等时，都需要自己写代码来实现。这种方式简单，对外部依赖少，但会导致存在大量的重复代码。所以，微服务越多，重复的代码越多，维护越难；而且，业务代码和治理逻辑耦合，不管是对治理逻辑的全局升级，还是对业务的升级，都要改同一段代码。

                              图1-5 第1种形态：在应用程序中包含治理逻辑

第2中形态：治理逻辑独立代码

在解决第1种形态的问题时，我们很容易想到把治理的公共逻辑抽象成一个公共库，让所有微服务都使用这个公共库。在将这些治理能力包含在开发框架中后，只要是用这种开发框架开发的代码，就包含这种能力，这就是如图 1-6 所示的 SDK 模式，非常典型的这种服务治理框架就是Spring Cloud。这种形态的治理工具集在过去一段时间里得到了非常广泛的应用。

                                            图1-6 第2种形态：治理逻辑独立的代码

此外，SDK对开发人员来说有较高的学习门槛，虽然各种SDK都会讲如何开箱即用，但如果只是因为需要治理逻辑，就让开发人员放弃自己熟悉的内容去学习一套新的语言和开发框架，可能代价有点大。

第3中形态：治理逻辑独立的进程

SDK模式仍旧侵入了用户的代码，那就再解耦一层，把治理逻辑彻底从用户的业务代码中剥离出来，这就是如图1-7所示的Sidecar模式。

                                                             图1-7 第3种形态：治理逻辑独立的进程

显然，在这种形态下，用户的业务代码和治理逻辑都以独立的进程存在，两者的代码和运行都无耦合，这样可以做到与开发语言无关，升级也相互独立。在对已存在的系统进行微服务治理时，只需搭配 Sidecar 即可，对原服务无须做任何修改，并且可以对老系统渐进式升级改造，先对部分服务进行微服务化。

比较以上三种服务治理形态，我们可以看到服务治理组件的位置在持续下沉，对应用的侵入逐渐减少，如表1-1所示。

                                                  表1-1 三种服务治理形态的比较

Istio不只解决了微服务问题

微服务作为一种架构风格，更是一种敏捷的软件工程实践，说到底是一套方法论；与之对应的 Istio 等服务网格则是一种完整的实践，Istio 更是一款设计良好的具有较好集成及可扩展能力的可落地的服务治理工具和平台。

所以，微服务是一套理论，Istio是一种实践。但是，Istio是用来解决问题的，并不是微服务理论的一种落地，在实际项目中拿着微服务的细节列表来硬套 Istio 的功能，比如要求Istio治理的服务必须实现微服务的服务注册的一些细节，就明显不太适当。

从场景来看，Istio管理的对象大部分是微服务化过的，但这不是必需的要求。对于一个或多个大的单体应用，只要存在服务间的访问要进行治理，Istio也适用。实际上，传统行业的用户业务需要在容器化后进行服务治理，Istio是用户非常喜欢的形态，因为不用因为服务治理而修改代码，只需将业务搬到 Istio 上即可，如果需要将业务微服务化，则可以渐进式进行。

从能力来看，Istio对服务的治理不只包含在微服务中强调的负载均衡、熔断、限流这些一般治理能力，还包含诸多其他能力，例如后续章节重点讲到的提供可插拔的服务安全、可扩展的控制策略、服务运行可观察性等更广泛的治理能力。在 Istio 中提供的是用户管理运维服务需要的能力，而不是在微服务教科书中定义的能力。

所以，过多地谈论Istio和微服务的关系，倒不如多关注Istio和Kubernetes的结合关系。Kubernetes和云原生实际上已经改变或者重新定义了软件开发的很多方面，再想一想微服务世界正在发生的事情，我们也许会慢慢地习惯微服务回归本源，即用更加通用和松散的理论在新的形态下指导我们的工作。

小结：

           本节内容到此结束。