极客时间持续交付36讲学习笔记.docx
- 文档编号:5294943
- 上传时间:2022-12-15
- 格式:DOCX
- 页数:28
- 大小:216.87KB
极客时间持续交付36讲学习笔记.docx
《极客时间持续交付36讲学习笔记.docx》由会员分享,可在线阅读,更多相关《极客时间持续交付36讲学习笔记.docx(28页珍藏版)》请在冰豆网上搜索。
极客时间持续交付36讲学习笔记
极客时间・《持续交付36讲》学习笔记
•06•发布及监控
O最后一公里
・部署和发布是有区别的,前者是一个技术范鋳,而后者则是一种业务决策
・应用被部署,并不代表就是发布了
O定义
・从英文上来看,我们通常既不用deploy这个词,也不用release这个词,而是使用rollout这个词
・发布是一个慢慢滚动向前、逐步生效的过程
・我们想要的应该是:
一个易用、快速、稳定、容错力强,必要时有能力迅速回滚的发布系统
O灰度发布的方式
・灰度发布是扌旨,渐进式地更新每台机器运行的版本,—段时期内集群内运行着多个不同的版本,同一个API在不同机器上返回的结果很可能不同。
・集群层面的设计,某种程度上聖寸单机部署理念的重复,只不过是在更高的维度上又实现了一遍
・蓝绿发布
•蓝绿发布,是先增加一套新的集群,发布新版本到这批新机器,并进行验证,新版本服务器并不接入外部流呈。
此时旧版本集群保持原有状态,发布和验证过程中老版本所在的服务器仍照常服勢。
验证通过后,流控处理把流星引入新服务器,待全部流星切换完成,等待一段时间没有异常的话,老版本服务器下线。
•好处是所有服务都使用这种方式时,实际上创造了蓝绿两套环境,隔离性最好、最可控,回滚切换几乎没有成本
•2011年出版的《持续交付:
发布可靠软件的系统方法》一书中,就曾
提到"蓝绿发布"的概念:
你需要更新一组实例,但并不是直接在原有实例上逬行变更,而是重新启动一批对等的实例,在新实例上更新,然后再用新实例替换老实例。
此时老实例仍旧存在,以便回滚。
・滚动发布
•滚动发布,是不添加新机器,从同样的集群服勢器中挑选一批,停止上面的服勢,并更新为新版本,进行验证,验证完毕后接入流星。
重复此步骤,—批一批地更新集群内的所有机器,直到遍历完所有机器。
•比蓝绿发布节省资源,但发布过程中同时会有两个版本对外提供服务,无论是对自身或是调用者都有较高的兼容性要求,需要团队间的合作妥协
・金丝雀发布
•金丝雀发布,从集群中料罐特走服务器或一小批符合要求的特征用户,对其进行版本更新及验证,随后逐步更新剩余服务器。
这种方
式,比较符合携程对灰度发布的预期”但可能需要精细的流控和娄的支持,同样有版本兼容的需求。
・高度抽象后其实就三步
•停服务
•覆盖原来目录
•起服务
■靠谱的单机部署抽象后就五步
•1.下载新的版本,不执行覆盖;
•3.运行命令load变更重启服务;
•4•验证服勢的健康状况;
•5•通知上游调用方,自己服务恢复正常
•2•通知上游调用方,自己现在为暂停服务状态;
o不可变又竣
・它就和Java中的不可变类完全相同:
类实例一旦创建,就无法变更,而可以
变更的是指向实例的引用。
・对但可的包、配置文件、软件应用和数据,都不做CRUD(创建、替换、更
新、删除)操作。
・对于已经存在的斟出设施,不再在其上创造任何新的事物
•1•构建一个新的基础设施;
•2•测试新的基I出设施是否符合需求;
•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由于ns的设计问题,不同虚拟目录之间可能存在共用应用程序池的情况,即多个应用运行在同一个进程下,导致任何一个应用的发布都可能对其他的关联应用造成影响。
o解决这个问题采用的方案是,去除根目录的被继承作用,默认每个虔拟目录就是一个应用,并且每个虚拟目录的应用程序池独立。
而每个虚拟目录以应用的名称命名,保证单机上不会发生冲突。
单机单应用的优势
O单机单应用不需要考虑分配服务端口的问题,所有的Web应用都可以使用同一个统一端口(比如,8080端口)对外服勢
o单机单应用在故障排除、配置管理等方面同样具有很多优势。
—言以籲之,简单的才是最好的
全星发布的优势
o增星发布对回滚非常不友好,你很难确走增臺发布前的具体内容是什么。
如果你真的要确走这些具体内容的话,就要做全版本的差异记录,获取每个版本和其他版本间的差异,这是一个巨大的笛卡尔积,需要耗费大呈的计算资源,简直就是得不偿失
O我的建议是,全星发布是互联网应用发布的最好方式。
使用标志位
O携程在设计系统时,用不同的标志位来标识发布系统、运维操作、健康检测,以及服务负责人对服勢的Markup和
Markdown状态。
4个标志位的任何一个为Markdown都代表暂停服勢,只有所有标志位都是Markup时,服务中心才会向外暴露这个服勢实例。
O解决多角色对服勢markup和Markdown的冲突问题
对于生产环境,发布结束才是最危险的时刻
监控分类
•用户侧监控
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平台四大核心模块
・四个模块是持续交付平台中最核心,最容易做到内聚和解耦的模块。
每个核心模块的周围,又围绕着各种子模块,t匕如:
代码管理模块,往往会和代码审核、静态扫描和分支管理等模块相联系;集成编译模块,也会与依赖管理、单元测试、加密打包等模块相生相随的;环境管理模块,离不开配置管理、路由管理等模块;发布部署模块,还需要监控模块和流控模块的支持。
O抽象公共服务
・需要抽象的公共功能,主要包括:
账户与权限,包括单点登录,以及鉴权、授权体系等等;用户行为日志,即任]可行动都要能够被追溯;消息通知,即提供统一的通知能力;安全与故障处理,即系统级的防护能力和故瞳降级。
O细节
・标准先行
O云计算带来的变革
・云计算的弹性能力,使得计算资源的提取成为持续交付过程的一个自然步骤。
・云计算的Immutable,可以保证计算资源的生命周期与持续交付过程一致。
・云计算本身不区分环境,这样可以获取与生产环境几乎一样配置的资源。
o缠说话
■如何衡呈系统健康度
•有的时候即使宕机了,特别是在夜间,因为没有用户使用,其实际影响几乎为0
•宕机时间这个单一指标,不能全面地评价系统的稳走性
•采用如下的实施方案:
首先,我们通过监控、保障、人为记录等手
间和故障时长。
然后,计算过去三个月内这个时间段产生的持续交付平均业务星。
所谓业务星,就是这个时间段内,处理的代码提交、
codereview;进行的编译、代码扫描、打包;测试部署;环境处理;测试执行和生产发布的数星。
最后,计算这个时间段内的业务臺与月平均呈相比的损失率。
这个损失率,就代表了系统的不稳走性率,反之就是稳创生率了。
・注重长尾
•看数据不仅要抓大势,也要关注细节,特别是异常细节。
•大的故障和影响,往往都是岀于一些非常愚蠢的失误。
-常用衡星指标
•稳走性
•性能
O与性能相关的扌颤,我匕傲关注的有:
push和fetch代码的速度;环境创建和销毁的速度;产生仿真数据的速度;平均编译速度及排队时长;静态检查的速度;自动化测试的耗时;发布和回滚的速度。
•成熟度
o与代码管理子系统相关的指标包括:
commit的数星,codereview的拒绝率,并行开发的分支数星。
O与环境管理子系统相关的指标包括:
计算资源的使用率,环境的平均大小。
O与集成编译子系统相关的指标包括:
每日编译数呈,编译检查的数据。
O与测试管理子系统相关的指标包括:
单元测试的覆盖率,自动化测试的覆盖率。
O与发布管理子系统相关的指标包括:
周发布数星,回滚t匕率。
•09.持续交付移动4PP
O移动端交付和后端服务交付的不同点
・对于移动App的持续交付来说,我们特别需要维护版本的相关信息,并对每个版本进行管理。
・移动App和后端服务的持续交付体系,在构建管理上的不同点,主要体现在以下三个方面:
你需要准备Android和iOS两套构建环境,而且iOS的构建坏境还需要一套独立的管理方案。
因为,iOS的构建环境,你不能直接使用Linux菌以机处理,而是要采用Apple公司的专用设备。
在整个构建过程中,你还要考虑证书的管理,不同的版本或使用场景需要使用不同的证书。
如果证书比较多的话,还会涉及到管理的逻辑问题,很多组织都会选择自行开发证书管理服勢。
为了解决组件依赖的问题,你需要持别准备独立的中央组件仓库,并用缓存等机制加快依赖组件下载的速度。
其实,这一点会和后端服务I:
匕较相像。
・发布管理
•首先,移动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独立建立工程效能部门,全面负责包括持续交付在内的硏发效
率提升工作;
使用
壬形式,如Scrumr打破职能部门间的〃隔离墙"
产品的形式组织团队,各团队自行推进持续交付0
•文化先行是前提
■事(流程)
•耗时长的流程
•完全人工的流程•信息报备类的流程
O持续交付过程中同样会产生各种信息流,这些信息有些需要广播,有些需要走点传递。
实施持续交付后,这些信息报备类的流程一走会通过异步i
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 时间 持续 交付 36 学习 笔记