ServiceMesh技术简要概述

2021/01/10 共 2414 字 6 分钟阅读
SOFTWARE-ENGINEERING service mesh

Table of Content

AI 摘要: 本文介绍了服务网格（Service Mesh）的概念和关键技术，服务网格用于管理分布式服务架构中的服务到服务间流量的管控，通常采用边车模式与服务部署在一起。文章还介绍了服务网格的背景、关键要点、目标、特性和架构，并解释了数据面和控制面的区别。此外，还提供了一些常见的技术术语和其他相关知识。

服务网格（Service Mesh）用于管理分布式服务架构中，服务到服务间流量的管控，通常采用边车模式（Sidecar）与服务部署在一起，旨在解耦业务服务与服务基础设施的依赖。
服务网格增加了技术的复杂度、资源以及性能的开销，通常在组织无法扩展到服务的通信或解决特定用例情况下才进行部署，文章内容对Service Mesh的一些关键性技术做概述。

1. 服务网格背景

随着微服务、云计算、DevOps领域不断发展，开发人员在构建分布式系统时候使用多语言、动态服务发现、服务监控、服务容错等服务治理的基础设施，整个服务的基础设施组件自研和掌握成本较高。

2016年左右出现了服务网格技术，希望妥善处理服务与服务间通信流量管理，实现服务之间通信安全与质量保证，同时提供服务的跟踪、度量与观测。在容器化技术成熟后，业务服务实例和网格sidecar代理共享一个容器，并且这些容器由容器编排工具（如Kubernetes，Nomad，Docker Swarm或DC/OS）进行管理。

服务代理负责与其他服务实例的通信，并且可以支持诸如服务（实例）发现，负载平衡，身份验证和授权，安全通信等功能。

在服务网格中，服务实例及服务代理组成数据平面，它不仅包括数据管理，还包括请求处理和响应；服务网格还包括一个控制平面，用于管理服务之间的交互，这些交互是由它们的边车代理接管。

服务网格体系结构有多种选择：开放服务网格，Istio（Google，IBM和Lyft之间的联合项目），Linkerd（由Buoyant领导的CNCF项目），Consul（HashiCorp产品）以及许多其他服务。服务网格景观。服务网格管理平面Meshery可跨服务网格部署提供生命周期，配置和性能管理。

2. 服务网格关键要点

网络流量代理：管理所有分布式服务之间的通信，典型方式通过sidecar方式透明的为每个服务做网络流量代理，支持动态服务发现和流量管控（包括镜像流量测试、AB测试、金丝雀灰度等），代理通常是在OSI的7层(应用层)，意味着流量路由和度量指标可以基于应用协议的元数据实现
服务质量和安全：网格支持安全（服务认证、TLS）和可靠性（限流、熔断）
服务跟踪观测：支持可观测性（分布式跟踪、HTTP错误码、服务到服务间服务响应延时）
网格成本：通过Sidecar代理，带来复杂度、资源以及性能开销
网格发展：ServiceMesh成为云原生应用的一部分，同时带来更高层次的抽象和控制平面的聚焦，流行的ServiceMesh包括Linkerd、Istio、Consul、Kuma、Maesh，支持技术包括7层代理(Envoy、HAProxy、Nginx、MOSN)、网格编排、虚拟化、易懂工具（SuperGloo、Kiali、Dive）

3. 服务网格目标

网络代理，处理服务发现、路由、应用层（7层）无需求功能交互
服务安全，包括外部服务网络配置、服务安全、服务质量等
提供服务被动和主动监控
分布式系统实时的策略
请求日志、分布式跟踪、指标度量，提供可视化观测

4. 服务网格特性

名字和路由
流量分形和流量转移
服务预发控制：金丝雀、流量分形
预请求路由：流量分形、失败注入（Chaos Engine）、路由调试
基线可靠性：监控检查、超时、熔断、重试
负载均衡：支持可配置的算法
安全增强，传输层的TLS和ACLs访问控制策略
可视化和监控，顶级度量（请求量、成功率、时延），支持分布式跟踪以及近实时的服务与服务通信
合理默认配置，保护系统免受不良通信影响

