Istio 系列篇一 | 服务网格和 Istio

gopher云原生

发布于 2021-12-24 13:16:40

1K0

发布于 2021-12-24 13:16:40

文章被收录于专栏：gopher云原生gopher云原生

这是「 Istio 系列」的第一篇文章。

作为本系列的开篇，主要介绍服务网格所解决的痛点，以及 Istio 的功能和组件。

本篇大纲

在之前的一篇文章 云原生思想 中，说过软件架构是从 单体 -> 微服务 -> 基于 k8s 上的微服务 -> 服务网格 逐步演进的。

而原因，在文章中也给出了答案：

为了将业务和基础设施解耦

这短短一句话却是服务架构的终极目标。

微服务架构的难题：服务治理

微服务架构流行至今，沉淀出了一套属于自己的模式[1]：

微服务模式

图中几个主要的点：

Communication patterns（通信模式）
1. Style（风格）：通信机制的选择。有远程过程调用（Remote Procedure Invocation）、消息（Messaging）和领域独用协议（Domain-specific protocol）。
2. Service registry（服务注册）：用于记录服务实例位置的服务注册表。
3. Service discovery（服务发现）：通过查询服务注册表获取服务实例的位置。有客户端服务发现（Client-side discovery）和服务器端服务发现（Server-side discovery）两种模式。
4. Reliability（可靠性）：当调用远端服务返回的故障率超过一定的阀值时，需要使用断路器（Circuit Breaker）熔断服务调用方和远端服务的调用链并立刻返回失败的信息，以防止引发服务雪崩现象。
5. External API（外部 API）：外部客户端与服务之间的通讯。需要引入 API 网关（API gateway），为了让后端 API 满足不同的前端使用场景，可能还需要引入 BFF 层，即服务前端的后端（Backend for front-end）。
Security（安全）
1. 服务实例之间可以通过在请求头携带访问令牌（Access Token）等方式来安全地传递客户端的身份信息。
Observability（可观测性）
1. 应用日志（Log aggregation）：聚合应用程序产生的日志文件。
2. 审计日志（Audit logging）：把用户行为记录在数据库中供日后核查。
3. 应用指标（Application metrics）：在代码中实现收集应用运营过程中各类指标的功能。
4. 分布式追踪（Distributed tracing）：在服务代码中针对每一个外部访问，都分配一个唯一的标识符，并在跨服务访问时传递这个标识符以供追踪分布式引发的问题。
5. 异常追踪（Exception tracking）：把所有服务程序代码触发的异常信息都汇聚到集中的异常追踪服务，并根据一定的逻辑对开发者或运维人员发出通知。
6. 健康检查 API（Health check API）：一个监控服务可调用的 API，通常返回服务健康度信息，或对 ping 等心跳检查请求做出响应。

这些 非业务性 的基础功能都是 微服务需要治理的问题 。

我们把上述长篇大论所涉及的功能点提炼一下：

微服务治理

可以看出微服务治理还是蛮多东西的，要是我们一一来手动解决，岂不累死去。因此各种微服务框架出场了，比如 Java 体系的 Spring Cloud ，Go 体系的 kratos、Go Zero 和 Go Kit 等。这些框架的共同点都是 用来帮助我们在开发过程中快速引入各种服务治理的组件。

当然，你还可以把大部分的功能下沉到 Kubernetes 来解决，如服务注册发现，负载均衡等。

下沉到基础设施层：服务网格

上面我们说到，微服务架构的难题：服务治理 ，可以通过微服务框架引入各种治理组件。

但这种方式带有 侵入性 ，想要集成某种治理功能，除了引入相关依赖库，还需要 在业务代码中增加非业务功能的代码或注解 。另外，治理组件往往还比较复杂，开发人员需要一定的学习周期才能 快速上手业务开发 。

除此之外，还有升级成本高、版本碎片化严重、中间件演变困难、治理功能不全等 问题[2] 存在。

即便我们还可以搭配 Kubernetes 来解决大部分的治理功能，减轻 业务开发 的压力，但并不意味着可以省心了。在细粒化的层面上，Kubernetes 往往是心有余而力不足。

熔断、限流、监控、认证、授权、安全、负载均衡等都有可能面临 细化管理的需求[3] 。例如服务调用时的负载均衡，往往需要根据流量特征，调整负载均衡的层次、算法等，而 Kubernetes 的 DNS 尽管能实现一定程度的负载均衡，但通常并不能满足这些额外的需求。

这也证明了 软件开发没有银弹 。

为了应对上诉的痛点，服务架构再次演进到了 服务网格（Service Mesh） 。

什么是服务网格

Service Mesh 的起源可以追溯到 2016-09-29 ，由开发出 Linkerd 的 Buoyant 公司在 SF Microservices 公开场合上首次提出。这也正式让 Service Mesh 的概念从 Buoyant 公司内部走向社区。

Servicemesh布道[4]

自此，Service Mesh ，国内翻译作 服务网格 ，以其独特的理念，开始流行，甚至在技术社区，有人指出 Service Mesh 将会是下一代的微服务架构基础。

服务网格到底有多大的魔力。

Buoyant 公司的 CEO Willian Morgan 在他的这篇文章 WHAT’S A SERVICE MESH? AND WHY DO I NEED ONE?[5] 中解释了什么是 Service Mesh，以及为什么云原生应用需要 Service Mesh。

总结一下，大概是：

服务网格被定义为一个专门的基础设施层，用于管理服务与服务之间的通信，使其可管理、可见、可控制。服务网格负责通过构成现代云原生应用的复杂服务拓扑来可靠地传递请求。服务网格通常是作为一组轻量级的网络代理与应用程序部署在一起，应用程序是无感知的。

