基于Istio的高级流量管理一（为什么需要服务网格？深入理解Envoy）

文章目录

一、微服务架构的演变
二、Istio服务网格简介
- 1、服务网格架构
- 1、ServiceMesh提供哪些能力？
- 2、Istio服务网格
- 3、Istio架构演进
三、深入理解数据平面Envoy
- 1、主流七层代理比较
- 2、Envoy简介
- 3、Envoy的发现机制
- 4、Envoy 过滤器架构

一、微服务架构的演变

早期互联网架构，都是采用单体架构，随着服务需要支撑越来越多的并发流量，以及业务更加复杂，代码也越来越复杂，单体架构的代码可维护性，及业务的横向扩展变得越来越难。因此慢慢就出现了微服务架构，其中核心理念就是高内聚，低耦合，每个微服务功能应该尽可能单一，微服务之间应该尽可能的独立。

微服务架构图：

各个服务之间通过服务注册中心相互调用，client通过api网关统一访问所有微服务，每个微服务可以按照自己的服务级别，定义副本数，进行灵活扩容.

由于拆成了一个个的微服务，因此如果一个上游服务的一直卡着，要死不活的，可能造成下游依赖它的服务也出现问题，因此就需要服务自身有熔断（降级、Fallback）的能力。因此微服务架构图就变成了下面这样：

CB（Circuit Breaker，熔断）
LB（Load Balance，负载均衡）
SD（Service Discovery，服务发现）
AU（Atomic Unit，原子单元，指微服务架构中最小的可独立部署、扩展和管理的单元），这些所有原子单元都需要一些共性的需求，比如认证鉴权、流量统计等。

原来，熔断、认证鉴权、服务发现这些都需要业务去控制，比如springcloud，但是业务应该只需要关注自己的业务，所以我们希望将这些全部都移到平台侧做统一管理：

因此服务网格就是为了解决这个需求的，用一句话概括：Service Mesh就是一个提供统一的熔断、认证鉴权、TLS、服务发现的微服务治理框架

二、Istio服务网格简介

1、服务网格架构

怎么提供这些熔断的这些能力呢？容器中的sidecar就是最佳答案，因为它天生就和业务pod在一起。

上面是服务A，下面是服务B，那么服务之间的调用，就不会是直接访问了，不论是流入还是流出都需要经过这个sidecar proxy容器，流量都要经过sidecar，那么它就可以做很多流量管理的事情了，也就能实现熔断、负载均衡、鉴权，服务发现是基于k8s的service去做的。

上面的图也可以抽象成下面这个图：

1、ServiceMesh提供哪些能力？

适应性：熔断、重试、超时处理、失败处理、负载均衡、FailOver
服务发现：路由
安全与访问控制：TLS和证书管理
可观察性：指标、分布式追踪、访问日志
部署：容器
通讯：http、ws、grpc、tcp

带来了这么多的功能，那么服务网格有什么优劣呢？

2、Istio服务网格

什么是服务网格？

Istio服务网格的大致能力：

（1）流量管理

连接：通过简单的规则配置和流量路由，可以控制服务之间的流量和 API调用。Istio 简化了断路器、超时和重试等服务级别属性的配置，并且可以轻松设置 A/B 测试、金丝雀部署和基于百分比的流量分割的分阶段部署等重要任务。
控制：通过更好地了解流量和开箱即用的故障恢复功能，可以在问题出现之前先发现问题，使调用更可靠，并且使您的网络更加强大——无论您面临什么条件。

（2）安全：使开发人员可以专注于应用程序级别的安全性。Istio 提供底层安全通信信道，并大规模管理服务通信的认证、授权和加密。使用Istio，服务通信在默认情况下是安全的，它允许跨多种协议和运行时一致地实施策略——所有这些都很少或根本不需要应用程序更改。虽然 Istio 与平台无关，但将其与 Kubernetes（或基础架构）网络策略结合使用，其优势会更大，包括在网络和应用层保护 Pod 间或服务间通信的能力。
（3）可观察性
istio生成以下类型的遥测数据，以提供对整个服务网格的可观察性：

指标：Istio 基于4 个监控的黄金标识（延迟、流量、错误、饱和）生成了一系列服务指标。Istio还为网格控制平面提供了更详细的指标。除此以外还提供了一组默认的基于这些指标的网格监控仪表板。
分布式追踪：Istio 为每个服务生成分布式追踪 span，运维人员可以理解网格内服务的依赖和调用流程。
访问日志：当流量流入网格中的服务时，Istio可以生成每个请求的完整记录，包括源和目标的元数据。此信息使运维人员能够将服务行为的审查控制到单个工作负载实例的级别。

所有这些功能可以更有效的设置、监控和实施服务上的SLO，快速有效的检测和修复问题。

3、Istio架构演进

下图左面是istio最初的架构图，右边是改进之后的架构图：

我们可以发现，最开始的时候istio控制面的架构，是拆成一个个的组件，但是维护很麻烦，因此后面合成了一个单体。并且取消了mixer组件。pilot基本上就是istio控制面的灵魂人物了，什么route配置下发proxy等主要功能都由它完成。

三、深入理解数据平面Envoy

1、主流七层代理比较

可以看下connection draining，算是Envoy比较特色的一个能力。

2、Envoy简介

我们先说下Envoy有什么优势：

