极客时间-《持续交付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（虚拟桌面），指的是操作系统运行在后端的服务器上，用户只使用属于他自己的虚拟桌面，无法改变后端的系统内容；
•Phoenix Server，指的是完全被破坏的服务器，能够从灰烬中自动进行恢复；
•基础设施即代码，指的是把基础设施的构建以代码的方式组织起来，从而通过运行代码可以完全构建
出你想要的全部基础设施。
o用户体验角度落地发布系统
▪  1 张页面展示发布信息，且仅有 1 张页面，展示发布当时的绝大多数信息、数据和内容，这个页面既要全面，又要精准。
▪  2 个操作按钮简化使用，即页面上除了“回滚”按钮常在外，最多同时展示 2 个操作按钮。目的是要降低发布系统的使用难度，做到“谁开发，谁运行”。
▪  3 种发布结果，即成功、失败和中断状态，目的是简单、明了地显示用户最关心的发布结果。
▪  4 类操作选择，包括开始发布、停止发布、发布回退、发布重试，目的是使状态机清晰明了。
▪  5 个发布步骤，即 markdown、download、install、verify 和 markup。这里需要注意到的是，verify 这步包含了预热，由于耗时往往比较长，一般采用
异步的处理方式。
•单个实例的发布过程，分为 5 个步骤：markdown：为了减少应用发布时对用户的影响，所以在一个实例发布前，都会做拉出集的操
作，这样新的流量就不会再继续进入了。download：这就是根据版本
号下载代码包的过程；install：在这个过程中，会完成停止服务、替换
代码、重启服务这些操作；verify：除了必要的启动预检外，这一步还
包括了预热过程；markup：把实例拉回集，重新接收流量和请求。
▪  6 大页面主要内容，包括集、实例、发布日志、发布历史、发布批次、发布操作，来统一、简洁而又详细呈现发布中和未发布时的各种信息。
▪三个原则
•信息直观，聚合
•操作简单，直接
•步骤与状态清晰
o发布系统架构
▪要求
•清晰
•健壮
•低耦合
•分布式、高可用、易扩展
▪注意点
•每台服务实例上的发布脚本一旦产生则不再修改，以达到不可变模型的要求；
•发布引擎和 Salt Master 之间采用异步通信，但为增强系统健壮性，要有同步轮询的备案；
•面对频繁的信息获取，要善用缓存，但同时也一定要慎用缓存，注意发布信息的新鲜度。
▪技术点
•布系统的核心模型主要包括 Group、DeploymentConfig、
Deployment、DeploymentBatch，和 DeploymentTarget 这 5 项•携程之所以这样设计，是因为 group 这个对象直接表示一个应用的一组实例，这样既可以支持单机单应用的部署架构，也可以支持单机多
应用的情况。
•借助于 Celery 分布式任务队列的 Chain 函数，发布系统将上述的Markdown、Download、Install、Verify、Markup 五个阶段定义为
一个完整的链式任务工作流，保证一个 Chain 函数里的子任务会依次
执行。
•堡垒就是预发布实例，它就是生成集的一个子集，但发布后，首先不接入外部正式流量，做自测用，自测通过后才接入生产流量•除堡垒批次外的每个发布批次均采用了 Quick and Dirty 的发布方式，即不管成功或失败，优先尝试把版本发布完，继续执行下个发布
批次，后续再解决个别目标服务器发布失败的问题。
•刹车机制，即在每个批次开始发布任务前，系统会根据用户设置的单个批次可拉出上限比，进行失败率的计算与控制。发布时，一旦达到
这个失败率，立即中断当前发布，从而保护 Quick and Dirty 发布方
式
•各个机房搭建了发布包专用的存储系统，实现了类似 CDN 的功能，编译和打包系统在任何一个写入点写入发布包，都会尽快同步到各个
IDC 及各个独立存储中，这样真正发布时，服务器只需从本 IDC 或本
网段做下载。
•降级机制可以保证发布系统做到，只有部署包存在，就能恢复服务。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。