【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

服务网格发展 5 年:复杂性问题悬而未决,社区依然“热闹”非凡

  • 2023-01-16
    北京
  • 本文字数:3044 字

    阅读完需:约 10 分钟

服务网格发展5年:复杂性问题悬而未决,社区依然“热闹”非凡

Service Mesh(服务网格)的概念由 Buoyant CEO William Morgan 首次提出。2017 年 4 月该公司发布了第一个 Service Mesh 产品 Linkerd。当时在同一时间发表的文章《What’s a service mesh?And why do I need one?》也被公认是 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 是一个处理服务通讯的专门的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中,它是一组和应用服务部署在一起的轻量级的网络代理,对应用服务透明。

 

为什么需要 Service Mesh?

 

Service Mesh 诞生的背景主要有两点:首先,微服务架构模式逐渐流行,开发者将多个服务组合在一起来构建应用程序;其次,企业已经使用了云原生平台技术,例如容器(Docker)、编排器(Kubernetes)和网关等。

 

Service Mesh 模式试图解决的问题包括:

 

  • 无需将特定语言的通信库编译到单个服务中来处理服务发现、路由和 application-level (Layer 7) 非功能性通信需求。

  • 外部化服务通信配置,包括外部服务的网络位置、安全凭证和服务质量目标。

  • 为其他服务提供被动和主动监控。

  • 在整个分布式系统中,执行分散策略。

  • 提供可观察性默认值并标准化相关数据的收集,如启用请求日志记录、配置分布式跟踪、收集指标等。

 

Phil Calçado 在Pattern:Service Mesh 一文中讲述了服务通信演变的过程:

 


  • 最初,流量管理和控制能力(比如图例中的熔断、服务发现)是和业务逻辑耦合在一起,即便以引用包的方式被调用,依然解决不了异构系统无法重用的问题。

  • 流控功能和业务耦合相当不美好,于是出现了提供这些功能的公共库和框架。但这些库通常比较复杂,无论是学习使用,与业务系统整合、维护都会带来很大的成本。

  • 为避免花费太多时间开发和维护这些通用库,人们希望流量控制能力可以下沉到网络通讯栈的层面,但几乎无法实现。

  • 于是另一种思路出现,就是将这些功能独立成一个代理,由它先接管业务服务的流量,处理完成后再转发给业务服务本身,这就是 Sidecar 模式。

  • 为统一管理 Sidecar,该模式进一步进化,形成网络拓扑,增加了控制平面,演变成 Service Mesh(最后的网格图中,绿色代表业务服务,蓝色代表 sidecar 服务)。

 

从上图可以看出,Service Mesh 就是 Sidecar 的网络拓扑形态,Mesh 这个词也由此而来。Service Mesh 的出现主要带来了以下两方面的变革:

 

  • 解决了微服务框架中的服务流量管理的痛点,使开发人员专注于业务本身;

  • 将服务通信及相关管控功能从业务程序中分离并下层到基础设施层,使其和业务系统完全解耦。

 

生态发展

 


2013 年,Airbnb 发布了 SmartStack ,为新兴的“微服务”架构提供了进程外服务发现机制(使用 HAProxy )。当然,许多以企业在此之前都进行过此类技术的研究。从 2000 年代初开始,Google 就在开发 Stubby RPC 框架,后来演变为 gRPC 以及 Google Frontend (GFE) 和 Global Software Load Balancer (GSLB),在 Istio 中依然可以看到这些产品的特征。2010 年代初期,Twitter 开始开发基于 Scala 的 Finagle,Linkerd 由此衍生而来。

 

2014 年底,Netflix 发布了一整套基于 JVM 的实用程序, 包括 Prana,这是一个“sidecar”进程,允许任何语言编写的应用程序服务通过 HTTP 与库的独立实例进行通信。2016 年,NGINX 团队开始谈论“ Fabric 模型”,它与服务网格非常相似,但需要使用他们的商业 NGINX Plus 产品来实现。此外,Linkerd v0.2 于 2016 年 2 月发布,尽管该团队后来才开始将其称为 Service Mesh。  

 