性能：在具备大量特性的同时，Envoy 提供极高的吞吐量和低尾部延迟差异，而 CPU 和 RAM 消耗却相对较少。
可扩展性：Envoy在L4 和L7都提供了丰富的可插拔过滤器能力，使用户可以轻松添加开源版本中没有的功能。
API可配置性：Envoy 提供了一组可以通过控制平面服务实现的管理 API。如果控制平面实现所有的API，则可以使用通用引导配置在整个基础架构上运行 Envoy。所有进一步的配置更改通过管理服务器以无缝方式动态传送，因此 Envoy从不需要重新启动。这使得 Envoy 成为通用数据平面，当它与一个足够复杂的控制平面相结合时，会极大的降低整体运维的复杂性。

Envoy的线程模型：

Envoy采用单进程多线程模式。主线程负责协调、子线程（worker线程）负责监听过滤和转发
当连接被监听器所接受，那么该连接的全部生命周期都与某线程绑定，应该是提高缓存命中率吧
Envoy基于IO多路复用的epoll模型
建议worker线程和envoy所在的硬件线程数一致。

Envoy架构图：

3、Envoy的发现机制

Endpoint Discovery Service

The Endpoint Discovery Service (EDS) API provides a more advanced
mechanism by which Envoy can discover members of an upstream cluster.
Layered on top of a static configuration, EDS allows an Envoy
deployment to circumvent the limitations of DNS (maximum records in a
response, etc.) as well as consume more information used in load
balancing and routing (e.g., canary status, zone, etc.).

Cluster Discovery Service

The Cluster Discovery Service (CDS) API layers on a mechanism by which Envoy can discover upstream clusters used during routing. Envoy will gracefully add, update, and remove clusters as specified by the API. This API allows implementors to build a topology in which Envoy does not need to be aware of all upstream clusters at initial configuration time. Typically, when doing HTTP routing along with CDS (but without route discovery service), implementors will make use of the router’s ability to forward requests to a cluster specified in an HTTP request header.

Although it is possible to use CDS without EDS by specifying fully static clusters, we recommend still using the EDS API for clusters specified via CDS. Internally, when a cluster definition is updated, the operation is graceful. However, all existing connection pools will be drained and reconnected. EDS does not suffer from this limitation. When hosts are added and removed via EDS, the existing hosts in the cluster are unaffected.

Route Discovery Service

The Route Discovery Service (RDS) API layers on a mechanism by which Envoy can discover the entire route configuration for an HTTP connection manager filter at runtime. The route configuration will be gracefully swapped in without affecting existing requests. This API, when used alongside EDS and CDS, allows implementors to build a complex routing topology (traffic shifting, blue/green deployment, etc).

Listener Discovery Service

The Listener Discovery Service (LDS) API layers on a mechanism by which Envoy can discover entire listeners at runtime. This includes all filter stacks, up to and including HTTP filters with embedded references to RDS. Adding LDS into the mix allows almost every aspect of Envoy to be dynamically configured. Hot restart should only be required for very rare configuration changes (admin, tracing driver, etc.), certificate rotation, or binary updates.

Secret Discovery Service

The Secret Discovery Service (SDS) API layers on a mechanism by which Envoy can discover cryptographic secrets (certificate plus private key, TLS session ticket keys) for its listeners, as well as configuration of peer certificate validation logic (trusted root certs, revocations, etc).

Aggregated Discovery Service

EDS, CDS, etc. are each separate services, with different REST/gRPC service names, e.g. StreamListeners, StreamSecrets. For users looking to enforce the order in which resources of different types reach Envoy, there is aggregated xDS, a single gRPC service that carries all resource types in a single gRPC stream. (ADS is only supported by gRPC). More details about ADS.

4、Envoy 过滤器架构

推荐博客：envoy 代码阅读记录 - - 过滤器

Listener Filter：主要作用是检测协议、解析协议，通过它们解析出的信息被用于匹配 filter_chains 中的那个 NetworkFilter处理。比如：

envoy.listener.http_inspector：判断应用层的数据是否使用 HTTP 协议，如果是，续继判断 HTTP 协议的版本号（HTTP 1.0、HTTP 1.1、HTTP 2）。
envoy.listener.tls_inspector：用来判断是否使用 TLS 协议，如果是 TLS 协议，解析出 Server Name、Negotiation 信息，解析出来的信息用于 FilterChain 的匹配。

Network Filter：每个监听器都有多个过滤器链（比如mysql、mongo等）和一个可选默认过滤器链（比如设置http为默认链）。如果找不到最佳匹配的过滤链，将选择默认的过滤链来处理请求。如果没有提供默认的过滤链，连接将被关闭。

envoy.filters.network.mysql_proxy：能够解析 mysql 的通信协议，需要和TCP proxy一起使用。
envoy.http_connection_manager：专门处理 http 协议的 network filter，内部又实现了 Http Filter。因为 http 最经常使用的协议，对代理功能需求也非常多样， HTTP connection manager 本身是一个比较复杂的 network filter，在 envoy 文档中被单独列出：HTTP connection 。 proto message 字段参考连接管理器.proto 。

Http Filter：在连接管理器中支持HTTP级别的过滤器栈。

envoy.filters.http.router ：路由器过滤器，执行高级路由任务。参考 HTTP
转发是用路由过滤器实现的。该过滤器的主要职能就是执行路由表中的指令。在重定向和转发这两个主要任务之外，路由过滤器还需要处理重试、统计之类的任务。