2月5-7日QCon全球软件开发大会携手100+位大咖讲师落定北京,点击查看完整日程>> 了解详情
写点什么

服务网格发展 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:483668

评论 1 条评论

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

产品经理训练营 学习起点

DB

面对疫情,我们正在行动!

anyRTC开发者

uni-app android 音视频 WebRTC 在线教育

Soul网关源码阅读(七)限流插件初探

Java 网关 限流

第一章作业

转转

“战复不胜”的产品经理

产品经理训练营

什么是产品经理?——课程总结

Deborah

合约跟单系统APP开发|合约跟单软件开发

系统开发

初探架构,随笔整理

Arvin

软件架构

产品经理训练营 0 期作业第一章作业

郭郭

四,编程范式

Arvin

编程范式

雪天专注行路思考一则

石君

冥想 28天写作

微众银行区块链:领跑产业应用落地 推进开源生态繁荣

CECBC

区块链技术

Nginx 最常用的两个功能:负载均衡和缓存

码农架构

Java nginx 架构 并发

产品实战作业(Job Model)

晓豪

迷茫 产品经理训练营 BTA 邱岳

“公测”成绩亮眼 数字人民币有望重构支付体系

CECBC

数字红包

Task01-产品类JD对比

遠景

产品 字节跳动 产品经理 JD

花了19998买的学习教程!Android跨进程通信导论,技术详细介绍

欢喜学安卓

android 程序员 面试 移动开发

张红珊——第一节课作业

zzz

UML是表达思想的工具

Arvin

UML

40000美元之后,比特币高位震荡加剧,是买?是卖?还是持有?

CECBC

比特币

干货丨深度迁移学习方法的基本思路

博文视点Broadview

Redis不仅仅是缓存,还是……

码农译站

数据库 redis 缓存 关系型数据库 非关系型数据库

对比:微服务VS单体架构

xcbeyond

微服务 单体架构 28天写作

万字解释!在咸鱼被疯抢的网络协议核心彩板手册已曝光!

996小迁

Java 编程 架构 面试 网络协议

量化交易自动炒币软件开发系统

2021年1月初Java开发从小公司跳槽阿里制胜关键:狂刷17套大厂真题

Java架构追梦

Java 阿里巴巴 架构 面试

Android入门你值得拥有!史上最通俗计算机网络分层详解,含BATJM大厂

欢喜学安卓

android 程序员 面试 移动开发

Elasticsearch 横向扩容

escray

elastic 七日更 28天写作 死磕Elasticsearch 60天通过Elastic认证考试

Docker发布开发团队2021年三个首选方向;工信部印发《工业互联网创新发展行动计划(2021-2023 年)》

京东科技开发者

云计算

架构的直观展示

Arvin

架构视图 4+1

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