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

25 | 分布式系统关键技术:服务调度

服务工作流和编排
服务的弹性伸缩和故障迁移
服务状态的维持和拟合
架构的manifest
服务清单
架构的版本控制
服务生命周期管理
服务状态管理
服务注册中心
服务应用生命周期管理
架构的版本管理
服务发现
服务依赖关系
服务关键程度
资源/服务调度
整个架构的版本管理
服务状态和生命周期的管理
服务调度
下一讲的主题:流量调度和状态数据调度
分布式系统架构的关键技术

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

你好,我是陈皓,网名左耳朵耗子。
服务治理,你应该听得很多了。但是我想说,你所听到的服务治理可能混合了流量调度等其它内容。我们这里会把服务治理和流量调度分开来讲。所以,今天这节课只涉及服务治理上的一些关键技术,主要有以下几点。
服务关键程度
服务依赖关系
服务发现
整个架构的版本管理
服务应用生命周期全管理

服务关键程度和服务的依赖关系

下面,我们先看看服务关键程度和服务的依赖关系。关于服务关键程度,主要是要我们梳理和定义服务的重要程度。这不是使用技术可以完成的,它需要细致地管理对业务的理解,才能定义出架构中各个服务的重要程度。
然后,我们还要梳理出服务间的依赖关系,这点也非常重要。我们常说,“没有依赖,就没有伤害”。这句话的意思就是说,服务间的依赖是一件很易碎的事。依赖越多,依赖越复杂,我们的系统就越易碎。
因为依赖关系就像“铁锁连环”一样,一个服务的问题很容易出现一条链上的问题。因此,传统的 SOA 希望通过 ESB 来解决服务间的依赖关系,这也是为什么微服务中希望服务间是没有依赖的,而让上层或是前端业务来整合这些后台服务。
但是要真正做到服务无依赖,我认为还是比较有困难的,总是会有一些公有服务会被依赖。我们只能是降低服务依赖的深度和广度,从而让管理更为简单和简洁。在这一点上,以 Spring Boot 为首的微服务开发框架就开了一个好头。
微服务是服务依赖最优解的上限,而服务依赖的下限是千万不要有依赖环。如果系统架构中有服务依赖环,那么表明你的架构设计是错误的。循环依赖有很多的副作用,最大的问题是这是一种极强的耦合,会导致服务部署相当复杂和难解,而且会导致无穷尽的递归故障和一些你意想不到的问题。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了分布式系统中服务调度的关键技术,包括服务状态的维持和拟合、服务的弹性伸缩和故障迁移、以及服务工作流和编排。作者首先强调了服务间的依赖关系对系统稳定性的重要性,并提出了解决循环依赖的设计模式。其次,文章详细介绍了服务状态的维持和拟合过程,强调了集群控制系统在维护服务状态时的重要性,以及拟合过程中的稳健性和严谨性。接着,文章阐述了服务的弹性伸缩和故障迁移所需的复杂操作步骤,以及宠物模式和奶牛模式的区别。最后,文章探讨了服务工作流和编排的重要性,指出在微服务中使用轻量的中间件来取代传统的服务编排功能,并展望了服务编排工作流引擎中间件的发展。总的来说,本文全面阐述了分布式系统中服务调度的关键技术,为读者提供了深入的技术视角和启发。

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

全部留言(34)

  • 最新
  • 精选
  • architect-lc
    关于分布式调用监控,为什么您推荐zipkin?skywalking和pinpoint您有什么评价吗?目前项目正在考虑分布式调用监控的问题,谢谢

    作者回复: 主要是社区和、跨语言、轻量、可扩展性这几个方面

    2018-01-01
    2
    9
  • 恩言
    皓哥,能推荐一两本相关书籍么

    作者回复: 后面的文章会有

    2017-12-25
    4
  • 夜行观星
    每篇文章都看好几次
    2017-12-22
    30
  • 菩提树下的杨过
    服务的循环依赖,有时候是公司组织结构和管理不合理导致的,比如几个相对独立的部门,A部门要搞一个新需求,依赖B部门提供的服务,B部门又依赖C部门的服务,而C又依赖A部门的服务。如果没有能站在上帝视角俯视全局的明白人指路(通常是公司最熟悉技术及业务的资深人士或xx委员会),部门之间沟通又不顺畅的情况下,服务依赖环就这么产生了,甚至还可以顺利上线,为将来又添新坑
    2018-06-24
    3
    22
  • zipkin好像对代码侵入性有点大
    2018-04-21
    17
  • ytz
    腾讯的tars也带有versionset,配合序列化协议实现兼容和升级也是非常便利。
    2018-08-23
    8
  • Vance
    作为一个App开发,看的是一脸懵逼,但是感觉后台的架构,分布式系统,还有自动运维这些技术是真的牛逼!希望有机会可以更深入学习一下。
    2019-07-08
    1
    5
  • 幼儿编程教学
    请教。state和status的区别是什么?
    2018-12-31
    3
    4
  • 蟹蟹
    前面都看懂 但是最后的服务编排没明白…
    2018-07-02
    4
  • JasonZ
    如果系统架构中有服务依赖环,那么表明你的架构设计是错误的。循环依赖有很多的副作用,最大的问题是这是一种极强的耦合,会导致服务部署相当复杂和难解 这个能举例说明下么?而不是结论
    2019-09-07
    2
    3
收起评论
显示
设置
留言
34
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部