架构15-服务网格

零、文章目录

架构15-服务网格

1、透明通信的涅槃

（1）服务网格

• 概念
  • 服务网格是一种处理程序间通信的基础设施，主要由数据平面和控制平面组成。
  • 它通过边车代理和控制程序管理程序间的通信，弥补了容器编排系统对分布式应用细粒度管控能力的不足。
• 背景与意义
  • Kubernetes 提供了工业级的韧性和弹性，并维护了各 Pod 之间的虚拟化网络。
  • 程序间的通信 不仅需要网络的连通性，还需要解决路由、容错、限流、加密、认证、授权、跟踪、度量等问题。
  • 服务网格 旨在通过容器、虚拟化网络、边车代理等技术，重新挑战程序间远程通信中的非透明原则。
• 技术特点
  • **数据平面：**负责转发程序间通信的数据包。
  • **控制平面：**负责路由管理、服务发现、数据遥测等控制信息。
  • **边车代理：**与应用容器共同部署，自动劫持流量，实现透明且强制的通信。
  • **解耦：**将“程序”与“网络”解耦，将网络问题和功能处理从程序中分离出来，放到数据平面通信中处理。
• 价值
  • **简化应用交互：**应用之间可以简单地交互，不必过多考虑异常情况。
  • **平稳迁移：**能够在不同程序框架、不同云服务提供商环境之间平稳迁移。
  • **统一访问控制：**根据角色、权限进行统一的访问控制。
  • **遥测信息：**不依赖程序支持即可获得所需的全部遥测信息。
• 未来展望
  • **透明远程服务：**尽管远程通信在性能上与本地访问有显著差距，但在功能上实现透明的远程服务仍是一个值得探讨的问题。
  • **行业讨论：**业界对于实现透明远程服务的可能性尚未达成统一共识，引发了广泛的讨论。

（2）通信成本

• **第一阶段：**通信的非功能性需求由程序员直接编写，与业务逻辑耦合，导致系统复杂且易出错。
• 
• **第二阶段：**通信功能被抽离为公共组件库，由专业开发人员编写和维护，但仍存在语言绑定和学习成本高的问题。
• 
• **第三阶段：**通信组件分离为网络代理，与业务逻辑不在同一进程空间，提高了通信质量，但使用范围有限。
• 
• **第四阶段：**网络代理以边车形式注入应用容器，自动劫持流量，实现透明且强制的通信，但管理代理本身会产生额外的通信需求。
• 
• **第五阶段：**边车代理统一管控，分离数据平面与控制平面，实现安全、可控、可观测的通信。
• 

（3）数据平面

• **核心职责 **
  • **转发数据包：**处理应用的入站（Inbound）和出站（Outbound）数据包。
  • **服务路由：**根据控制平面的策略自动完成服务路由。
  • **健康检查：**定期检查服务的健康状况。
  • **负载均衡：**分散请求，提高服务的可用性和性能。
  • **认证鉴权：**确保通信的安全性。
  • **监控数据：**生成和上报监控数据。
• 关键问题及解决方案
  • 代理注入
    • **基座模式（Chassis）：**通过轻量级的 SDK 接入，对程序不透明，有侵入性。
    • 注入模式（Injector）：
      • **手动注入：**对使用者不透明，对程序透明，通过修改 Pod 的 Manifest 文件实现。
      • **自动注入：**对使用者和程序都透明，通过 Kubernetes 的 Mutating Webhook 控制器实现。
  • 流量劫持
    • **iptables：**通过修改容器的 iptables 规则，拦截所有进出 Pod 的流量。
    • 
    • **eBPF：**在 Socket 层面直接完成数据转发，减少数据在通信链路的路径长度。
    • 
    • **CNI 插件：**通过自定义的 CNI 插件控制虚拟化网络，无需依赖 iptables。
  • 可靠通信
    • **xDS 协议族：**定义了如何发现和访问 Listener、Router、Cluster 等资源的 API。
    • 
    • **Listener：**监听端口，接收来自下游的数据。
    • **Router：**决定数据转发的目标 Cluster。
    • **Cluster：**连接到一组提供相同服务的上游主机。
  • 

（4）控制平面

• 核心职责
  • **数据平面交互：**负责边车注入、策略分发和配置分发。
  • **流量控制：**实现请求路由、流量治理和调试能力。
  • **通信安全：**提供加密、凭证、认证和授权功能。
  • **可观测性：**包括日志收集、链路追踪和指标度量。
