赵成的运维体系管理课
赵成
《进化: 运维技术变革与实践探索》作者
37829 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
开篇词 (1讲)
效率和稳定性最佳实践 (20讲)
赵成的运维体系管理课
15
15
1.0x
00:00/00:00
登录|注册

02 | 微服务架构时代,运维体系建设为什么要以“应用”为核心?

基础组件
资源层面
场景二:应用名不统一的问题
场景一:线上的缓存和消息队列管理问题
识别基础设施及组件与应用名的关联关系
建立各个基础设施和组件的数据模型
应用运行时所依赖的基础设施和组件
应用管理模型
应用业务模型
应用的唯一标识符
微服务架构演进过程
真实的情况是怎么样的?
应用模型及关系模型的建立
应用的起源
微服务架构时代,运维体系建设为什么要以“应用”为核心?

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

今天我来讲一下微服务架构模式下的一个核心概念:应用
我会从这几个方面来讲:应用的起源、应用模型和应用关系模型建模以及为什么要这样做。最终希望,在微服务的架构模式下,我们的运维视角一定转到应用这个核心概念上来,一切要从应用的角度来分析和看待问题

应用的起源

我们知道,微服务架构一般都是从单体架构或分层架构演进过来的。软件架构服务化的过程,就是我们根据业务模型进行细化的过程,在这个过程中切分出一个个具备不同职责的业务逻辑模块,然后每个微服务模块都会提供相对应业务逻辑的服务化接口。
如果解释得简单点,就一个字,!如下图,从一个单体工程,拆分出 N 个独立模块。
这些模块可以独立部署和运行,并提供对应的业务能力。拆分后的模块数量与业务体量和复杂度相关,少则几个、十几个,多则几十、几百个,所以为了统一概念,我们通常称这些模块为应用
为了确保每个应用的唯一性,我们给每个应用定义一个唯一的标识符,如上图的 APP-1、APP-2 等,这个唯一标识符我们称之为应用名。
接下来,这个定义为应用的概念,将成为我们后续一系列微服务架构管理的核心概念。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

在微服务架构时代,运维体系建设以“应用”为核心至关重要。文章从应用的起源、应用模型及关系模型的建立等方面进行了阐述。微服务架构的演进过程中,单体架构或分层架构被细化为具备不同职责的业务逻辑模块,每个模块提供相应的业务能力,这些模块被称为应用。为了确保每个应用的唯一性,给每个应用定义了一个唯一的标识符,即应用名。除了应用这个实体之外,还存在其他各类基础组件实体,应用需要与这些组件产生和建立各种复杂的关联关系。因此,建立应用模型及关系模型对于后续的运维自动化、持续交付以及稳定性保障至关重要。文章还指出了当前业界在微服务架构下的运维管理存在的问题,如对基础组件的片面对待、应用名不统一等。作者强调了在微服务架构模式下,运维视角需要转移到应用这个核心概念上来,一切问题都要从应用的角度来分析和看待。最后,作者呼吁技术团队要转换视角,规划以应用为核心的运维管理体系,并分享了自己的经验教训。整体而言,本文深入探讨了微服务架构下的运维体系建设,提出了解决问题的思路和建议,对于正在应用微服务架构的技术团队具有重要的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《赵成的运维体系管理课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(13)

  • 最新
  • 精选
  • 宵伯特
    传统的开发模式以产品发布上线为一个节点,但是在现在的敏捷开发和微服务体系下,线上运行也只是整个开发流程中的一个环节。不论是以业务为导向,还是以功能为导向的开发,都需要将开发运行维护的所有环节纳入完整的体系之中,这也便要求整个开发团队的管理者或架构师有全面的统筹规划的能力,以便促进各个模块之间的协调合作。 而国内开发者可能面临更多的问题就是架构体系受限于组织结构,管理者缺乏对结构转型的经验和能力,自然导致团队成员缺乏思维转变的动力。

    作者回复: “要求整个开发团队的管理者或架构师有全面的统筹规划的能力,以便促进各个模块之间的协调合作。 而国内开发者可能面临更多的问题就是架构体系受限于组织结构,管理者缺乏对结构转型的经验和能力,自然导致团队成员缺乏思维转变的动力。” 上面这段分析的非常到位,也是我一直在讲的现在做运维,首要是思路上要先转变过。后面有几篇文章中我也会提到类似的观点,还有一篇专门介绍组织架构和组织协作的,欢迎继续讨论!

    2017-12-23
    10
  • dongcc
    请教一下如何维护后续的应用与基础设施和组建的关联关系?比如研发更新版本在某个缓存里增加了一个namespace,或者消息队列里增加了一个topic(类似这种资源申请是代码里可以自动创建的,可能运维都不知道),以应用为中心的关联关系信息如何维护?人工录入维护还是任何资源申请后台申请还是怎么样?谢谢

    作者回复: 这个要进行约束的,比如创建接口必须要鉴权,不能随意调用,申请环节必须要走流程,也不能随意。我们要做的就是尽量让流程简化,自动化,提升效率。

    2018-03-09
    3
    7
  • 付盼星
    哈哈,每次看作者的文章都有一种从文章中验证自己想法的感觉,读着读着,就会感慨,原来作者也是这么想的,很感谢公司,一来是初创公司,有很好的窗口去做这件事,二来是领导的前瞻性和信任,最后这件事才得以顺利实施。PS:开发确实缺少运维思维,运维和开发两者的确需要互补,前提是开发能把端到端交付先完成,不然整个流程都没走完。

    作者回复: 事物发展的规律都是相同的,所以只要经历过,就会有共鸣。 可以多留言讨论。

    2018-02-28
    4
  • 牧野静风
    还是个传统公司的运维,一直想要融入到新项目的筹备,可是只是最后上线才知道有这个项目,传统的方式作为一个运维好难改变现实

    作者回复: 这是很多公司的状况,根本上还是没有认识到运维的重要性。

    2019-07-19
    1
  • 希望
    “架构体系受限与组织结构”是国内互联网公司运维发展过程中的普遍问题,在这种情况下,是自上而下去推动转型还是自下而上去争取变革,两种情况下的实现难度有着巨大差异。转变思路,不仅仅是运维需要转变,还包括产品、开发、测试一起。对于背负历史包袱的项目和产品来说,运维模式转型是成本开销,希望可以听老师分享一些如何推动产品进行运维模式转型的实际案例,以及如何换位思考去影响和推动开发思路上的转变。

    作者回复: 后面的很多文章都是介绍技术产品实践案例的,你可以先看下后面的文章。

    2018-02-24
  • 黄无由
    paas的能力,有助于微服务

    作者回复: Paas的本质是什么?

    2017-12-24
  • 赵成
    1.软件系统中,基础设施和组件都是为上层的一个个业务应用所服务的,识别和建立它们之间的关系的非常重要,这个是运维体系化的前提。 2.要从应用的视角去看这些基础服务,不要将它们与应用割裂。 3.应用运维层面管理混乱,运维无法场景化,流程无法闭环,首要看是不是忽略了应用这个核心。
    2017-12-23
    33
  • kevinsu
    很不错,我们目前所在的公司就是使用了微服务但是不成体系,相互对立!
    2019-05-16
    2
  • 竹寺
    每一次读都有新的体会。结合工作中的实际情况,会有新的感受和理解。跟接触到不同的开发团队也有莫大关系。
    2019-07-06
    1
  • 松花皮蛋me
    一切都应该以应用为基础,包含cmdb和变更管理等等
    2019-02-17
    1
收起评论
显示
设置
留言
13
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部