istio in kubernetes (一) --原理篇

背景

微服务是什么

• 服务之间有轻量级的通讯机制，通常为REST API
• 去中心化的管理机制
• 每个服务可以使用不同的编程语言实现，使用不同的数据存储技术
• 应用按业务拆分成服务，一个大型应用系统可以由多个独立的服务组成
• 各个服务均可独立部署，都有自己的业务逻辑
• 服务可被多个应用共享，其他服务可复用一些公共的资源服务

微服务的优势

• 模块化开发，以单个服务为组件进行更新升级，提升系统整体异常稳定性
• 模块化开发管理方便，单独团队开发维护，职责分明
• 模块服用，公共服务模块可被其他业务模块使用
• 系统架构更加分明
• 结合CI/CD，实现DevOPS
• 弹性伸缩，结合服务编排K8S动态HPA
• 服务熔断/降级，避免但节点异常雪崩效应，分散故障节点

微服务带来的挑战

• 服务越来越多，配置管理维护复杂
• 服务间依赖关系复杂
• 服务调用链追踪难
• 服务之间的负载均衡
• 服务的拓展
• 服务监控/日志
• 服务熔断/降级
• 服务鉴权
• 服务上线与下线
• 服务文档

微服务架构和单体架构的对比

因素	单体架构	微服务架构	说明
故障隔离	线程级	进程级	微服务独立运行，通过进程的方式隔离，使故障范围得到有效控制，架构变得更可靠
整体可用性	较低	较高	微服务架构由于故障得到有效隔离，整体可用性更高，有效降低了单点故障对整体的影响
架构持续演进	困难	容易	微服务的粒度更小，架构演进的影响面相应也更小，架构演进不需要大规模重构，只需调整个别微服务即可
可重用性	低	高	微服务架构可以实现以服务为粒度，通过接口共享重用
可扩展性	笨重	灵活	微服务架构可以根据服务对资源的要求以服务为粒度进行扩展，而单体应用只能整体进行扩展
交付速递	较慢	较快	服务拆分后，各个服务可以独立进行开发、测试、部署、交付效率大大提升，产品更新换代速度更快，用户体验更好

什么是微服务治理

