极客时间持续交付36讲 学习笔记.docx

极客时间持续交付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架构要做到持续交付比单体架构要难得多。

但也