Service Mesh 历史上的其他重要事件还包括 2017 年 5 月发布的 Istio、2018 年 7 月的 Linkerd 2.0、2018 年 11 月的 Consul Connect 和 Gloo Mesh 、2019 年 5 月的服务网格接口 (SMI) 以及同年 9 月发布的 Maesh(现称为 Traefik Mesh ) 和 Kuma。     

 

其他企业的产品,如 HashiCorp 的 Consul 等,也都是从上述技术中汲取灵感。

 

实践现状

 

很多企业都是多协议、多语言栈的,他们选择使用 Service Mesh 来解决复杂的服务治理问题。在之前的一些实践取得正反馈后,Service Mesh 使用范围也在扩大。如今的 Service Mesh 不再局限于 RPC,开始向对象存储、加解密、MySQL、Redis 等领域深入。

 

但总体看,如今 Service Mesh 落地还是遇到了大的技术挑战,远没有达到企业理想的使用状态。有一定研发能力的企业使用传统治理模式也可以做得不错,这时就不会选择完全换成 Mesh 架构,只会在一些新的、没有历史负担的业务上试用。

 

本质上,Service Mesh 只是转移了复杂度,当业务发展到一定规模后,复杂度问题就会再次显现。sidecar 模式很适用于逻辑复杂的场景,如路由、治理,灵活且对业务无入侵。但在大规模场景下,其复杂度就上来了,性能优势不再明显,资源占用也变得不可忽略。可以说,sidecar 模式天生在大规模场景应用中就有一定的局限性。

 

为解决这个问题,今年九月,Istio 推出了 Sidecarless 的 Ambient Mesh。Ambient 是将 Istio 分成两个不同的层次:安全覆盖层(四层治理)和 七层处理层(七层治理)。但在网易数帆云原生平台负责人冯常健看来,四层治理模式将复杂度降到了 Node 级别,但可能只有对网格安全能力感兴趣的企业会尝试,而七层治理模式本质上还是独立的应用层代理,链路也并未减少。因此,对于该模式的应用,业内更多还是持观望态度。

 

现在,Service Mesh 社区还在统一的方向演化。比如今年 4 月谷歌声明将 Istio 捐赠给 CNCF,9 月份 Istio 正式成为 CNCF 孵化项目。这一事件使 CNCF 社区的确定性更强,也消除了前些年大家对社区治理、法规等方面的顾虑。

 

但在网关层面,社区基本还是分为 NGINX 和 Envoy 两派:Kong 、APISIX 等基于 NGINX,网易、阿里云等更多应用 Envoy 技术栈。有人认为 NGINX 及其生态已经比较成熟了,但随着 Kubernetes Gateway API 的成熟,今年社区推出了 Envoy Gateway 组件,新一轮网关标准定义的争论再次掀起。

 

Kubernetes Gateway API 对标的是 Ingress API。Ingress 的 API 解决流量从集群外导入集群内的问题,但表达能力较弱,使用场景有限,因此社区推出了 Kubernetes Gateway API,希望其提供更高级的网络能力。

 

Kubernetes Gateway API 直接促进了 Envoy Gateway 项目的发展。Envoy Gateway 进而统一了网关的控制面 API。原先网关控制面是通过 xDS 控制数据面,现在更多会基于 Kubernetes Gateway API。

 

实际上,现在各个企业都在从不同的方向尝试对 Service Mesh 进行完善和补充。虽然社区有了各种开源产品,但业内还没有形成像 Kubernetes 这样的事实标准。当有这样的一个事实标准出来后,Service Mesh 才会迎来自己的爆发。这与容器的发展轨迹是类似的。

 

Service Mesh 也在寻找更适合的落地方式。现在,业内有尝试不再将 Service Mesh 作为一个独立的产品,而是将其与 Serverless 结合。Serverless 不让用户去关心服务器,Service Mesh 不让用户关心服务治理,如果将服务治理的 Service Mesh 容器内置到 Serverless 平台里面,企业提交一个业务的容器进项后也会拥有 Serverless 的能力。