微服务之间一旦建立起路由，就意味着会有数据在服务之间流通。由于不同服务可以提供的资源和对数据流量的承载能力不尽相同，为了防止单个 Consumer(消费者) 占用 Provide(生产者） 过多的资源，或者突发的大流量冲击导致 Provider 故障，需要服务限流来保证服务的高可用。

在服务治理中，虽然可以通过限流规则尽量避免服务承受过高的流量，但是在实际生产中服务故障依然难以完全避免。当整个系统中某些服务产生故障时，如果不及时采取措施，这种故障就有可能因为服务之间的互相访问而被传播开来，最终导致故障规模的扩大，甚至导致整个系统奔溃，这种现象我们称之为“雪崩”。熔断降级其实不只是服务治理中，在金融行业也有很广泛的应用。比如当股指的波动幅度超过规定的熔断点时，交易所为了控制风险采取的暂停交易措施。

针对以微服务带来的方便以及挑战，从裸金属到虚拟化再到公有云，再到容器，到serverless，技术不断革新，应对微服务带来的挑战，如何对服务进行注册发现，请求链路追踪，负载均衡，服务熔断/降级，服务限流，访问控制，监控日志，配置管理，金丝雀发布呢

微服务治理istio

Service Mesh

Service Mesh 的中文译为“服务网格”，是一个用于处理服务和服务之间通信的基础设施层，它负责为构建复杂的云原生应用传递可靠的网络请求，并为服务通信实现了微服务所需的基本组件功能，例如服务发现、负载均衡、监控、流量管理、访问控制等。在实践中，服务网格通常实现为一组和应用程序部署在一起的轻量级的网络代理，但对应用程序来说是透明的。

服务网格（Service Mesh）这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长，服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。

服务网格技术对企业现有分布式系统架构的影响主要体现在系统分层和能力下沉。传统微服务框架以 RPC 框架为基础，提供服务目录、注册发现、服务治理、流量管理、配置中心、全链路追踪等核心能力，并且向外延伸到安全审计、监控告警、统计分析、知识库等平台化能力，服务网格技术要做的事情就是把这些微服务架构支撑能力下沉到 Sidecar 里，并且在这个改造过程中不中断业务。要做到这个过程平滑，除了在服务网格数据面和控制面组件中对服务注册发现、RPC 协议、配置下发进行扩展之外，还要对现有的上层的研发工作台、运维效能平台等支撑平台进行兼容。

Istio 提供了一个完整的解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。

Service Mesh 部署网络结构图:

Service Mesh有四大特点：

• 治理能力独立（Sidecar）
• 应用程序无感知
• 服务通信的基础设施层
• 解耦应用程序的重试/超时、监控、追踪和服务发现

如此一来，Service Mesh将业务模块和服务治理分开。

从上图中看到，控制面和数据面分离，应用在部署的时候，每个应用附带一个SideCar，这个SideCar是拦截每一个应用对外请求的。同时控制面的服务治理策略下到SideCar中具体的执行，这样的话，即使业务模块升级和服务治理的升级也能互不影响的，还能动态调整服务治理的规则和策略。

从Service Mesh的结构和特点，可以总结出其对于服务治理的理念：

1、微服务治理与业务逻辑解耦：把大部分SDK能力从应用中剥离出来，并拆解为独立进程，以 sidecar 的模式进行部署。

2、异构系统的统一治理：方便多语言的实施，解锁升级带来的困难。

3、价值：

（1）可观察性：服务网格捕获诸如来源、目的地、协议、URL、状态码、延迟、持续时间等线路数据；

（2）流量控制：为服务提供智能路由、超时重试、熔断、故障注入、流量镜像等各种控制能力。

（3）安全性高：服务的认证、服务间通讯的加密、安全相关策略的强制执行；

（4）健壮性：支持故障注入，对于容灾和故障演练等健壮性检验帮助巨大。

以Service Mesh的杰出代表Istio为例来聊聊最新的服务治理的架构，它对Service Mesh完全支持，架构清晰，拆分数据面、控制面；拥有通信、安全、控制、观察等功能，实现开放，且插件化，多种可选实现。

Istio可结合K8S使用，K8S提供服务生命周期的管理，Istio在K8S之上实现服务治理的整体的功能。

Istio 概述

Isito是Service Mesh的产品化落地，是目前最受欢迎的服务网格，功能丰富、成熟度高。 Linkerd是世界上第一个服务网格类的产品

中文文档地址：https://istio.io/latest/zh/docs/

Istio 近几个版本持续演进的方向：把控制面组件合并为 istiod 和完善 istioctl 的集群生命周期管理能力来降低运维复杂性；将 Mixer 组件能力下沉到 Sidecar 降低服务东西向网络延时；增加对虚拟机的原生支持，便于非容器化业务平滑迁移……等等，这其中的每一项都是业务生产落地 Istio 时面临的痛点问题。

主要有以下特点

• 连接（Connect）

- 流量管理

通过简单的规则配置和流量路由，您可以控制服务之间的流量和 API 调用。Istio 简化了断路器、超时和重试等服务级别属性的配置，并且可以轻松设置 A/B测试、金丝雀部署和基于百分比的流量分割的分阶段部署等重要任务。

通过更好地了解您的流量和开箱即用的故障恢复功能，您可以在问题出现之前先发现问题，使调用更可靠，并且使您的网络更加强大——无论您面临什么条件。

- 负载均衡
- 灰度发布 
- 动态路由
- 故障注入

• 安全（Secure）

Istio 的安全功能使开发人员可以专注于应用程序级别的安全性。Istio 提供底层安全通信信道，并大规模管理服务通信的认证、授权和加密。使用Istio，服务通信在默认情况下是安全的，它允许您跨多种协议和运行时一致地实施策略——所有这些都很少或根本不需要应用程序更改。

虽然 Istio 与平台无关，但将其与 Kubernetes（或基础架构）网络策略结合使用，其优势会更大，包括在网络和应用层保护 pod 间或服务间通信的能力。

- 认证
- 鉴权

• 控制（Control）

- 限流
- ACL

• 观察（Observe）

Istio 强大的追踪、监控和日志记录可让您深入了解服务网格部署。通过 Istio 的监控功能，可以真正了解服务性能如何影响上游和下游的功能，而其自定义仪表板可以提供对所有服务性能的可视性，并让您了解该性能如何影响您的其他进程。

Istio 的 Mixer 组件负责策略控制和遥测收集。它提供后端抽象和中介，将 Istio 的其余部分与各个基础架构后端的实现细节隔离开来，并为运维提供对网格和基础架构后端之间所有交互的细粒度控制。

所有这些功能可以让您可以更有效地设置、监控和实施服务上的 SLO。当然，最重要的是，您可以快速有效地检测和修复问题。

- 监控
- 调用链

主要应用于服务治理：

• 注：此图isito ???

Isito 架构与组件

注：此页中图片引用自Istio官网

• Envoy - 也就是图中的Proxy，有时候也叫Sidecar。 每个微服务中的Sidecar代理处理集群内服务之间的入口/出口流量以及到外部服务的入口/出口流量。这个代理构成一个安全的微服务网格，提供丰富的功能集，如发现、丰富的7层路由、熔断、策略执行和遥测记录/报告功能。
• Istiod - Istio控制平面。提供服务发现、配置和证书管理。它由以下子部分组成：
• Pilot - 负责在运行时配置代理。为Envoy sidecar提供服务发现功能，为智能路由（例如A/B测试、金丝雀部署等）和弹性（超时、重试、熔断器等）提供流量管理功能；它将控制流量行为的高级路由规则转换为特定于Envoy的配置，并在运行时将它们传播到sidecar；
• Citadel - 负责证书颁发和轮换。通过内置身份和凭证管理赋能强大的服务间和最终用户身份验证；可用于升级服务网格中未加密的流量，并为运维人员提供基于服务标识而不是网络控制的强制执行策略的能力；
• Galley - 负责Istio内部的验证、采集、聚合、转换和分发配置。
• Operator - 该组件提供用户友好的选项来操作Istio服务网格。

◆ 性能总结

Istio 负载测试网格包含了 1000 个服务和 2000 个 sidecar，全网 格范围内，QPS 为 70,000。 在使用 Istio 1.6.2 运行测试后，我们 得到了如下结果：

• 通过代理的 QPS 有 1000 时，Envoy 使用了 0.5 vCPU 和 50 MB 内存。

• 网格总的 QPS 为 1000 时，istio-telemetry 服务使用了 0.6 vCPU。

• Pilot 使用了 1 vCPU 和 1.5 GB 内存。

• 90% 的情况 Envoy 代理只增加了 6.3 ms 的延迟

注：此页中图片和数据引用自Istio官网

东西南北流量

• 本节整理自网络

先看一张图

• 说明：
• VM_B3有FIP，其它VM没有FIP
• 红色数据流：跨服务器东西流量
• 紫色数据流：服务器内东西流量
• 蓝色数据流：没有FIP场景，VM访问外网
• 橙色数据流：有VIP场景，VM访问外网，外网访问VM

在Service Mesh微服务架构中，我们常常会听到东西流量和南北流量两个术语。

南北流量（NORTH-SOUTH traffic）和东西流量（EAST-WEST traffic）是数据中心环境中的网络流量模式。下面通过一个例子来理解这两个术语。

假设我们尝试通过浏览器访问某些Web应用。Web应用部署在位于某个数据中心的应用服务器中。在多层体系结构中，典型的数据中心不仅包含应用服务器，还包含其他服务器，如负载均衡器、数据库等，以及路由器和交换机等网络组件。假设应用服务器是负载均衡器的前端。

当我们访问web应用时，会发生以下类型的网络流量：

• 客户端（位于数据中心一侧的浏览器）与负载均衡器（位于数据中心）之间的网络流量
• 负载均衡器、应用服务器、数据库等之间的网络流量，它们都位于数据中心。

南北流量

在这个例子中，前者即客户端和服务器之间的流量被称为南北流量。简而言之，南北流量是server-client流量。

东西流量

第二种流量即不同服务器之间的流量与数据中心或不同数据中心之间的网络流被称为东西流量。简而言之，东西流量是server-server流量。

当下，东西流量远超南北流量，尤其是在当今的大数据生态系统中，比如Hadoop生态系统（大量server驻留在数据中心中，用map reduce处理），server-server流量远大于server-client流量。

该命名来自于绘制典型network diagrams的习惯。在图表中，通常核心网络组件绘制在顶部（NORTH），客户端绘制在底部（SOUTH），而数据中心内的不同服务器水平（EAST-WEST）绘制。