极客时间持续交付36讲 学习笔记.docx
- 文档编号:24937714
- 上传时间:2023-06-03
- 格式:DOCX
- 页数:35
- 大小:415.24KB
极客时间持续交付36讲 学习笔记.docx
《极客时间持续交付36讲 学习笔记.docx》由会员分享,可在线阅读,更多相关《极客时间持续交付36讲 学习笔记.docx(35页珍藏版)》请在冰豆网上搜索。
极客时间持续交付36讲学习笔记
极客时间-《持续交付36讲》学习笔记
∙06.发布及监控
o最后一公里
▪部署和发布是有区别的,前者是一个技术范畴,而后者则是一种业务决策
▪应用被部署,并不代表就是发布了
o定义
▪从英文上来看,我们通常既不用deploy这个词,也不用release这个词,而是使用rollout这个词
▪发布是一个慢慢滚动向前、逐步生效的过程
▪我们想要的应该是:
一个易用、快速、稳定、容错力强,必要时有能力迅速回滚的发布系统
o灰度发布的方式
▪灰度发布是指,渐进式地更新每台机器运行的版本,一段时期内集群内运行着多个不同的版本,同一个API在不同机器上返回的结果很可能不同。
▪集群层面的设计,某种程度上是对单机部署理念的重复,只不过是在更高的维度上又实现了一遍
▪蓝绿发布
∙蓝绿发布,是先增加一套新的集群,发布新版本到这批新机器,并进行验证,新版本服务器并不接入外部流量。
此时旧版本集群保持原有状态,发布和验证过程中老版本所在的服务器仍照常服务。
验证通过后,流控处理把流量引入新服务器,待全部流量切换完成,等待一段时间没有异常的话,老版本服务器下线。
∙好处是所有服务都使用这种方式时,实际上创造了蓝绿两套环境,隔离性最好、最可控,回滚切换几乎没有成本
∙2011年出版的《持续交付:
发布可靠软件的系统方法》一书中,就曾提到“蓝绿发布”的概念:
你需要更新一组实例,但并不是直接在原有实例上进行变更,而是重新启动一批对等的实例,在新实例上更新,然后再用新实例替换老实例。
此时老实例仍旧存在,以便回滚。
▪滚动发布
∙滚动发布,是不添加新机器,从同样的集群服务器中挑选一批,停止上面的服务,并更新为新版本,进行验证,验证完毕后接入流量。
重复此步骤,一批一批地更新集群内的所有机器,直到遍历完所有机器。
∙比蓝绿发布节省资源,但发布过程中同时会有两个版本对外提供服务,无论是对自身或是调用者都有较高的兼容性要求,需要团队间的合作妥协
▪金丝雀发布
∙金丝雀发布,从集群中挑选特定服务器或一小批符合要求的特征用户,对其进行版本更新及验证,随后逐步更新剩余服务器。
这种方式,比较符合携程对灰度发布的预期,但可能需要精细的流控和数据的支持,同样有版本兼容的需求。
▪高度抽象后其实就三步
∙停服务
∙覆盖原来目录
∙起服务
▪靠谱的单机部署抽象后就五步
∙1.下载新的版本,不执行覆盖;
∙3.运行命令load变更重启服务;
∙4.验证服务的健康状况;
∙5.通知上游调用方,自己服务恢复正常
∙2.通知上游调用方,自己现在为暂停服务状态;
o不可变对象
▪它就和Java中的不可变类完全相同:
类实例一旦创建,就无法变更,而可以变更的是指向实例的引用。
▪对任何的包、配置文件、软件应用和数据,都不做CRUD(创建、替换、更新、删除)操作。
▪对于已经存在的基础设施,不再在其上创造任何新的事物
∙1.构建一个新的基础设施;
∙2.测试新的基础设施是否符合需求;
∙3.将引用指向这个新的基础设施;
∙4.保留原有基础设施以备回滚。
▪不可变(Immutable)的前提是无状态。
▪容器技术解决的问题(仅仅通过发散和收敛是解决不了的)
∙顺序问题
∙频率问题
∙蝴蝶效应
▪Immutable的衍生
∙黄金映像,指的是将绝大部分不变的基础设施(包括操作系统、大多数软件、基本配置等),包含在映像内,只留很少一部分变更通过脚本执行解决
∙VDI(虚拟桌面),指的是操作系统运行在后端的服务器上,用户只使用属于他自己的虚拟桌面,无法改变后端的系统内容;
∙PhoenixServer,指的是完全被破坏的服务器,能够从灰烬中自动进行恢复;
∙基础设施即代码,指的是把基础设施的构建以代码的方式组织起来,从而通过运行代码可以完全构建出你想要的全部基础设施。
o用户体验角度落地发布系统
▪1张页面展示发布信息,且仅有1张页面,展示发布当时的绝大多数信息、数据和内容,这个页面既要全面,又要精准。
▪2个操作按钮简化使用,即页面上除了“回滚”按钮常在外,最多同时展示2个操作按钮。
目的是要降低发布系统的使用难度,做到“谁开发,谁运行”。
▪3种发布结果,即成功、失败和中断状态,目的是简单、明了地显示用户最关心的发布结果。
▪4类操作选择,包括开始发布、停止发布、发布回退、发布重试,目的是使状态机清晰明了。
▪5个发布步骤,即markdown、download、install、verify和markup。
这里需要注意到的是,verify这步包含了预热,由于耗时往往比较长,一般采用异步的处理方式。
∙单个实例的发布过程,分为5个步骤:
markdown:
为了减少应用发布时对用户的影响,所以在一个实例发布前,都会做拉出集群的操作,这样新的流量就不会再继续进入了。
download:
这就是根据版本号下载代码包的过程;install:
在这个过程中,会完成停止服务、替换代码、重启服务这些操作;verify:
除了必要的启动预检外,这一步还包括了预热过程;markup:
把实例拉回集群,重新接收流量和请求。
▪6大页面主要内容,包括集群、实例、发布日志、发布历史、发布批次、发布操作,来统一、简洁而又详细呈现发布中和未发布时的各种信息。
▪三个原则
∙信息直观,聚合
∙操作简单,直接
∙步骤与状态清晰
o发布系统架构
▪要求
∙清晰
∙健壮
∙低耦合
∙分布式、高可用、易扩展
▪注意点
∙每台服务实例上的发布脚本一旦产生则不再修改,以达到不可变模型的要求;
∙发布引擎和SaltMaster之间采用异步通信,但为增强系统健壮性,要有同步轮询的备案;
∙面对频繁的信息获取,要善用缓存,但同时也一定要慎用缓存,注意发布信息的新鲜度。
▪技术点
∙布系统的核心模型主要包括Group、DeploymentConfig、Deployment、DeploymentBatch,和DeploymentTarget这5项
∙携程之所以这样设计,是因为group这个对象直接表示一个应用的一组实例,这样既可以支持单机单应用的部署架构,也可以支持单机多应用的情况。
∙借助于Celery分布式任务队列的Chain函数,发布系统将上述的Markdown、Download、Install、Verify、Markup五个阶段定义为一个完整的链式任务工作流,保证一个Chain函数里的子任务会依次执行。
∙堡垒就是预发布实例,它就是生成集群的一个子集,但发布后,首先不接入外部正式流量,做自测用,自测通过后才接入生产流量
∙除堡垒批次外的每个发布批次均采用了QuickandDirty的发布方式,即不管成功或失败,优先尝试把版本发布完,继续执行下个发布批次,后续再解决个别目标服务器发布失败的问题。
∙刹车机制,即在每个批次开始发布任务前,系统会根据用户设置的单个批次可拉出上限比,进行失败率的计算与控制。
发布时,一旦达到这个失败率,立即中断当前发布,从而保护QuickandDirty发布方式
∙各个机房搭建了发布包专用的存储系统,实现了类似CDN的功能,编译和打包系统在任何一个写入点写入发布包,都会尽快同步到各个IDC及各个独立存储中,这样真正发布时,服务器只需从本IDC或本网段做下载。
∙降级机制可以保证发布系统做到,只有部署包存在,就能恢复服务。
∙子主题
∙点火
o我们借助于VI(ValidateInternal)框架中间件,实现了Verify过程的自动化,我们把这个过程形象地叫作“点火”。
▪优化
∙单机多应用IIS架构的弊端
o由于IIS的设计问题,不同虚拟目录之间可能存在共用应用程序池的情况,即多个应用运行在同一个进程下,导致任何一个应用的发布都可能对其他的关联应用造成影响。
o解决这个问题采用的方案是,去除根目录的被继承作用,默认每个虚拟目录就是一个应用,并且每个虚拟目录的应用程序池独立。
而每个虚拟目录以应用的名称命名,保证单机上不会发生冲突。
∙单机单应用的优势
o单机单应用不需要考虑分配服务端口的问题,所有的Web应用都可以使用同一个统一端口(比如,8080端口)对外服务
o单机单应用在故障排除、配置管理等方面同样具有很多优势。
一言以蔽之,简单的才是最好的
∙全量发布的优势
o增量发布对回滚非常不友好,你很难确定增量发布前的具体内容是什么。
如果你真的要确定这些具体内容的话,就要做全版本的差异记录,获取每个版本和其他版本间的差异,这是一个巨大的笛卡尔积,需要耗费大量的计算资源,简直就是得不偿失
o我的建议是,全量发布是互联网应用发布的最好方式。
∙使用标志位
o携程在设计系统时,用不同的标志位来标识发布系统、运维操作、健康检测,以及服务负责人对服务的Markup和Markdown状态。
4个标志位的任何一个为Markdown都代表暂停服务,只有所有标志位都是Markup时,服务中心才会向外暴露这个服务实例。
o解决多角色对服务markup和Markdown的冲突问题
o监控
▪对于生产环境,发布结束才是最危险的时刻
▪监控分类
∙用户侧监控
o访问速度和结果
∙网络监控
oCDN与核心网络
∙业务监控
o关注核心业务指标的波动
∙应用监控
o服务调用链
∙系统监控
o即基础设施、虚拟机及操作系统
▪用户侧监控
∙通过打点或者定期日志收集
∙端到端监控
o访问量
o访问成功率
o响应时间
o发包回包时间
o不同维度:
地区、运营商、App版本、返回码、网络类型等
∙移动端日志
∙设备表现监控
oCPU
o内存
o温度
o卡顿、白屏
o堆栈分析
∙唯一用户ID监控
▪网络监控
∙网络监控并不需要做到太细致和太深入,因为大多数网络问题最终也会表现为其他应用层面的故障问题。
但是,如果你的诉求是要快速定位rootcause,那就需要花费比较大的精力去做好网络监控了
∙公网
∙内网
▪监控无法处理的两种情况
∙累积效应,即系统异常需要累积到一定量后才会表现为业务异常;
∙业务的阴跌,这种小幅度的变化也无法在业务监控上得到体现。
▪三个重要问题
∙测试环境是否监控?
o测试环境的监控需要视作用而定,如果不能帮助分析和定位问题,则不需要很全面的监控;
∙发布后监控多久?
o一般发布后,我建议继续坚持监控30分钟,把这个流程纳入发布流程中;
∙如何确定异常是由发布引起的?
o完整的运维事件记录体系,可以帮你定位某次故障是否是由发布引起的。
∙07.测试管理
o代码静态检查
▪代码静态检查,即静态代码分析,是指不运行被测代码,仅通过分析或检查源程序的语法、结构、过程、接口等检查程序的正确性,并找出代码中隐藏的错误和缺陷(比如参数不匹配、有歧义的嵌套语句、错误的递归、非法计算、可能出现的空指针引用等等)。
▪在整个软件开发生命周期中,有70%左右的代码逻辑设计和编码缺陷属于重复性错误,完全可以通过静态代码分析发现和修复
▪SonarQube是一款目前比较流行的工具,国内很多互联网公司都选择用它来搭建静态检查的平台
o破坏性测试
▪注意
∙第一,破坏性测试的手段和过程,并不是无的放矢,它们是被严格设计和执行的。
不要把破坏性测试和探索性测试混为一谈。
∙第二,破坏性测试,会产生切实的破坏作用,你需要权衡破坏的量和度。
∙破坏性测试与普通测试流程,唯一不同的是,绝大部分普通测试可以在测试失败后,继续进行其他的测试;而破坏性测试,则有可能无法恢复到待测状态,只能停止后续的测试。
∙绝大部分破坏性测试都会在单元测试、功能测试阶段执行。
而执行测试的环境也往往是局部的测试子环境。
▪优点
∙破坏性测试还能很好地证明整个分布式系统的健壮性
▪定义
∙破坏性测试就是通过有效的测试手段,使软件应用程序出现奔溃或失败的情况,然后测试在这样的情况下,软件运行会产生什么结果,而这些结果又是否符合预期
▪混沌工程
∙混沌工程是在分布式系统上建立的实验,其目的是建立对系统承受混乱冲击能力的信心。
鉴于分布式系统固有的混乱属性,也就是说即使所有的部件都可以正常工作,但把它们结合后,你还是很难预知会发生什么。
∙通过一些受控实验,我们能够观察这些弱点在系统中的行为。
这种实验方法,就被叫作混沌工程。
∙案例
o混沌工程的一个典型实践是,Netflix公司的ChaosMonkey系统。
这个系统已经证明了混沌工程的价值和重要性,值得我们借鉴
oChaosMonkey会在工作日期间,随机地杀死一些服务以制造混乱,从而检验系统的稳定性。
而工程师们不得不停下手头工作去解决这些问题,并且保证它们不会再现。
久而久之,系统的健壮性就可以不断地被提高。
▪科学实验的四个必须步骤
∙科学实验都必须遵循的4个步骤:
将正常系统的一些正常行为的可测量数据定义为“稳定态”;建立一个对照组,并假设对照组和实验组都保持“稳定态”;引入真实世界的变量,如服务器崩溃、断网、磁盘损坏等等;尝试寻找对照组和实验组之间的差异,找出系统弱点。
“稳定态”越难被破坏,则说明系统越稳固;而发现的每一个弱点,则都是一个改进目标。
oMock与回放
▪Mock
∙如果某个对象在测试过程中依赖于另一个复杂对象,而这个复杂对象又很难被从测试过程中剥离出来,那么就可以利用Mock去模拟并代替这个复杂对象。
∙框架
o基于对象和类的Mock
▪适合模拟DAO层的数据操作和复杂逻辑,所以它们往往只能用于单元测试阶段
▪推荐Mockito、EasyMock
o基于微服务的Mock
▪到了集成测试阶段,你需要模拟一个外部依赖服务时,就需要基于微服务的Mock
▪推荐WeirMock、MockServer
▪回放
∙定义
o要做到和实际用户操作一致,最好的方法就是记录实际用户在生产环境的操作,然后在测试环境中回放
∙实现
o即先通过虚拟交换机,复制和记录生产用户的实际请求,在测试时“回放”这些真实操作,以达到更逼真地模拟用户行为的目的
∙08.持续交付平台化
o好处及原因
▪随着软件技术的发展,任何企业最终都将面临多技术栈的现实
▪随着持续交付业务的发展,团队会越来越庞大,分工也会越来越明细
▪随着持续交付技术本身的发展,还会不断引入新的工具,或新的流程方法
o初衷
▪互联网厂商平台化的玩法,往往是指自己搭台子,让其他人唱戏。
▪高可用、可扩展
o平台四大核心模块
▪四个模块是持续交付平台中最核心,最容易做到内聚和解耦的模块。
每个核心模块的周围,又围绕着各种子模块,比如:
代码管理模块,往往会和代码审核、静态扫描和分支管理等模块相联系;集成编译模块,也会与依赖管理、单元测试、加密打包等模块相生相随的;环境管理模块,离不开配置管理、路由管理等模块;发布部署模块,还需要监控模块和流控模块的支持。
o抽象公共服务
▪需要抽象的公共功能,主要包括:
账户与权限,包括单点登录,以及鉴权、授权体系等等;用户行为日志,即任何行动都要能够被追溯;消息通知,即提供统一的通知能力;安全与故障处理,即系统级的防护能力和故障降级。
o细节
▪标准先行
o云计算带来的变革
▪云计算的弹性能力,使得计算资源的提取成为持续交付过程的一个自然步骤。
▪云计算的Immutable,可以保证计算资源的生命周期与持续交付过程一致。
▪云计算本身不区分环境,这样可以获取到与生产环境几乎一样配置的资源。
o数据说话
▪如何衡量系统健康度
∙有的时候即使宕机了,特别是在夜间,因为没有用户使用,其实际影响几乎为0
∙宕机时间这个单一指标,不能全面地评价系统的稳定性
∙采用如下的实施方案:
首先,我们通过监控、保障、人为记录等手段,统计所有的故障时间。
需要统计的指标包括:
开始时间、结束时间和故障时长。
然后,计算过去三个月内这个时间段产生的持续交付平均业务量。
所谓业务量,就是这个时间段内,处理的代码提交、codereview;进行的编译、代码扫描、打包;测试部署;环境处理;测试执行和生产发布的数量。
最后,计算这个时间段内的业务量与月平均量相比的损失率。
这个损失率,就代表了系统的不稳定性率,反之就是稳定性率了。
▪注重长尾
∙看数据不仅要抓大势,也要关注细节,特别是异常细节。
∙大的故障和影响,往往都是出于一些非常愚蠢的失误。
▪常用衡量指标
∙稳定性
∙性能
o与性能相关的指标,我比较关注的有:
push和fetch代码的速度;环境创建和销毁的速度;产生仿真数据的速度;平均编译速度及排队时长;静态检查的速度;自动化测试的耗时;发布和回滚的速度。
∙成熟度
o与代码管理子系统相关的指标包括:
commit的数量,codereview的拒绝率,并行开发的分支数量。
o与环境管理子系统相关的指标包括:
计算资源的使用率,环境的平均大小。
o与集成编译子系统相关的指标包括:
每日编译数量,编译检查的数据。
o与测试管理子系统相关的指标包括:
单元测试的覆盖率,自动化测试的覆盖率。
o与发布管理子系统相关的指标包括:
周发布数量,回滚比率。
∙09.持续交付移动APP
o移动端交付和后端服务交付的不同点
▪对于移动App的持续交付来说,我们特别需要维护版本的相关信息,并对每个版本进行管理。
▪移动App和后端服务的持续交付体系,在构建管理上的不同点,主要体现在以下三个方面:
你需要准备Android和iOS两套构建环境,而且iOS的构建环境还需要一套独立的管理方案。
因为,iOS的构建环境,你不能直接使用Linux虚拟机处理,而是要采用Apple公司的专用设备。
在整个构建过程中,你还要考虑证书的管理,不同的版本或使用场景需要使用不同的证书。
如果证书比较多的话,还会涉及到管理的逻辑问题,很多组织都会选择自行开发证书管理服务。
为了解决组件依赖的问题,你需要特别准备独立的中央组件仓库,并用缓存等机制加快依赖组件下载的速度。
其实,这一点会和后端服务比较相像。
▪发布管理
∙首先,移动App无法做到强制更新,决定权在终端用户。
∙其次,移动App在正式发布到市场前,会进行时间比较长的内测或公测。
∙最后,移动App的分发渠道比较多样。
o移动App的持续交付体系的搭建完全可以借鉴服务端的持续交付的经验。
然后,再针对移动App固有的特点,进行改进和优化。
o移动APP交付流水线pipeline
▪发布快车模式
∙发布快车,就像一列由多节车厢组成的火车,每一节车厢代表一个发布版本,整个火车以一节节车厢或者说一个个版本的节奏,定期向前发车。
而工程师们,则会把自己开发完成的功能集成到一节节的车厢上,这样集成在一节车厢的功能代码,就形成了一个新的版本。
∙三个关键点
o第一个关键点是,并不是说所有开发的功能,都一定要集成到最近的那节车厢、最近的那个版本中。
o第二个关键点是,我们必须要保证固定间隔的发车时间,每周、每两周都可以,但必须保证每个车厢到点即发。
o第三个关键点是,这个过程的最终产物是可以发布到市场的版本,而不是发布到用户侧的版本。
∙代码分支策略
∙构建通道
o我们会在功能分支合并入Master分支前,增加一次构建(MergeCIService),这次构建的作用是保证功能分支的集成是成功的,否则不允许合并;同时,对于一个代码仓库来说,增加的这次构建过程要保证是串行的,即如果这个仓库正有一个合并构建在进行,则后续的合并构建需要等待。
o发布流程
▪iOS系统的发布步骤为:
构建,导出ipa包,记录符号表,备份,上传至iTC;Android系统的发布步骤为:
构建打包,更新渠道标识,签名,保存mapping文件,备份,上传至发布点。
o提升效率
▪提升效率最好的方法就是2个字:
解耦。
落到技术实现上来说,就是通过组件化形成合理的开发框架
▪实践经验:
利用组件化的思想提升开发效率,但同时也会带来组件依赖及发布的问题;利用扁平化依赖管理的方法解决组件依赖和发布的问题,同时采用二进制交付的方式,进一步提高构建效率;合理利用静态代码扫描、UI自动化、自动Monkey等测试工具和方法,进一步提升测试效率;确保分发的精准性和稳定性,是提升发布效率的有效手段。
∙01.持续交付体系概述
o要点
▪配置管理
▪环境管理
▪构建集成
▪测试管理
o趋势
▪“持续交付”必须以平台化的思想去看待,单点突破是无力的;
▪“持续交付”的实施,也要顺应技术的变迁,善于利用技术红利;
▪“持续交付”与系统架构、运维体系息息相关,已经不分彼此。
o误区
▪过度强调自动化
▪过度强调流程化
▪过度强调特殊化
o难点
▪事难做
▪人难找
▪效果难以度量
o目的
▪提高研发效率
∙02.基本概念
o持续集成
▪这个从编码到构建再到测试的反复持续过程,就叫作“持续集成”。
o持续交付
▪这个在“持续集成”之后,获取外部对软件的反馈再通过“持续集成”进行优化的过程就叫作“持续交付”,它是“持续集成”的自然延续。
▪“持续交付”是一个承上启下的过程,它使“持续集成”有了实际业务价值,形成了闭环,而又为将来达到“持续部署”的高级目标做好了铺垫。
▪从“持续部署”(自动化发布)开始推进“持续交付”,这才是一条优选的路径。
o持续部署
▪“持续部署”就是将可交付产品,快速且安全地交付用户使用的一套方法和系统,它是“持续交付”的最后“一公里”。
o价值
▪显性价值
∙在“最终用户”和“研发团队”之间建立紧密的反馈环:
通过持续交付新的软件版本,以验证新想法和软件改动的正确性,并衡量这些改动对软件价值的影响。
这里说的“软件价值”,说白了就是收入、日活、GMV等KPI指标了。
▪隐性价值
∙对于管理者
o技术选型
o标准落地
o协作效率
o黑天鹅防范
∙对于团队主管
o知识传递
o专注于业务
o持续工作
∙对于产品经理
o产品的第一个用户
o进度和质量
o随时发布
∙对于程序员
o加强对软件工程的认识
o工作效率和质量
o挑战和乐趣
o如何衡量绩效
▪将所有的“不可持续点”进行记录和分解,通过OKR的考评方式,将消灭这些点作为目标,拆解出来的可行动点,作为关键结果,以这样的方式来完成绩效考评。
o影响持续交付的因素
▪人(组织和文化)
∙第一个层次:
紧密配合,这是组织发展,部门合作的基础
∙第二个层次:
集思广益,这就需要组织内各个不同部门,或不同职能的角色,跳出自身的“舒适区”
∙第三个层次:
自我驱动,是理想中的完美组织形式
∙软件企业与交付有关的研发部门包括四个:
产品、开发、测试和运维。
而这四个部门天然地形成了一个生产流水线
∙如何解决组织问题
o成立项目管理办公室(ProjectManageOffice,简称PMO)这样的监督型组织,帮助持续交付落地;
o独立建立工程效能部门,全面负责包括持续交付在内的研发效率提升工作;
o使用敏捷形式,如Scrum,打破职能部门间的“隔离墙”,以产品的形式组织团队,各团队自行推进持续交付。
∙文化先行是前提
▪事(流程)
∙耗时长的流程
∙完全人工的流程
∙信息报备类的流程
o持续交付过程中同样会产生各种信息流,这些信息有些需要广播,有些需要定点传递。
实施持续交付后,这些信息报备类的流程一定会通过异步消息等方式进行改造。
▪物(架构)
∙系统架构
o单体架构
oSOA架构
▪总体来说,SOA架构要做到持续交付比单体架构要难得多。
但也
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 极客时间持续交付36讲 学习笔记 时间 持续 交付 36 学习 笔记