服务网格：棋到中盘方见势

最新推荐文章于 2024-05-19 23:25:18 发布

米开朗基杨

最新推荐文章于 2024-05-19 23:25:18 发布

阅读量175

点赞数

文章标签：内核网络运维大数据 java

原文链接：https://mp.weixin.qq.com/s?__biz=MzU1MzY4NzQ1OA==&mid=2247502074&idx=1&sn=32b9a2000345839cfe2ba86a5f9c9134&chksm=fbed8837cc9a012155cbad1da07739b77f5ab5284ff08aa331a3bf5112b408978a576a0c1c62&scene=126&&sessionid=0

版权

一、服务网格：微服务框架 2.0 时代

如果我们使用“微服务框架“作为关键字进行搜索时，它会关联到”服务治理”、“微服务框架 Spring Cloud“、”Dubbo“、”服务网格“等概念。虽然，它们都与微服务框架相关，但它们各有侧重，存在较大差异。让我们一一说来。

服务治理是 2006 年 IBM 提出，又称 SOA 治理。服务治理是指企业按照最佳实践、架构原则、政府法规、法律和其他决定因素，管理 SOA 的采用和执行的过程。限于当时的技术发展水平，大家对于 SOA 和服务治理的技术认知还主要停留在 Web Service 和 ESB 总线等技术和规范上，并没有真正在软件开发中得以充分落地。直到 2011 年 10 月，阿里巴巴开源了自己的 SOA 服务治理方案的核心框架 Dubbo，服务治理和 SOA 的设计理念开始逐渐在国内软件行业中落地，并被广泛应用。随后，2012 年 3 月微服务一词最早被提出，同时，Netflix 发布了 Netflix OSS；2013 年 9 月 Spring Boot 发布；2016 年 Spring cloud 发布。通常把 Spring Cloud 和 Dubbo 称为微服务框架 1.0 时代。随后，2016 年 9 月 29 日 Linkerd 公司提出了 Service Mesh 概念，被翻译成“服务网格”。服务网格是微服务框架发展的重要方向。通常服务网格称为微服务框架 2.0 时代。

下面是常见的微服务框架服务网格、Dubbo 和 Spring Cloud 的比较。服务网格关注于服务间通信，Dubbo 是提供了 RPC 通信及 SOA 服务治理能力，Spring Cloud 是一整套微服务开发框架的工具集，其中包括 SOA 服务治理能力。

**服务网格是一个用于处理服务间通信的基础设施层。**云原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传递。在实践中，服务网格通常实现为一组轻量级网络代理，他们与应用程序部署在一起，而对应用程序透明。目前最流行的服务网格开源实现是 Istio。Istio 提供了一个完整的解决方案，以统一的方式去管理和监测微服务应用。同时，它还具有管理流量、实施访问策略、收集数据等方面的能力，这些能力对应用透明，几乎不需要修改业务代码就能实现。服务网格解决了两个重要的问题：一是将共性的技术治理部分剥离出来，彻底解耦应用与框架；二是解决了异构开发语言问题，不同开发语言开发的应用，统一被通信代理模块接管。

服务网格为应用层提供流量管理、安全和可观测性能力。下面是服务网格的主要功能特征：

服务网格技术一出现，由于服务网格的特征，服务网格的必要性就引起大家的关注：

服务网格将业务逻辑与架构支撑能力解耦，业务开发只关注于业务逻辑的开发。
服务网格作为基础设施层，平台化具有通用性，可以降低成本，统一技术栈，沉淀技术资产。
主流的服务网格开源项目 Istio 具有开放性和标准化性，企业可以快速获得社区技术红利。

随着服务网格在社区不断被提及，很多互联网大厂开始试水，并初步完成了应用落地。随后，各行业的企业也进行探索并逐渐开始尝试。随着服务网格技术的逐步稳定，2021 年 7 月，中国信息通信研究院主办的 2021 年可信云大会上，正式发布了《服务网格技术能力要求》标准。到 2022 年，服务网格技术已发展了 5 年，2022 年，当我们谈起服务网格，我们到底在讨论什么？服务网格技术演进、服务网格的实践落地又是怎样的？

二、技术演进：向下不断下沉，向上不断抽象

2021 年，Istio 社区如期每三个月推出一个版本：1.9，1.10，1.11，1.12。稳定的版本发布周期显示出 Istio 社区发展进入常态化，也为企业选择合适的版本提供了便利。总的来说，2021 年 Istio 社区没有发布特别重大的架构调整或者创新能力，更多在接入性、运维性、API 等方面提供更好的原生支持，这表明Istio 版本已趋于稳定。

**对于云原生终态而言，服务网格技术是一个基础设施技术，一定要不断下沉，不断向上抽象。**下沉到更高效的内核或者基础网络上实现，向上抽象到配置管理成本更低。随着服务网格社区的发展，2021 年陆续出现了内核级的服务网格，以及无 Sidecar 代理的服务网格。两种模式的服务网格可以缓解服务网格技术带来的两个主要挑战：复杂性和性能。对于复杂性，服务网格比较难安装部署和管理，需要专业技能；同时，服务网格引入了延迟，所以它也会产生性能问题。

2.1 内核级的服务网格

