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

08 | 如何在CMDB中落地应用的概念?

稳定性保障平台
基础服务中
服务化框架
发布系统
监控系统
多服务分组问题
多IDC问题
多环境问题
应用名定义规范
技术团队的组织架构
业务维度的拆分
服务树的概念
CMDB在基础服务体系中的核心位置
应用的集群服务分组建设
有效组织和管理应用
如何在CMDB中落地应用这个核心概念
CMDB是整个运维平台的基石
应用是微服务架构体系下运维的核心
运维平台的基石,如何在CMDB中落地应用的概念

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

我们前面讲了应用是整个微服务架构体系下运维的核心,而 CMDB 又是整个运维平台的基石。今天我就讲讲在 CMDB 中如何落地应用这个核心概念,以及如何建立应用集群分组的思路。

如何有效组织和管理应用

微服务架构下会有很多应用产生出来,少则十几、几十个,多则上百甚至上千个。这时我们面临的第一个问题就是如何有效地组织和管理这些应用,而不是让它们在各处散乱,命名方式和层次结构可能还不统一。
你可能接触过“服务树”的概念,这个提法是小米在早期互联网运维实践的分享中传播出来的。我第一次听到这个概念是在 13 年阿里技术嘉年华大会上听小米运维的分享。再往前,这个概念应该是从百度的运维体系中借鉴出来的。
这里的服务实际对应的就是我们前面提到的应用这个概念。据我了解,在阿里和腾讯都是叫作应用,现在业界比较通用的叫法也是应用。其实叫什么并不重要,关键还是要学习到对这个概念的管理方式。
从服务树这个名字中,我们就可以了解到,有效组织和管理应用的方式,就是把它组织成一个树形的层次结构。这种管理模式,无论是在 BAT,还是在其它的互联网公司,基本都是一样的思路和模式,所以叫法虽然不同,但是思路上却是相通的,可谓异曲同工。
基于业务维度的拆分,对应产生了我们的应用拆分原则。比如对于电商公司,大的维度会有电商、支付、广告、流量和搜索等业务领域;进一步,电商业务领域里最典型的会有用户、会员、商品、交易、商家、店铺以及物流等;这里面还可以再进一步细分,比如商品会有详情、SKU、SPU、库存、评价、标签等。
讲到这里,我们再看一下技术团队的组织架构,基本上是对应着整个业务技术架构的拆分的。也就是业务架构决定了技术架构,而技术架构又决定了一个研发团队的组织架构,这个组织架构中不同的团队单元分别承担着对应业务的需求开发和实现职责。
上面这个组织架构建设的逻辑和思路,也是我们在组建团队和职责划分时可以参考的。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

CMDB在基础服务体系中的核心位置 CMDB作为运维平台的基石,对于应用的组织管理和集群服务分组建设至关重要。在微服务架构下,有效组织和管理大量应用是一个挑战,而通过构建应用树的层次结构,可以清晰地管理应用。根据业务维度的拆分原则,可以将应用组织成产品线-业务团队-应用的结构,确保团队职责清晰,协作顺畅。同时,对应用命名规范的设定也是必要的,以确保统一和易懂性。在应用的集群服务分组建设中,需要考虑多环境、多IDC和多服务分组等需求场景,以建立应用-集群服务分组-资源的对应关系。这些信息是CMDB中最为关键和核心的,对于运维工作的高效开展至关重要。因此,业务架构的合理拆分和职责明晰将直接影响到后续团队组织架构和运维工作的有序进行。 CMDB中保存的“应用-分组-资源”的对应关系对于周边系统都是必要的,如监控系统、发布系统、服务化框架、基础服务等。这些系统依赖CMDB中的关键信息来实现监控、发布、配置管理、服务注册、服务发现、稳定性保障等功能。基于以应用为核心的CMDB中,又衍生出“应用-集群服务分组-资源”这样一个运维体系中的核心关系。文章深入浅出地阐述了基于应用为核心的运维视图的建立,强调了CMDB中关系信息的重要性。 总的来说,本文通过对CMDB在基础服务体系中的核心位置的分析,为读者提供了关于CMDB中应用落地应用概念的重要思路和方法。文章内容丰富,涵盖了监控、发布、基础服务以及稳定性平台对CMDB中关系信息的依赖,为读者提供了全面的视角。文章内容简洁明了,适合读者快速了解CMDB在基础服务体系中的核心位置的重要性和作用。

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

