写点什么

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

评论 1 条评论

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

实用机器学习笔记十八:过、欠拟合

打工人!

机器学习 深度学习 算法 学习笔记 12月日更

架构实战营模块二作业

lchx08

「架构实战营」

-exec rm 与 xargs rm -rf 深度剖析

liuzhen007

28天写作 12月日更

在不丢失数据的情况下处理屏幕旋转 - Android

坚果

android 28天写作 12月日更

架构实战模块二作业

青青子衿

MQTT X v1.7.0 正式发布:MQTT 5.0 支持最为完整的客户端工具

EMQ映云科技

物联网 IoT mqtt

元宇宙

圣迪

区块链 数字孪生 元宇宙 进化的力量 扩展现实

ArgoCD 简明教程

Se7en

架构实战营模块二作业

zhongwy

架构实战营 「架构实战营」

圣诞节快到了,何不送给Ta一份程序员的浪漫

海拥(haiyong.site)

前端 代码中的浪漫 圣诞节 28天写作 12月日更

学习总结 2021.12.19

mj4ever

学习笔记

模块7作业

Geek_1d37ea

架构实战营

模块三作业

Vincent

「架构实战营」

从对象内存布局了解锁的膨胀

Ayue、

锁升级

🏆【Alibaba中间件技术系列】「EasyExcel实战案例」实战研究一下EasyExcel如何从指定文件位置进行读取数据

码界西柚

EasyExcel Apache POI Alibaba 12月日更

给弟弟的信第17封|拒绝自我感觉良好

大菠萝

28天写作

别做消费主义的祭品

mtfelix

轻松容器化golang应用程序

xcbeyond

golang Docker 28天写作 12月日更

如何做一个区块链浏览器

Rayjun

区块链 区块链浏览器

第二周作业

cqyanbo

服务端质量保证体系(四) 测试环境治理

homber

服务端 质量保证 测试环境 签约计划第二季

作业作业作业作业作业作业作业作业作业作业作业作业作业作业作业作业作业作业作业作作业作业作业作业作业作业作业作业作业作业作业作业作业作业作业作业作业作业作业业作业作业作业作业作业作业作业作业作业作业作业作业作业

AUV

「架构实战营」

项目已成为组织发展的必要手段、企业成长的发动机

Seven的代码实验室

项目管理

模块7学习总结

Geek_1d37ea

架构实战营

微信朋友圈高性能架构

Only

架构实战营 「架构实战营」

架构训练营 - 模块二作业

伊静西蒙

JavaScript 数组方法 .map() 的 5 个使用场景

devpoint

JavaScript map array 12月日更

架构实战营模块2课后作业

墨宝

王者荣耀商城异地多活架构设计

奔奔

Linux之cat命令

入门小站

Linux

事业的智囊团,精神的后花园(19/28)

赵新龙

28天写作

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