左耳听风
陈皓
网名“左耳朵耗子”,资深技术专家
180930 人已学习
新⼈⾸单¥98
登录后,你可以任选6讲全文学习
课程目录
已完结/共 119 讲
左耳听风
15
15
1.0x
00:00/00:00
登录|注册

55 | 管理设计:服务网格

用于服务间的访问安全控制
通过Pilot控制器应用新规则
从Envoy收集监控数据
收集流量相关的性能指标
提供服务发现、负载均衡、限流熔断等能力
轻量简单
Rust/Go实现
设计重点包括可靠性和与Kubernetes的结合
开源软件实现了服务网格
服务本身只需关注业务逻辑
服务网格类似传输层协议
边车模式演化为服务网格
与Kubernetes的结合
Service Mesh作为独立部署的基础设施
Service Mesh作为Gateway
集中式Sidecar作为备选方案
高可靠性和故障处理
lstio-Auth身份认证组件
Mixer收集器
lstio和Conduit
Sidecar集群成为Service Mesh
出现Sidecar作为专门层
编写SDK/Lib/Framework集成到应用服务
弹力设计的模式标准化
TCP/IP成为成功的网络协议
应用层实现流控
分离出网络层实现远程通信
原始的进程直接通信
解耦和分离分布式系统架构中的控制层面
对应用服务透明无侵入
由轻量级网络代理组成
服务网格是处理服务间通信的基础设施
业务开发和运维工作量降低
在已部署好的Sidecar集群中放置业务服务
加速业务开发
提高整体控制和管理效率
分离系统控制和业务逻辑
小结
Service Mesh的设计重点
Service Mesh相关的开源软件
Service Mesh的演化路径
什么是Service Mesh
Think big
Sidecar边车模式
陈皓(左耳朵耗子)
管理设计篇之“服务网格”
分布式系统设计模式

该思维导图由 AI 生成,仅供参考

你好,我是陈皓,网名左耳朵耗子。
前面,我讨论了 Sidecar 边车模式,这是一个非常不错的分布式架构的设计模式。因为这个模式可以有效地分离系统控制和业务逻辑,并且可以让整个系统架构在控制面上可以集中管理,可以显著地提高分布式系统的整体控制和管理效率,并且可以让业务开发更快速。
那么,我们不妨在上面这个模式下 think big 一下。假如,我们在一个分布式系统中,已经把一些标准的 Sidecar 给部署好了。比如前面文章说过的熔断、限流、重试、幂等、路由、监视等这些东西。我们在每个计算结点上都部署好了这些东西,那么真实的业务服务只需要往这个集群中放,就可以和本地的 Sidecar 通信,然后由 Sidecar 委托代理与其它系统的交互和控制。这样一来,我们的业务开发和运维岂不是简单至极了?
是啊,试想一下,如果某云服务提供商,提供了一个带着前面我们说过的那些各式各样的分布式设计模式的 Sidecar 集群,那么我们的用户真的就只用写业务逻辑相关的 service 了。写好一个就往这个集群中部署,开发和运维工作量都会得到巨大的降低和减少。

什么是 Service Mesh

这就是 CNCF(Cloud Native Computing Foundation,云原生计算基金会)目前主力推动的新一代的微服务架构——Service Mesh 服务网格。
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 这个服务网络专注于处理服务和服务间的通讯。其主要负责构造一个稳定可靠的服务通讯的基础设施,并让整个架构更为的先进和 Cloud Native。在工程中,Service Mesh 基本来说是一组轻量级的服务代理和应用逻辑的服务在一起,并且对于应用服务是透明的。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了分布式系统设计模式中的重要模式——服务网格。作者首先引出了边车模式的重要性,并将其演化为服务网格,将其比喻为分布式系统中的传输层协议,为服务间通讯提供了标准化的集群功能。服务网格的出现和演化路径得到了详细解释,并介绍了当前流行的开源软件。此外,文章还强调了服务网格的设计重点,特别是在整体架构上的一些设计要点,以及服务网格与Kubernetes和Docker的关系。通过本文,读者可以快速了解服务网格的概念、重要性和相关技术,为深入学习和应用服务网格提供了全面的概览。文章内容丰富,涵盖了服务网格的重要性、演化过程、开源软件实现以及设计重点,为读者提供了全面的技术视角,有助于加深对服务网格的理解和应用。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《左耳听风》
新⼈⾸单¥98
立即购买
登录 后留言