全部留言(13)

  • 最新
  • 精选
  • 赵成
    置顶
    本文重点,应用集群如何管理?怎么分组?以及组织架构如何与技术架构相匹配? 欢迎大家讨论。
    2018-01-08
    3
  • 圣诞使者
    我想问下,cmdb需要体现应用的依赖关系吗?

    作者回复: 不需要,应用的依赖更多体现在服务调用层面,cmdb里面的应用粒度还是会比较粗。这一点后面会有文章讲到。

    2018-01-10
    2
    2
  • 宵伯特
    对于小的开发团队或者初创的开发团队可能在基础设施架构的管理上并没有过多的资源,而更偏向于使用云端的设施或架构,甚至如serverless之类的计算服务。这方面的运维管理会有较大的差异或者模式上的差别吗?

    作者回复: 体量不同,管理方式和采用的技术手段必然不一样,就跟数据量大的表和量小的表,查询方式和索引方式一定是不一样的。 量不大的时候可以怎么快怎么来,即使没有运维,问题也不大,但是要有意识,如果业务量开始快速增长了,就要有规划和设计了。

    2018-01-09
    2
  • 刘斌
    之前看过您的文章提过“应用层的CMDB”,我感觉基础设施层CMDB不会涉及应用,还是以服务器为中心。应用所在的机器(及依赖的缓存、队列等),是在应用层的CMDB?

    作者回复: 其实不用纠结做在哪里,关键是要看解决什么问题,怎么解决问题,cmdb只是一个概念而已。

    2018-01-24
    1
  • 天舟
    框架已经搭好,接下来就期待博主能讨论一个具体的实施方法了,比如说是纯粹基于name还是引入了tag,比如相关的组策略等等

    作者回复: Tag模式适用于场景更复杂,体量更大的情况下,这种情况需要更为灵活的查询和分类,我建议体量不大的话尽量简化设计。我们自己就当前情况,一直是通过相对固定的分组模式来管理。

    2018-01-09
    1
  • james
    应用所在容器不固定如何处理关系呢,比如弹性扩容所容以及应用down了重新启动一个docker镜像

    作者回复: 应用跟运行载体不一定是ip,容器id或者pod的对应关系也可以

    2018-03-26
  • casper2dd
    cmdb提供API或者命令 用来查询应用 资源的信息 当cmdb信息有变化的时候 其他平台通过API或者命令 同步最新的信息

    作者回复: 量大的话可以通过消息方式处理变更

    2018-01-16
  • 技术修行者
    CMDB在整个系统中的作用,它需要和其他支撑系统进行集成,包括: 1. 应用发布系统 2. 系统监控平台 3. 应用治理平台 完整的配置管理=资源配置管理 + 应用配置管理。资源配置管理主要是对数据中心的管理,包括主机、网络等,应用配置管理主要针对应用运行所需要环境的配置管理。在微服务体系下,应用配置管理会变得更加复杂和重要。
    2020-05-28
    3
  • kobe
    你好 我想问下这个服务树的结构需要怎么设计实现呢 就是可能每个层次的结构都不一样 比如 组织架构下有项目 项目下有应用和中间件等 这个树状结构要怎么实现呢
    2023-08-03归属地:上海
  • 怀揣梦想的学渣
    作者有想推荐分享的服务树相关的资料吗
    2022-02-19
收起评论
显示
设置
留言
13
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部