许式伟的架构课
许式伟
七牛云CEO
立即订阅
19946 人已学习
课程目录
已更新 71 讲 / 共 77 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 怎样成长为优秀的软件架构师?
免费
基础平台篇 (21讲)
01 | 架构设计的宏观视角
02 | 大厦基石:无生有,有生万物
03 | 汇编:编程语言的诞生
04 | 编程语言的进化
05 | 思考题解读:如何实现可自我迭代的计算机?
06 | 操作系统进场
07 | 软件运行机制及内存管理
08 | 操作系统内核与编程接口
09 | 外存管理与文件系统
10 | 输入和输出设备:交互的演进
11 | 多任务:进程、线程与协程
12 | 进程内协同:同步、互斥与通讯
13 | 进程间的同步互斥、资源共享与通讯
14 | IP 网络:连接世界的桥梁
15 | 可编程的互联网世界
16 | 安全管理:数字世界的守护
17 | 架构:需求分析 (上)
18 | 架构:需求分析 (下) · 实战案例
19 | 基础平台篇:回顾与总结
加餐 | 我看Facebook发币(上):区块链、比特币与Libra币
加餐 | 我看Facebook发币(下):深入浅出理解 Libra 币
桌面开发篇 (16讲)
20 | 桌面开发的宏观视角
21 | 图形界面程序的框架
22 | 桌面程序的架构建议
23 | Web开发:浏览器、小程序与PWA
24 | 跨平台与 Web 开发的建议
25 | 桌面开发的未来
26 | 实战(一):怎么设计一个“画图”程序?
27 | 实战(二):怎么设计一个“画图”程序?
28 | 实战(三):怎么设计一个“画图”程序?
29 | 实战(四):怎么设计一个“画图”程序?
30 | 实战(五):怎么设计一个“画图”程序?
31 | 辅助界面元素的架构设计
课外阅读 | 从《孙子兵法》看底层的自然法则
加餐 | 想当架构师,我需要成为“全才”吗?
32 | 架构:系统的概要设计
33 | 桌面开发篇:回顾与总结
服务端开发篇 (14讲)
34 | 服务端开发的宏观视角
35 | 流量调度与负载均衡
36 | 业务状态与存储中间件
37 | 键值存储与数据库
38 | 文件系统与对象存储
39 | 存储与缓存
40 | 服务端的业务架构建议
41 | 实战(一):“画图”程序后端实战
42 | 实战(二):“画图”程序后端实战
43 | 实战(三):“画图”程序后端实战
44 | 实战(四):“画图”程序后端实战
45 | 架构:怎么做详细设计?
46 | 服务端开发篇:回顾与总结
加餐 | 如何做HTTP服务的测试?
服务治理篇 (11讲)
47 | 服务治理的宏观视角
48 | 事务与工程:什么是工程师思维?
49 | 发布、升级与版本管理
50 | 日志、监控与报警
加餐 | 怎么保障发布的效率与质量?
51 | 故障域与故障预案
52 | 故障排查与根因分析
53 | 过载保护与容量规划
54 | 业务的可支持性与持续运营
55 | 云计算、容器革命与服务端的未来
56 | 服务治理篇:回顾与总结
架构思维篇 (8讲)
57 | 心性:架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣?
59 | 少谈点框架,多谈点业务
60 | 架构分解:边界,不断重新审视边界
加餐 | 实战:“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
许式伟的架构课
登录|注册

49 | 发布、升级与版本管理

许式伟 2019-10-15
你好,我是七牛云许式伟。
今天我们探讨服务治理的第一个环节:发布与升级。
在应用开发工程师完成一个版本的迭代后,他们交付的是软件新版本的源代码,这些代码存储在源代码仓库中。
一次正常的发布过程,大体分为这样几个典型的步骤:
构建:从源代码仓库检出源代码,编译出对应的目标文件,也就是我们新版本的软件。
测试:对新版本的软件进行测试,以确认软件的质量符合期望。
打包:将新版本的软件及其执行所需的相关文件,比如配置文件,一起打包并记录相应的版本号。
部署:将打包好的新版本更新到线上环境。为了保证线上环境的质量,更新过程往往需要灰度,而不是一步到位直接全面切换到新版本。
当然,并不是所有的升级都是发布新版本的软件。有时候我们仅仅只是进行配置变更,也就是修改线上的配置参数。配置参数可能存在于软件配套的配置文件中,也可能存在于线上的某个配置数据库。
整个发布与升级的过程,大体可以用下图来表示。
从上面我们可以看出,发布是一个具备很强的事务特征的工作,过程很复杂。不仅如此,发布工作的心智负担也很大。所有 SRE 都应该牢牢记住以下这句七字箴言:
变更是故障之源。
我们应该怎么做,才能彻底解决发布与升级的问题?
让我们从 “工程师思维” 的角度,用系统化、产品化的思维来考虑这样一个复杂事务。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(9)

  • 风清扬
    老师,发布升级版本管理后面会有详细讲解吗?光讲解原理,没实际操作,很难有具体的收获。
    2019-10-15
    3
  • 葫芦娃
    “SRE 需要非常了解某个新发布中包含的所有具体改动,以便在发布出现问题时可以更快地进行在线调试”——发布出现问题还是应该先回退版本,恢复服务吧,调试定位问题感觉应该业务开发来做,SRE通常也无能为力,如果是devops就没什么可推脱了

    作者回复: 是这样,出问题首先第一要务应该先恢复服务,但是有可能的话还应该尽可能保留现场,所以把流量切走是更好的做法。

    2019-10-15
    2
  • Geek_88604f
    在配置管理中老师提到:‘’将配置管理与物理硬件环境彻底进行解耦,这也是数据中心操作系统(DCOS)在做的事情。本质上,你也把它理解成是将高频的配置变更支持做到应用逻辑中,只不过这由一个基础平台来实现罢了。‘’对于这一点不太理解,配置中心已经将服务的配置管理做的很好了,为啥还会有‘‘将配置管理与物理硬件环境彻底进行解耦’’的需求呢?这么做的优势是什么?

    作者回复: 我们希望升级才需要配置变更,硬件环境改变不需要配置变更。这样的话,配置中心就需要针对集群的逻辑视图,而不是物理视图。

    2019-11-06
    1
  • Fs
    这篇比较简单,事务性介绍
    2019-10-19
    1
  • Aaron Cheung
    七牛云项目发布是sre还是软件开发工程师自己发布呢

    作者回复: sre

    2019-10-15
    1
  • Eternal
    将配置管理与物理硬件环境彻底进行解耦,这也是数据中心操作系统(DCOS)在做的事情。本质上,你也把它理解成是将高频的配置变更支持做到应用逻辑中,只不过这由一个基础平台来实现罢了。

    讲的是将配置打包到douker镜像中吗?

    作者回复: 讲的是容器调度

    2019-11-23
  • 日拱一卒
    对配置管理中的数据配置操作系统不太熟悉,希望作者能在后面深入展开讲一下。
    2019-11-18
  • 诗泽
    看了上一节和这一节内容对于“事务性工作”还是不太理解,老师可以详解一下吗?
    2019-10-18
  • 曹龙
    收获满满😬
    2019-10-15
收起评论
9
返回
顶部