2021 年底 Cilium 1.11 发布，其中包括了 Cilium Service Mesh 的 Beta 版本。Cilium 通过 Linux 内核的新技术 eBPF，可以在 Linux 内核上动态地注入强大的安全性、可见性以及网络控制逻辑，实现多集群路由、kube-proxy 替代负载均衡、透明加密以及网络和服务安全等诸多功能。同时，基于 eBPF 的内核级服务网格从性能角度可以获得最大收益，使用 eBPF 的服务网格相比我们常规的 Istio/Linkerd 等方案，最显着的特点就是将 Sidecar proxy 模型替换成了 Kernel 模型。

下图是边车模式与内核模式的服务网格比较：

2.2 无 Sidecar 代理的服务网格

2021 年发布了 Istio 1.11，Istio 1.11 增加了对 gRPC 支持 xDS 协议的实验性支持。用户可以直接将 gRPC 服务添加到网格中，直接跟 Istio 控制平面通信，为服务提供基本的服务发现、双向 TLS、以及一些基于 VirtualService 的流量策略、故障、重试、超时、镜像和重写规则的管理。无 Sidecar 代理的服务网格可以减少因 Sidecar 代理注入而带来的额外的资源开销和延时的性能开销。

下图是基于 gRPC 协议实现的无 Sidecar 代理服务网格：

三、架构平滑演进：融合（过渡）期的双模式微服务平台

3.1 服务网格落地艰难

建设服务网格是必要的，但面对业务情景的复杂，服务网络的实际企业落地过程却是艰难的。方知理想很美好，现实却很残酷。服务网格落地困难有如下的原因：

服务网格增加了运维部署的复杂性，同时带来额外的资源开销和延时的性能开销。
Sidecar 管理和规模问题，随着接入的节点越多，规模越大，控制平面下发配置的速度越慢，甚至无法工作。
服务网格技术设计上比较理想化，与真实的用户使用场景存在差异，很难直接拿给业务直接使用，如：业务场景需要使用多种通讯协议，如：Dubbo、Thrift；需要支持多种场景的限流、路由能力；Sidecar 版本升级业务容器需要重启，以及需要 K8s 运维经验等问题。
微服务框架和服务网格两者在服务治理方面存在重合区域，但又无法完全替代。

3.2 架构演进的关键要素

下面是服务网格架构平滑演进的一些关键要素：

服务网格数据平面延迟的性能优化。
规模问题的性能优化。
对于存量业务，提供业务不中断的平滑迁移方案。
整合成熟的 API 网关方案。
提供多种业务场景的限流和路由方案。
除了支持主流的 HTTP/gRPC 通信协议，支持多种通信协议，如：Dubbo、Thrift 等。
服务注册方案，是使用 Kubernetes 内置的 Service 作为服务发现机制？对于存量使用了 Eureka、Zookeeper、Nacos 的注册中心的微服务架构，如何平滑迁移？
sidecar 管理、版本升级及运维方案。如：在不重启 pod 下，sidecar 的热升级。

3.3 SDK 和 Sidecar 代理并存模式的过渡期

“服务框架在微服务架构中占据核心位置，因此，使用 Service Mesh 来替换正在使用的微服务框架，无异于一次‘换心手术’。”

“保守派”的做法是在融合（过渡）期使用双模式落地。

在微服务框架 1.0 时代，服务治理的逻辑是通过使用 SDK 代码侵入的方式实现的，SDK 负责应用内的服务治理。
在融合（过渡）期，是 SDK 和 Mesh 并存阶段。SDK 负责 RPC 调用和应用内的服务治理。Mesh 主要处理流量控制逻辑，负责应用间粗粒度服务治理。融合（过渡）期是架构平滑演变的一种解决方案，也是从传统微服务框架到服务网格架构变革的最后一公里。
第三阶段是 Mesh 阶段，即架构变革完成，SDK 只负责 RPC 调用部分，新的业务直接不使用 SDK。

下面是采用双模式微服务平台架构。对于数据平面，微服务框架的 SDK 和 Sidecar envoy 并存，微服务框架的 SDK 裁剪成 ThinSDK，服务治理能力下沉，逐步将这个能力沉淀到新架构上。对于控制平面，服务注册中心与服务网格的控制平面打通，以实现全局服务的可见和路由。

四、服务网格的未来：深度整合多运行时

最后，让我们看看服务网格的未来。2020 年初，Bilgin Ibryam （Author of Kubernetes Patterns | Product Manager at Red Hat）提出了微服务架构的一个新的设想：Multiple Runtime（多运行时），并总结了分布式应用存在的四大类需求：生命周期、网络、状态、绑定。很可能在将来，我们最终将使用多个运行时来实现分布式系统。比较典型的多运行时开源框架是由微软开源的 Dapr（ Distributed Application Runtime），在 2021 年迎来了标志性的 1.0 版本，并且进入 CNCF Sandbox 进行孵化，目前仍在高速发展中。

服务网格的本质是服务间通讯的抽象层，多运行时的本质是应用需要的各种分布式能力和原语，包括但不限于服务间通讯。从这个角度上说，多运行时覆盖的范围是服务网格的超集：毕竟服务网格只覆盖到应用的部分需求（即服务间通讯），还有更多的分布式能力和原语有待覆盖。随着云原生的推进，分布式能力（以传统中间件为典型代表）下沉是大势所趋，Mesh 化的范围必然会继续扩大，服务网格会与多运行时深度整合。