赵成的运维体系管理课
赵成
蘑菇街平台技术总监
立即订阅
5553 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 带给你不一样的运维思考
免费
应用运维体系建设 (11讲)
01 | 为什么Netflix没有运维岗位?
02 | 微服务架构时代,运维体系建设为什么要以“应用”为核心?
03 | 标准化体系建设(上):如何建立应用标准化体系和模型?
04 | 标准化体系建设(下):如何建立基础架构标准化及服务化体系?
05 | 如何从生命周期的视角看待应用运维体系建设?
06 | 聊聊CMDB的前世今生
07 | 有了CMDB,为什么还需要应用配置管理?
08 | 如何在CMDB中落地应用的概念?
09 | 如何打造运维组织架构?
10 | 谷歌SRE运维模式解读
11 | 从谷歌CRE谈起,运维如何培养服务意识?
效率和稳定性最佳实践 (20讲)
12 | 持续交付知易行难,想做成这事你要理解这几个关键点
13 | 持续交付的第一关键点:配置管理
14 | 如何做好持续交付中的多环境配置管理?
15 | 开发和测试争抢环境?是时候进行多环境建设了
16 | 线上环境建设,要扛得住真刀真枪的考验
17 | 人多力量大vs.两个披萨原则,聊聊持续交付中的流水线模式
18 | 持续交付流水线软件构建难吗?有哪些关键问题?
19 | 持续交付中流水线构建完成后就大功告成了吗?别忘了质量保障
20 | 做持续交付概念重要还是场景重要?看“笨办法”如何找到最佳方案
21 | 极端业务场景下,我们应该如何做好稳定性保障?
22 | 稳定性实践:容量规划之业务场景分析
23 | 稳定性实践:容量规划之压测系统建设
24 | 稳定性实践:限流降级
25 | 稳定性实践:开关和预案
26 | 稳定性实践:全链路跟踪系统,技术运营能力的体现
27 | 故障管理:谈谈我对故障的理解
28 | 故障管理:故障定级和定责
29 | 故障管理:鼓励做事,而不是处罚错误
30 | 故障管理:故障应急和故障复盘
31 | 唇亡齿寒,运维与安全
云计算时代的运维实践 (6讲)
32 | 为什么蘑菇街会选择上云?是被动选择还是主动出击?
33 | 为什么混合云是未来云计算的主流形态?
34 | Spring Cloud:面向应用层的云架构解决方案
35 | 以绝对优势立足:从CDN和云存储来聊聊云生态的崛起
36 | 量体裁衣方得最优解:聊聊页面静态化架构和二级CDN建设
37 | 云计算时代,我们所说的弹性伸缩,弹的到底是什么?
个人成长 (5讲)
38 | 我是如何走上运维岗位的?
39 | 云计算和AI时代,运维应该如何做好转型?
40 | 运维需要懂产品和运营吗?
41 | 冷静下来想想,员工离职这事真能“防得住”吗?
42 | 树立个人品牌意识:从背景调查谈谈职业口碑的重要性
加餐 (4讲)
划重点:赵成的运维体系管理课精华(一)
划重点:赵成的运维体系管理课精华(二)
划重点:赵成的运维体系管理课精华(三)
新书 |《进化:运维技术变革与实践探索》
结束语 (1讲)
结束语 | 学习的过程,多些耐心和脚踏实地
赵成的运维体系管理课
登录|注册

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

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

应用的起源

我们知道,微服务架构一般都是从单体架构或分层架构演进过来的。软件架构服务化的过程,就是我们根据业务模型进行细化的过程,在这个过程中切分出一个个具备不同职责的业务逻辑模块,然后每个微服务模块都会提供相对应业务逻辑的服务化接口。
如果解释得简单点,就一个字,!如下图,从一个单体工程,拆分出 N 个独立模块。
这些模块可以独立部署和运行,并提供对应的业务能力。拆分后的模块数量与业务体量和复杂度相关,少则几个、十几个,多则几十、几百个,所以为了统一概念,我们通常称这些模块为应用
为了确保每个应用的唯一性,我们给每个应用定义一个唯一的标识符,如上图的 APP-1、APP-2 等,这个唯一标识符我们称之为应用名。
接下来,这个定义为应用的概念,将成为我们后续一系列微服务架构管理的核心概念。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《赵成的运维体系管理课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • 赵成
    1.软件系统中,基础设施和组件都是为上层的一个个业务应用所服务的,识别和建立它们之间的关系的非常重要,这个是运维体系化的前提。

    2.要从应用的视角去看这些基础服务,不要将它们与应用割裂。

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

    作者回复: “要求整个开发团队的管理者或架构师有全面的统筹规划的能力,以便促进各个模块之间的协调合作。
    而国内开发者可能面临更多的问题就是架构体系受限于组织结构,管理者缺乏对结构转型的经验和能力,自然导致团队成员缺乏思维转变的动力。”

    上面这段分析的非常到位,也是我一直在讲的现在做运维,首要是思路上要先转变过。后面有几篇文章中我也会提到类似的观点,还有一篇专门介绍组织架构和组织协作的,欢迎继续讨论!

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

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

    2018-03-09
    2
  • 竹寺
    每一次读都有新的体会。结合工作中的实际情况,会有新的感受和理解。跟接触到不同的开发团队也有莫大关系。
    2019-07-06
    1
  • 付盼星
    哈哈,每次看作者的文章都有一种从文章中验证自己想法的感觉,读着读着,就会感慨,原来作者也是这么想的,很感谢公司,一来是初创公司,有很好的窗口去做这件事,二来是领导的前瞻性和信任,最后这件事才得以顺利实施。PS:开发确实缺少运维思维,运维和开发两者的确需要互补,前提是开发能把端到端交付先完成,不然整个流程都没走完。

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

    可以多留言讨论。

    2018-02-28
    1
  • 牧野静风
    还是个传统公司的运维,一直想要融入到新项目的筹备,可是只是最后上线才知道有这个项目,传统的方式作为一个运维好难改变现实
    2019-07-19
  • kevinsu
    很不错,我们目前所在的公司就是使用了微服务但是不成体系,相互对立!
    2019-05-16
  • 松花皮蛋me
    一切都应该以应用为基础,包含cmdb和变更管理等等
    2019-02-17
  • 恒念
    我更新到现在版本后,复制app里的文章粘贴出去,再也无法完整粘贴了。请帮忙看看。
    比如,复制了一大段,粘贴成了这个样子:
    我会从这几个方面来讲:应用的起源、应用模型和应用关系模型建模...
    极客时间版权所有: https://time.geekbang.org/column/article/1682?device=geekTime.ios
    2018-06-28
  • 希望
    “架构体系受限与组织结构”是国内互联网公司运维发展过程中的普遍问题,在这种情况下,是自上而下去推动转型还是自下而上去争取变革,两种情况下的实现难度有着巨大差异。转变思路,不仅仅是运维需要转变,还包括产品、开发、测试一起。对于背负历史包袱的项目和产品来说,运维模式转型是成本开销,希望可以听老师分享一些如何推动产品进行运维模式转型的实际案例,以及如何换位思考去影响和推动开发思路上的转变。

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

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

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

    2017-12-24
收起评论
11
返回
顶部