• 主要功能
  • 数据平面交互
    • **边车注入：**通过 Mutating Webhook 控制器实现自动注入。
    • **策略分发：**为 Envoy 代理提供符合 xDS 协议的策略。
    • **配置分发：**监听来自多种配置源的数据，处理 API 校验和配置转发。
  • 流量控制
    • **请求路由：**通过 VirtualService 和 DestinationRule 实现灵活的服务版本切分与规则路由。
    • **流量治理：**包括熔断、超时、重试等功能。
    • **调试能力：**提供故障注入和流量镜像功能。
  • 通信安全
    • **生成 CA 证书：**负责生成通信加密所需私钥和 CA 证书。
    • **SDS 服务代理：**通过 SDS 服务代理分发证书，保证私钥证书的安全。
    • **认证：**提供基于节点的服务认证和基于请求的用户认证。
    • **授权：**提供不同级别的访问控制。
  • 可观测性
    • **日志收集：**收集远程服务的访问日志。
    • **链路追踪：**生成分布式追踪数据并上报。
    • **指标度量：**生成监控指标，记录和展示服务状态。

2、服务网格与生态

（1）服务网格的发展背景

• **早期发展：**2016年，Linkerd 和 Envoy 问世，标志着服务网格的诞生。
• **行业认可：**2017年，Google、IBM 和 Lyft 发布 Istio，进一步推动了服务网格的发展。
• **云巨头参与：**2018年后，云计算巨头如 Google、AWS、微软等纷纷推出自己的服务网格产品。
• **市场碎片化：**随着市场的繁荣，出现了多个服务网格产品，导致了市场碎片化问题。

（2）服务网格的主要规范

• 服务网格接口 (SMI)
  • **目标：**提供 Kubernetes 与控制平面交互的标准，实现应用程序在不同服务网格产品之间的无缝移植。
  • 特点：
    • **Kubernetes Native：**完全依赖 Kubernetes 的 CRD 实现。
    • **Provider Agnostic：**不绑定任何特定的控制平面。
  • API 构成：
    • **流量规格 (Traffic Specs)：**定义流量的表示方式。
    • **流量拆分 (Traffic Split)：**定义不同版本服务之间的流量比例。
    • **度量 (Metrics)：**提供通用集成点，用于抓取指标。
    • **流量访问控制 (Traffic Access Control)：**基于 ServiceAccount 进行访问控制。
  • **发展状况：**2020年4月被托管到 CNCF，成为 Sandbox 项目。
  • 
• 通用数据平面 API (UDPA)
  • **目标：**制定控制平面与数据平面交互的标准。
  • 特点：
    • **基于 xDS：**基于 Envoy 的 xDS 协议经验。
    • **传输协议 (UDPA-TP)：**定义数据平面的传输协议。
    • **数据模型 (UDPA-DM)：**定义数据平面的数据模型。
  • **发展状况：**仍处于早期设计阶段，距离完备还有很长的路要走。
  • 

（3）服务网格的主要产品

• 数据平面产品
  • Linkerd
    • **历史：**2016年1月发布，2017年1月加入 CNCF。
    • **特点：**使用 Scala 语言，性能和资源消耗方面逊于 Envoy。
  • Envoy
    • **历史：**2016年9月开源，2017年9月加入 CNCF。
    • **特点：**使用 C++ 语言，市场占有率最高，支持多种控制平面。
  • nginMesh
    • **历史：**2017年9月发布，2020年宣告失败。
    • **特点：**基于 Nginx，使用 C 语言，发展不温不火。
  • Linkerd 2
    • **历史：**2017年12月发布，2018年重新命名为 Linkerd 2。
    • **特点：**使用 Rust 语言，性能与资源消耗不输 Envoy。
  • MOSN
    • **历史：**2018年6月开源，2019年12月加入 CNCF Landscape。
    • **特点：**使用 Golang 语言，适用于阿里巴巴生态。
• 控制平面产品
  • Linkerd 2
    • **特点：**性能提升，但功能上不如 Istio 强大。
  • Istio
    • **特点：**功能最强大，市场占有率第一，支持多种数据平面。
  • Consul Connect
    • **特点：**强调整合集成，支持多种运行平台和数据平面。
  • Open Service Mesh (OSM)
    • **特点：**轻量简单，作为 SMI 规范的参考实现。

（4）服务网格的生态格局

• **市场现状：**服务网格市场尚未决出最终胜利者，但已形成初步的生态格局。
• **主要竞争者：**Linkerd 2、Istio、Consul Connect、OSM 等。
• **云巨头策略：**AWS 选择专有闭源，微软和 Google 选择开源竞争。

（5）服务网格的未来展望

• **挑战：**市场碎片化、产品成熟度不足、兼容性问题。
• **前景：**服务网格可能是未来的发展方向，但需要时间和实践来验证其价值。

原文地址：https://blog.csdn.net/liyou123456789/article/details/144385797

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！