简介

服务网格从总体架构上来讲比较简单，不过是一堆紧挨着各项服务的用户 代理 ，外加一组 任务管理流程 组成：

• 代理：在服务网格中被称为 数据层 或 数据平面 （data plane）， 截获 不同服务之间的调用并对其进行 处理

• 管理流程：被称为 控制层 或 控制平面 （control plane）， 协调 代理的行为，并为运维人员提供 API，用来操控和测量整个网络

  

更进一步地说，服务网格是一个专用的基础设施层，旨在“在微服务架构中实现可靠、快速和安全的服务间调用”。它不是一个“服务”的网格，而是一个“代理”的网格，服务可以插入这个代理，从而使网络抽象化。在典型的服务网格中：

• 这些代理作为一个 sidecar （边车）被 注入 到每个 服务部署 中
• 服务不直接通过网络调用服务，而是 调用 它们 本地的 sidecar 代理 ，而 sidecar 代理又代表服务 管理请求 ，从而封装了服务间通信的复杂性
• 相互连接的 sidecar 代理集 实现了所谓的数据平面，这与用于 配置代理 和 收集指标 的服务网格组件（控制平面）形成对比

      总而言之，Service Mesh 的基础设施层主要分为两部分： 控制平面 与 数据平面

      当前流行的两款开源服务网格 Istio 和 Linkerd 实际上都是这种构造

控制平面的特点：

• 不直接解析数据包
• 与控制平面中的代理通信，下发策略和配置
• 负责网络行为的可视化
• 通常提供 API 或者命令行工具可用于配置版本化管理，便于持续集成和部署。

数据平面的特点：

• 通常是按照无状态目标设计的，但实际上为了提高流量转发性能，需要缓存一些数据，因此无状态也是有争议的
• 直接处理入站和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等
• 对应用来说透明，即可以做到无感知部署

      那么服务网格的出现带来了哪些变革呢？

• 微服务治理与业务逻辑的解耦 ：服务网格把 SDK 中的大部分能力从应用中剥离出来，拆解为独立进程，以 sidecar 的模式进行部署。服务网格通过将服务通信及相关管控功能从业务程序中分离并下沉到基础设施层，使其和业务系统完全解耦，使开发人员更加专注于业务本身

      注意，这里提到了一个词“大部分”，SDK 中往往还需要保留协议编解码的逻辑，甚至在某些场景下还需要一个轻量级的 SDK 来实现细粒度的治理与监控策略

      例如，要想实现方法级别的调用链追踪，服务网格则需要业务应用实现 trace ID 的传递，而这部分实现逻辑也可以通过轻量级的 SDK 实现

      因此，从代码层面来讲，服务网格并非是零侵入的

• 异构系统的统一治理 ：随着新技术的发展和人员更替，在同一家公司中往往会出现不同语言、不同框架的应用和服务，为了能够统一管控这些服务，以往的做法是为每种语言、每种框架都开发一套完整的 SDK，维护成本非常之高，而且给公司的中间件团队带来了很大的挑战。有了服务网格之后，通过将主体的服务治理能力下沉到基础设施，多语言的支持就轻松很多了。只需要提供一个非常轻量级的 SDK，甚至很多情况下都不需要一个单独的 SDK，就可以方便地实现多语言、多协议的统一流量管控、监控等需求

服务网格相对于传统微服务框架，还拥有三大技术优势：

• 可观察性：因为服务网格是一个专用的基础设施层，所有的服务间通信都要通过它，所以它在技术堆栈中处于独特的位置，以便在服务调用级别上提供统一的遥测指标。这意味着，所有服务都被监控为“黑盒”。服务网格捕获诸如来源、目的地、协议、URL、状态码、延迟、持续时间等线路数据

      这本质上等同于 web 服务器日志可以提供的数据，但是服务网格可以为所有服务捕获这些数据，而不仅仅是单个服务的 web 层

      需要指出的是，收集数据仅仅是解决微服务应用程序中可观察性问题的一部分，存储与分析这些数据则需要额外能力的机制的补充，然后作用于警报或实例自动伸缩等