5. 服务网格架构

服务网格(Service Mesh)是一个用于管理、观测、支持工作负载实例之间安全通信的管理层，由控制平面和数据平面两部分组成
边车模式(Sidecar)作为一个独立的容器和业务系统运行在同一个Kubernetes的Pod里面，或者作为一个独立的进程和应用程序进程运行在同一个虚拟机上，充当业务系统的网络流量的代理

数据面（实施工作）：技术主要包含流量路由、转发、可视化进出网络流量，触控每一个包/请求，通常由代理实现，诸如Envoy,HaProxy,MOSN，通常以Sidecar模式运行，功能包含服务发现，健康检查，路由，负载均衡，认证与鉴权，可视化等。Universal Data Plane API（通用数据面API），建议扩展xDS API（由Envoy定义）MSON实现
控制面（监督工作）：获取所有无状态的Sidecar代理的数据，转入分布式系统；控制面不接触任何包和请求，但允许操作员人员为所有允许在网格中提供策略和配置管理数据面板，控制面允许数据面遥测收集和中心化数据，用于服务通信、质量等数据可视化展示

Istio架构:

服务通信架构的演进

ServiceMesh 的架构图来源: Pattern: Service Mesh

数据面和控制面的思考

控制平面本质上是个存储系统，所以其演进基本就是在一致性和可用性上做平衡，数据平面主要是在高效率和低侵入性方面做平衡。

Sidecar虽然是数据平面的典型方案，但并不是唯一方案，RPC框架也可以做数据平面，且效率会更高，但相对的侵入性也更高。

6. 技术术语

API gateway：管理南北流量入口，作为整个系统接入点
Consul: HashiCorp开发的基于Go的服务网格
Control plane: 获取所有数据平面实例，转入分布式系统，且被可视化控制和操作
Data plane: 基于条件转发进出服务节点的流量
East-West流量：数据中心网络或K8s集群的流量
Envoy Proxy：开源的服务的流量代理，设计用于云原生应用
Ingress traffic: 入口流量，来自数据中心，网络或Kubernets集群的网络流量
Istio：服务网格的一种，由Google、IBM创建Go（控制平面），以及Lyft提供的EnvoyC++（数据平面）共同组成
Kubernetes：由Google进行的容器编排、调度框架
Kuma: 服务网格的一种，来自Kong实现的Go服务网格
Linkerd：服务网格的一种，由Twitter创建，技术基于Rust(数据平面)、Go(控制平面)实现，基于早期JVM通信框架
Meash: 服务网格的一种，基于Go实现
MOSN：蚂蚁金融团队实现的基于xDS(Envoy) APIs接口实现
North-South流量：进入数据中心、网络或Kubernetes集群
Proxy: 服务的节点上的代理软件
Segmentation：切割，网络或集群切分为多个子网
Service Mesh: 管理在分布式微服务系统中的东-西流量系统，也提供功能操作诸如路由，也提供非功能操作诸如安全策略、服务质量、流量限制
Service Mesh Interface(SMI): 服务网格部署在K8s上的标准接口
Service Mesh policy: 网格与其他网络节点通信策略
Sidecar: 一种部署模式，独立的进程、服务或容器与存在的业务服务附加在一起，如同摩托车的边车一样
Single pane of glass: UI或者管理控制台，可在统一显示中显示来至多个来源的数据
Traffic shapping: 流量分形，通过限流、负载调度修改访问网络的流量
Traffic shifting: 流量转移，将流量从一个转移至另一个

7. 其他的普及

Envoy不是服务网格，只是一个云原生代理，由Lyft团队设计和构建，Envyoy通常用于数据平面，需要与控制平台结合使用
Istio只是服务网格的一种
ServiceMesh产品选择，这里还没有确定的答案，基于团队与网格的实际情况（资源、技术、时间）匹配
ServiceMesh不一定需要Kubernets，只是与后者可以更细粒度的管控资源
哪个团队运维网格? 通常是由平台或者运维团队负责服务网格，通常和Kubernetes和CI/CD设施团队一起，单开发团队应该参与网格属性的配置