服务|围观KubeCon 2020丨火了 2 年的服务网格究竟给微服务带来了什么?( 二 )


而 Service Mesh 技术也因此越来越火热 , 受到越来越多开发者的关注 , 并拥有了大批拥趸 。 那么 Service Mesh 是什么呢?它为什么会受到开发者的关注?它和传统微服务应用有什么区别?
Service Mesh 定义
Service Mesh 一词最早由开发 Linkerd 的 Buoyant 公司提出 , 并于 2016 年 9 月29 日第一次公开使用了这一术语 。 William Morgan , Buoyant CEO , 对 Service Mesh 这一概念定义如下:
A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application.
In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.
翻译成中文如下:
Service Mesh 是一个专门处理服务通讯的基础设施层 。 它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送 。 在实践中 , 它是一组和应用服务部署在一起的轻量级的网络代理 , 并且对应用服务透明 。
以上这段话有四个关键点:
本质:基础设施层;
功能:请求分发;
部署形式:网络代理;
特点:透明;
2017 年 , 随着 Linkerd 的传入 , Service Mesh 进入国内社区的视野 , 并且由国内的技术布道师们翻译成“服务网格” 。
服务网格概述
服务网格从总体架构上来讲比较简单 , 不过是一堆紧挨着各项服务的用户代理 , 外加一组任务管理流程组成 。 代理在服务网格中被称为数据层或数据平面(data plane) , 管理流程被称为控制层或控制平面(control plane) 。 数据层截获不同服务之间的调用并对其进行“处理”;控制层协调代理的行为 , 并为运维人员提供 API , 用来操控和测量整个网络 。
服务|围观KubeCon 2020丨火了 2 年的服务网格究竟给微服务带来了什么?
图片

更进一步地说 , 服务网格是一个专用的基础设施层 , 旨在“在微服务架构中实现可靠、快速和安全的服务间调用” 。 它不是一个“服务”的网格 , 而是一个“代理”的网格 , 服务可以插入这个代理 , 从而使网络抽象化 。 在典型的服务网格中 , 这些代理作为一个 sidecar(边车)被注入到每个服务部署中 。 服务不直接通过网络调用服务 , 而是调用它们本地的 sidecar 代理 , 而 sidecar 代理又代表服务管理请求 , 从而封装了服务间通信的复杂性 。 相互连接的 sidecar 代理集实现了所谓的数据平面 , 这与用于配置代理和收集指标的服务网格组件(控制平面)形成对比 。
总而言之 , Service Mesh 的基础设施层主要分为两部分:控制平面与数据平面 。 当前流行的两款开源服务网格 Istio 和 Linkerd 实际上都是这种构造 。
控制平面的特点:
不直接解析数据包;
与控制平面中的代理通信 , 下发策略和配置;
负责网络行为的可视化;
通常提供 API 或者命令行工具可用于配置版本化管理 , 便于持续集成和部署;
数据平面的特点:
通常是按照无状态目标设计的 , 但实际上为了提高流量转发性能 , 需要缓存一些数据 , 因此无状态也是有争议的;
直接处理入站和出站数据包 , 转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等;
对应用来说透明 , 即可以做到无感知部署;
服务网格带来的变革
那么服务网格的出现带来了哪些变革呢?
第一 , 微服务治理与业务逻辑的解耦 。 服务网格把 SDK 中的大部分能力从应用中剥离出来 , 拆解为独立进程 , 以 sidecar 的模式进行部署 。 服务网格通过将服务通信及相关管控功能从业务程序中分离并下沉到基础设施层 , 使其和业务系统完全解耦 , 使开发人员更加专注于业务本身 。


推荐阅读