• 流量控制：通过 Service Mesh，可以为服务提供智能路由（蓝绿部署、金丝雀发布、A/B test）、超时重试、熔断、故障注入、流量镜像等各种控制能力

      以上这些往往是传统微服务框架不具备，但是对系统来说至关重要的功能

      例如，服务网格承载了微服务之间的通信流量，因此可以在网格中通过规则进行故障注入，模拟部分微服务出现故障的情况，对整个应用的健壮性进行测试

      由于服务网格的设计目的是有效地将来源请求调用连接到其最优目标服务实例，所以这些流量控制特性是“面向目的地的”，这正是服务网格流量控制能力的一大特点

• 安全：在某种程度上，单体架构应用受其单地址空间的保护。然而，一旦单体架构应用被分解为多个微服务，网络就会成为一个重要的攻击面。更多的服务意味着更多的网络流量，这对黑客来说意味着更多的机会来攻击信息流。而服务网格恰恰提供了保护网络调用的能力和基础设施。服务网格的安全相关的好处主要体现在以下三个核心领域： 服务的认证 、 服务间 通讯的加密 、 安全相关策略的强制执行

然而就像之前说的软件开发没有银弹，传统微服务架构有许多痛点，而服务网格也不例外，也有它的局限性：

• 增加了复杂度：服务网格将 sidecar 代理和其它组件引入到已经很复杂的分布式环境中，会极大地增加整体链路和操作运维的复杂性
• 运维人员需要更专业：在容器编排器（如 Kubernetes）上添加 Istio 之类的服务网格，通常需要运维人员成为这两种技术的专家，以便充分使用二者的功能以及定位环境中遇到的问题
• 延迟：从链路层面来讲，服务网格是一种侵入性的、复杂的技术，可以为系统调用增加显著的延迟。这个延迟是毫秒级别的，但是在特殊业务场景下，这个延迟可能也是难以容忍的
• 平台的适配：服务网格的侵入性迫使开发人员和运维人员适应高度自治的平台并遵守平台的规则

      展望未来，Kubernetes 正在爆炸式发展，它已经成为企业应用的容器编排的首选

      如果说 Kubernetes 已经彻底赢得了市场，并且基于 Kubernetes 的应用程序的规模和复杂性持续增加，那么就会有一个临界点，而服务网格则将是有效管理这些应用程序所必需的

      随着服务网格技术的持续发展，其实现产品（如 Istio）的架构与功能的不断优化，服务网格将完全取代传统微服务架构，成为大小企业微服务化和上云改造的首选架构

Kubernetes 集群的每个节点都部署了一个 kube-proxy 组件，该组件会与 Kubernetes API Server 通信，获取集群中的 service 信息，然后设置 iptables 规则 ，直接将对某个 service 的请求发送到对应的 Endpoint（属于同一组 service 的 pod）上

Istio Service Mesh 可以沿用 Kubernetes 中的 service 做服务注册，还可以通过控制平面的平台适配器对接其他服务发现系统，然后生成数据平面的配置（使用 CRD 声明，保存在 etcd 中）：

数据平面的透明代理以 sidecar 容器 的形式 部署 在每个 应用服务的 pod 中：

• 这些 proxy 都需要请求 控制平面 来 同步 代理配置
• 透明代理，是因为应用程序容器完全无感知代理的存在
• 该过程 kube-proxy 组件一样需要拦截流量：
  • 现在kube-proxy 拦截的是进出 Kubernetes 节点的流量
  • sidecar proxy 拦截的是进出该 Pod 的流量

kube-proxy 的不足之处：

• 如果转发的 pod 不能正常提供服务，它不会自动尝试另一个 pod，当然这个可以通过 liveness probes 来解决。每个 pod 都有一个健康检查的机制，当有 pod 健康状况有问题时，kube-proxy 会删除对应的转发规则
• nodePort 类型的服务也无法添加 TLS 或者更复杂的报文路由机制