全部留言(17)

  • 最新
  • 精选
  • Alan
    能不能,每篇文章做个总结,比如微服务和服务网格的区别,他们的优势,劣势,解决了什么问题,适合什么规模的业务,他们的相同点,不同点,感觉文章讲的有点模糊
    2018-05-03
    7
    23
  • 闫飞
    最后一段的意思是,服务网格和API网关可以结合使用的,两种技术并不互相冲突吧。服务网格自己本身是完全去中心化的,给每个微服务运行期实例都加了个壳,两者是一荣俱荣一损俱损的关系,所以往往部署上也应该是在一个容器或VM上的。 目前linkerd是比较成熟而功能完备的,奈何JVM本身不小,打包到容器中就会额外多几十乃至上百MB,运行期也要吃掉很多内存。 lstio的数据面是用的C++,性能优势明显所以buoyant作为linkerd背后公司才不得已自己用另外一门无GC的静态语言重写了。他们也想过优化JVM,但只是优化了部分启动时间便放弃了改良路线决定起炉重造了,毕竟优化JVM太难了。
    2018-05-09
    7
  • 俊毓
    在k8s上,如果我们强制每一个服务发布时候,都必须在pod里面绑定一个nginx或者envoy,负责流控,熔断,通信等等功能,然后利用k8s的service服务发现,那我们也可得到一个很基础的服务网格。
    2020-01-12
    5
  • 知行合一
    servise mess其实就是将控制组件云化,实现业务系统只管业务?
    2020-01-10
    4
  • 杉松壁
    谢谢。sidecar的稳定性是必须谨慎的地方
    2020-04-23
    2
  • edisonhuang
    边车模式进一步发展,就出现了服务网格,服务网格单独作为一个集群部署,解决服务之间的流控,熔断,重试等服务通信的问题,类似于网络协议中的传输层。使用服务网格将业务逻辑和服务通讯的控制隔离开来,让分布式服务开发更简单容易
    2019-07-18
    2
  • chenhz
    服务网格的劣势: 多一层通信,响应上比微服务稍逊一筹 服务网格的优势: 1.业务代码无侵入,服务跨语言; 2.将管理与业务逻辑分离,开发只需专注业务代码实现,开发成本更低; 传统微服务的优势: 快; 劣势: 治理方案不统一; 语言相关性
    2019-03-25
    2
  • hua168
    大神,所有文章我看了,没有讲到安全呀……能不能讲下安全……
    2018-05-02
    2
  • 王植萌
    DDD战术设计中的防腐层看起来一定程度上起到的就是sidecar的作用,虽然说是从不同的角度看这个问题。
    2020-12-15
    1
    1
  • escray
    Service Mesh 就是一个 Sidecar 集群? A service mesh is a dedicated infrastructure layer for making service-to-service communication safe, fast, and reliable. The service mesh is a critical component of the cloud native stack. 感觉类似于 service mesh 类的分布式基础技术,对我来说有点像是“屠龙之技”,虽然我也没有完全掌握,但是至少目前来看完全没有应用场景。这些底层技术,也许会逐步和 PaaS 或者 IaaS 平台绑定,对我来说应该是能够理解就可以。 The safest way to handle distribution has been to avoid it as much as possible, even if that meant duplicated logic and data across various systems. 在 Pattern: Service Mesh 那篇文章里面,对于历史脉络梳理的很清楚,软件或者说架构的发展历程,就是不断抽象的过程。先看一遍专栏,然后再看英文原文,可以方便理解。 因为看到留言里面,说 Istio 的架构有所变化,所以去看了一眼官网上的介绍,确实没有明显的标记出 mixer 的模块,同样的 Pilot 和 Istio-Auth 也没有画出来,感觉应该还是会有,只是不在突出说明。Istio 基本上就是 Service Mesh 的开源实现,官网上强调 Traffic management,Observability 和 Security capabilities 三个方面。
    2023-03-27归属地:北京
收起评论
显示
设置
留言
17
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部