服务网格概念

服务网格

是指专注于服务间通信的基础设施，它负责现代云原生应用组成的复杂拓扑中的可靠传递请求

服务网格基本功能：

● 控制服务间通信：熔断、重试、超时、故障注入、负载均衡和故障转移等

● 服务发现：通过专用的服务总线发现服务端点
● 可观测：指标数据采集、监控、分布式日志记录和分布式追踪
● 安全性：TLS/SSL通信和密钥管理
● 身份认证和授权检查：身份认证，以及基于黑白名单或RBAC的访问控制功能
● 部署：对容器技术的原生支持，例如Docker和k8s
● 服务间的通信协议：HTTP1.1、HTTP2.0、gRPC
● 健康状态检测：检测上游服务的健康状态

控制平面与数据平面：

● 数据平面：触及系统中的每个数据包或请求，负责服务发现、健康状态、路由、负载均衡、身份验证/授权和可观测性等
● 控制平面：为网格中的所有正在运行的数据平面提供策略和配置，从而将所有数据平面联合构建为分布式系统，他不接触系统中的任何数据包或请求。例如确定两个服务Service X到Service Y之间路由，Service Y相关集群的负载均衡机制、断路策略、流量转移机制等，并将决策下发给Service X和Service Y的Sidecar

控制平面组件：

● 工作负载调度程序：借助与底层的基础设施（例如kubernetes）完成服务及其Sidecar运行位置的调度策略
● 服务发现：服务网格中的服务发现
● Sidecar代理配置API：各Sidecar代理以最终一致的方式从各种系统组件获取配置
● 控制平面UI：管理人员的操作接口，用于配置全局级别的设置，例如部署、身份认证和授权、路由及负载均衡等

Service Mesh解决方案极大降低了业务逻辑与网络功能之间的耦合度，能够快捷、方便地集成到现有的业务环境中，并提供了多语言、多协议支持，运维和管理成本被大大压缩，且开发人员能够将精力集中于业务逻辑本身，而无须再灌注业务代码以外的其它功能

一旦启用Service Mesh，服务间的通信将遵循一下通信逻辑：
● 微服务彼此间不会直接进行通信，而是由各服务前端的称为Service Mesh的代理程序进行；
● Service Mesh内置支持服务发现、熔断、负载均衡等网络相关的用于控制服务间通信的各种高级功能
● Service Mesh与编程语言无关，开发人员可以使用任何编程语言编写微服务的业务逻辑，各服务之间也可以使用不同的编程语言开发
● 服务间的通信的局部故障可由Service Mesh自动处理
● Service Mesh中的各服务的代理程序由控制平面（Control Plane）集中管理；各代理程序之间的通信网络也称为数据平面（Data Plane）
● 部署于容器编排平台时，各代理程序会以微服务容器的Sidecar模式运行

Service Mesh技术标准：

● UDPA（Universal Data Plane API）：通用数据平面API（例如Envoy）
● SMI（Service Mesh Interface）：控制平面API

Service Mesh代表产品：

● 数据平面的主流解决方案有Linkerd、Nginx、Envoy、HAProxy和Traefik等
● 控制平面实现主要有Istio、Nelson和SmartStack等

服务网格的部署模式：

主机共享代理：

● 适用于同一主机上存在许多容器的场景，并且还可利用连接池来提高吞吐量
● 但一个代理进程故障将终止其所在主机上的所有容器队列，受影响不仅仅是单个服务
● 实现方式中，常见的运行为k8s之上的DaemonSet

sidecar容器：

● 代理进程注入每个pod，与主容器一同运行
● Sidecar进程应该尽可能轻量且功能完善
● 实现方案：Linkerd、Envoy和Conduit