按照服务网格的定义，最终我们会得到如下的部署模型：

图源 pattern_service_mesh[6]

绿色部分是实际的应用程序，蓝色部分便是网络代理，这在服务网格中被称为 Sidecar （边车模式，类似连接到摩托车的边车），Sidecar 边车应用与应用程序共享相同的生命周期，与应用程序一起创建和退出。

Sidecar 只负责 服务间网络通信 。还需要有个组件来统一管理所有 Sidecar 的配置。在服务网格中，负责配置管理的部分就叫 控制平面（control plane） ，负责网络通信的部分叫 数据平面（data plane） 。数据平面和控制平面一起构成了服务网格的基本架构 。

pattern_service_mesh

在服务网格中，所有出站入站的流量都会通过 Sidecar 进行 处理和转发 ，这样之前所说的 微服务治理的功能就可以由服务网格来承担了 。

最重要的是服务网格不需要在应用层面加入额外的处理代码（非侵入性），就可以提供几乎不亚于程序代码级别的细化管理能力。

侵入式微服务框架 => 基于 Kubernetes 完成大部分微服务治理功能 => 基于服务网格解耦微服务治理和业务逻辑。

归根结底，就是那个宗旨：为了将业务和基础设施解耦 ，让业务开发人员专心实现业务，而无需理会业务无关的功能。

另提一嘴。服务网格和 Kubernetes 是相辅相成的关系 。Kubernetes 的本质是对应用的部署和管理，服务网格是对 Kubernetes 中的 Service 更上层的抽象 。而 Sidecar 就是作为一个 边车代理容器和业务应用容器共同部署在 Pod 里面 。

图源 istio-handbook[7]

服务网格的实现：Istio

业界第一款服务网格产品是 Buoyant 公司开发的 Linkerd ，如果说它是第一代产品，那么 Istio[8] 就是现今服务网格的第二代产品。本篇就不过多讲述它们之间的爱恨情仇了。如果感兴趣，可以在 Service Mesh 的发展史[9] 中了解。

相比于侵入式架构，非侵入式的服务网格最大的特性就是 对应用透明 。

作为现今服务网格的明星级产品，Istio 可以非常轻松地创建出一个网络，将微服务应用接入进来，而服务的代码只需很少甚至无需更改。

Istio 通过在整个环境中部署一个特殊的 Sidecar 代理为服务添加 Istio 的支持，而代理会拦截微服务之间的所有网络通信，然后使用其控制平面的功能来配置和管理 Istio，这包括：

为 HTTP、gRPC、WebSocket 和 TCP 流量自动负载均衡。
通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制。
可插拔的策略层和配置 API，支持访问控制、速率限制和配额。
集群内（包括集群的入口和出口）所有流量的自动化度量、日志记录和追踪。
在具有强大的基于身份验证和授权的集群中实现安全的服务间通信。

即便有不同的需求，由于 Istio 的 可扩展性 设计，也都可以轻松应对。

Istio 功能

从宏观上看，Istio 以统一的方式提供了许多跨服务网络的关键功能：

流量管理利用 Istio 的规则配置和流量路由功能，我们可以控制服务之间的流量和 API 调用过程。服务级属性（如熔断器、超时和重试等）都可以通过简单的配置改变来完成。
安全 Istio 提供了底层的安全通信通道，我们可以在代理层面管理服务间通信的认证、授权和加密过程。
可观测性 Istio 健壮的追踪、监控和日志特性能够让我们深入的了解服务网络内部。而且 Istio 还提供了一个拥有对所有服务性能可视化能力的 Dashboard 。

Istio 组件

我们说过服务网格从逻辑上分为 数据平面和控制平面 。

数据平面：由一组智能代理组成，被部署为 Sidecar。这些代理负责协调和控制微服务之间的所有网络通信。它们还收集和报告所有网格流量的遥测数据。
控制平面：管理并配置代理来进行流量路由。

在 Istio 中数据平面默认使用 Envoy 作为 Sidecar 代理（也支持使用 MOSN ），而控制平面则由 Istiod 提供支持。

Istio 架构

Envoy（数据平面）

Envoy[10] 是一个用 C++ 开发的高性能代理。

Istio 将 Envoy 代理作为一个 Sidecar 容器注入到应用容器旁边，之后该代理拦截该服务所有入站和出站流量。

这些注入的 Envoy 代理们一起构成了服务网格的数据平面，并且在 Istio 中， Envoy 代理是唯一与数据平面流量交互的组件。

除了负载均衡、断路器、故障注入等基本功能，Envoy 还支持基于 WebAssembly（WASM）的可插拔扩展模型。这种可扩展性使我们能够执行自定义策略，并为网格中的流量生成遥测数据。

Istiod（控制平面）

在 Istio 1.5 版本之前，控制平面的 Pilot、Citadel 和 Galley 组件是分散、独立部署的。而之后，出于 性能和易用性 方面考虑，这三个组件整合为一个单体结构 Istiod 。因此 Istio 的控制平面是一个 单进程、多模块 的组织形态。

Istiod 主要提供服务发现、配置和证书管理等功能。

Istiod 将采用 YAML 编写的控制流量行为的高级路由规则转换为 Envoy 特定配置，并在运行时把这个配置传播给网格中的所有 Sidecar。

按模块进一步细分的话：

Pilot 模块：抽象出特定平台的服务发现机制（Kubernetes、Consul 或 VM），并将其转化成 Sidecar 可以使用的 标准格式 。
Citadel 模块：负责安全模块，内置 身份和凭证管理 ，可以实现强大的认证授权等操作。
Galley 模块：将 Pilot 和底层平台（如 Kubernetes）进行解耦。分担了原本 Pilot 的一部分功能，主要负责 配置的验证、提取和处理 等功能。