Kube-proxy 实现了流量在 Kubernetes service 多个 pod 实例间的负载均衡，但是如何对这些 service 间的流量做细粒度的控制，比如按照百分比划分流量到不同的应用版本

如果这些应用都属于同一个 service，但位于不同的 deployment 上，怎么做金丝雀发布（灰度发布）和蓝绿发布?

Kubernetes 社区给出了 使用 Deployment 做金丝雀发布的方法，该方法本质上就是通过修改 pod 的 label 来将不同的 pod 划归到 Deployment 的 Service 上

• CDS、EDS、LDS、RDS 是最基础的 xDS 协议，它们可以分别独立更新
  • CDS 设置 Service Mesh 中有哪些服务
  • EDS 设置哪些实例（Endpoint）属于这些服务（Cluster）
  • LDS 设置实例上监听的端口以配置路由
  • RDS 最终服务间的路由关系，应该保证最后更新 RDS
• 所有的发现服务（Discovery Service）可以连接不同的 Management Server，也就是说管理 xDS 的服务器可以是多个
• Envoy 在原始 xDS 协议的基础上进行了一些列扩充，增加了
  • SDS（秘钥发现服务）
  • ADS（聚合发现服务）
  • HDS（健康发现服务）
  • MS（Metric 服务）
  • RLS（速率限制服务）等
• 为了保证数据一致性，若直接使用 xDS 原始 API 的话，需要保证这样的顺序更新：CDS –> EDS –> LDS –> RDS

      这是遵循电子工程中的先合后断（Make-Before-Break）原则，即在断开原来的连接之前先建立好新的连接

      应用在路由里就是为了防止设置了新的路由规则的时候却无法发现上游集群而导致流量被丢弃的情况，类似于电路里的断路

下面是应该了解的 Envoy 里的基本术语：

• Downstream （下游）：下游主机连接到 Envoy，发送请求并接收响应，即发送请求的主机
• Upstream （上游）：上游主机接收来自 Envoy 的连接和请求，并返回响应，即接受请求的主机
• Listener （监听器）：监听器是命名网地址（例如，端口、unix domain socket 等)
  • 下游客户端可以连接这些监听器。Envoy 暴露一个或者多个监听器给下游主机连接
• Cluster （集群）：集群是指 Envoy 连接的一组逻辑相同的上游主机。Envoy 通过服务发现来发现集群的成员
  • 可以选择通过主动健康检查来确定集群成员的健康状态
  • 通过负载均衡策略决定将请求路由到集群的哪个成员

xDS 协议是由 Envoy 提出的，现在是 Istio 中默认的 sidecar proxy

但只要实现 xDS 协议理论上都是可以作为 Istio 中的 sidecar proxy 的，例如蚂蚁金服开源的 MOSN

Envoy 中可以设置多个 Listener，每个 Listener 中又可以设置 filter chain（过滤器链表），而且过滤器是可扩展的，这样就可以更方便操作流量的行为，例如设置加密、私有 RPC 等

Istio 中定义了如下的 CRD 来帮助用户进行流量管理：

• Gateway：Gateway 描述了在网络边缘运行的负载均衡器，用于接收传入或传出的HTTP/TCP连接
• VirtualService：VirtualService 实际上将 Kubernetes 服务连接到 Istio Gateway。它还可以执行更多操作，例如定义一组流量路由规则，以便在主机被寻址时应用
• DestinationRule：DestinationRule 所定义的策略，决定了经过路由处理之后的流量的访问策略。简单的说就是定义流量如何路由。这些策略中可以定义负载均衡配置、连接池尺寸以及外部检测（用于在负载均衡池中对不健康主机进行识别和驱逐）配置
• EnvoyFilter：EnvoyFilter 对象描述了针对代理服务的过滤器，这些过滤器可以定制由 Istio Pilot 生成的代理配置。这个配置初级用户一般很少用到
• ServiceEntry：默认情况下 Istio Service Mesh 中的服务是无法发现 Mesh 外的服务的，ServiceEntry 能够在 Istio 内部的服务注册表中加入额外的条目，从而让网格中自动发现的服务能够访问和路由到这些手工加入的服务