2023-01-16 14:486355

评论 1 条评论

发布
用户头像
还是复杂了, 而且, 它提供的所有能力(除了mTLS), 都有更简单的方案可以解决
2023-01-16 16:19 · 上海
回复
没有更多了
发现更多内容

大家都在用哪些开源项目系统?20款推荐

PingCode

开源 项目管理 项目管理工具

FontLab for Mac(Mac字体编辑器)v8.3.0.8766直装激活版

影影绰绰一往直前

QCN9024 and QCN9074: Wallys DR9074 Triband Module ATH11k QSDK Supported

wallyslilly

QCN9074 QCN9024

4K Tokkit Pro for Mac(TikTok内容下载工具)v2.5.0激活版

影影绰绰一往直前

BatchOutput PDF for Mac(PDF文件批量打印软件)v3.1.3激活版下载

影影绰绰一往直前

揭秘看不见人的“黑灯工厂”

AIRIOT

物联网平台 智慧工厂 智慧系统

阿里云容器服务助力万兴科技 AIGC 应用加速

阿里巴巴云原生

阿里云 云原生 容器服务

国外服务器租用:如何在预算内选择最优服务

一只扑棱蛾子

国外服务器

Lyn for Mac(轻量级图像查看器)v2.3.7中文版

影影绰绰一往直前

PDF Checkpoint for mac(PDF自动化批处理工具)v1.9.20激活版

影影绰绰一往直前

Bike for Mac(创意写作软件)v1.18(168)激活版

影影绰绰一往直前

StarRocks 生成列:百倍提速半结构化数据分析

StarRocks

数据库 StarRocks 半结构化数据分析

鸿蒙Next来了,企业应该如何快速应对

Onegun

鸿蒙 鸿蒙系统

智能开发助手——华为云CodeArts Snap,揭开智能研发新篇章

华为云PaaS服务小智

人工智能 华为云

Web Components从技术解析到生态应用个人心得指北

zhoulujun

Project项目管理软件好用吗?实用性分析

PingCode

开源 项目管理 项目管理软件

VideoProc Converter 4K for mac(一站式视频处理软件)v6.3中文免激活版

影影绰绰一往直前

Mac无损音乐播放器 Audirvana中文激活版下载

iMac小白

Premiere Pro 2024 for Mac(PR 2024视频编辑软件)v24.1中文激活版

iMac小白

【论文解读】用于代码处理的语言模型综述

合合技术团队

代码 自然语言模型 大语言模型 文献综述

​食品饮料行业如何进行数字化转型?

万界星空科技

数字化转型 mes 万界星空科技 食品饮料行业数字化转型 食品MES

百度搜索Push个性化:新的突破

百度Geek说

推荐算法 百度搜索 搜索push

为什么数字人和真人一模一样?

青否数字人

VideoProc Converter for mac(全能视频处理软件)v6.3中文激活版

影影绰绰一往直前

手机崩溃日志的查找与分析

雪奈椰子

泛互联网行业A/B测试全解析:产品优化的创新之道

字节跳动数据平台

A/B 测试

Tower for Mac(强大的Git客户端)v10.3注册激活版

影影绰绰一往直前

SnippetsLab for Mac(mac代码管理器)v2.4.0激活版

影影绰绰一往直前

百度基于金融场景构建高实时、高可用的分布式数据传输系统的技术实践

JackJiang

网络编程 即时通讯 IM

万界星空科技注塑行业生产管理MES系统管理

万界星空科技

mes 万界星空科技 注塑制造业 注塑MES 注塑生产管理系统

Permute 3 for mac(全能媒体格式转换器)v3.11.4中文版下载

iMac小白

服务网格发展5年:复杂性问题悬而未决,社区依然“热闹”非凡_语言 & 开发_褚杏娟_InfoQ精选文章