20 | 做持续交付概念重要还是场景重要？看“笨办法”如何找到最佳方案
赵成
该思维导图由 AI 生成，仅供参考
上期文章中我们讲到，在经过严格的依赖规则校验和安全审计之后，构建出的软件包才可以部署发布。
在开发环境、项目环境、集成测试环境以及预发环境下，我们还要进行各类的功能和非功能性测试，最后才能发布到正式的生产环境之上。
通常状况下，做一次软件版本发布，必须经过以下几个环境（如下图所示）。需要明确的是，项目环境和“小蘑菇”（内部叫法）环境，只有特殊版本才会配备，这里我们不做强制。
上述这些环境我们在之前都介绍过。而历经如此多的环境，高效的自动化持续部署和发布就变得尤为重要。
特别是最后的线上发布环节，还需要确保业务连续稳定、无间断，所以，在复杂的微服务架构环境下，我们对软件的发布策略选择、自动化程度和稳定性要求就更高了。
今天，我们一起看看整个流水线软件部署和发布的细节。
软件的持续部署发布
这里，我们直接以生产环境的发布过程来讲解。软件的部署发布，简单来说就是：
将构建完成和验证通过的应用软件包，发布到该应用对应环境下的 IP 主机上的指定目录下，并通过应用优雅上下线，来实现软件最新版本对外提供服务的过程。
这个过程会包含的环节，我以图示整理如下：
我们可以看到，软件部署发布，听上去就是把软件部署一下，然后启动起来。这样的操作方式对于单体架构软件没有问题，但是在微服务架构下就满足不了要求了。
单体架构软件启动起来就可以提供服务，但是对于微服务应用，无论停止还是启动，都需要考虑到对周边其它依赖和被依赖应用的影响才可以，考虑的点也就相对较多。
我们针对单机发布，分环节来看一下：
1. 从 CMDB 中，拿到线上生产环境下的应用主机 IP 列表去对应关系，目的是要将软件包发布到应用对应的 IP 主机上。
2. 检查每台机器上的服务是否正常运行，如果是正常服务的，说明可以发布，但是服务本身异常，就要记录或跳过。
3. 下载 war 包到指定目录。这里要依赖前期我们介绍的应用配置管理，在这一步要获取到该应用的源代码目录。
4. 关闭该应用在这台主机上的监控，以免服务下线和应用终止产生线上错误告警。
5. 优雅下线。RPC 服务从软负载下线，如果该应用还提供了 http 的 Web 调用，就需要从 Nginx 这样的七层负载下线，下线动作均通过 API 接口调用方式实现。
6. 下线后经过短暂静默，重启应用。对于 Java 应用来说，重启时可以自动解压，启停命令等还是之前从应用配置管理中获取响应路径和命令脚本名称。
7. 优雅上线，进行健康监测，检查进程和应用状态是否正常，如果全部监测通过，则开始上线服务，开启监控。
上述是一个应用的单机发布过程，过程比较长，但是可以看出，每个环节并不复杂。这里我们需要注意两个关键点：
针对场景，进行细分，这样就可以化整为零，把一个乍看上去很复杂的过程，分解成一个个可执行的步骤。
与服务化的软负载和注册中心进行交互，确保应用是可以优雅上下线的，而不是简单粗暴地启动和停止。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
“持续交付概念重要还是场景重要？”一文深入探讨了软件持续部署和发布的重要性，以及在微服务架构环境下的挑战和解决方案。文章首先介绍了软件的持续部署发布过程，强调了在微服务架构下，对于软件发布策略选择、自动化程度和稳定性的高要求。接着详细分析了灰度发布和滚动发布的组合方式，并阐述了它们在实际应用中的优势和稳定性。此外，文章还探讨了持续交付体系的收益，强调了整个流水线过程的自助发布，达到了DevOps或NoOps的效果。最后，作者强调了从实际问题和业务场景出发来考虑解决方案的重要性，鼓励读者采取“笨办法”：找到问题，分析问题，调研解决方案，讨论碰撞，然后慢慢摸索和实践，找出最合适的方式。整体而言，本文通过深入的技术分析和实践经验分享，为读者提供了对持续交付概念和实践的全面了解，强调了在实际业务场景中寻找解决方案的重要性。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《赵成的运维体系管理课》，新⼈⾸单¥59
《赵成的运维体系管理课》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(5)
- 最新
- 精选
Tom我也想做一套持续交付的系统，像阿里云的云效，但感觉系统很庞大，开发难度大，有什么建议吗？作者回复: 云效是比较完备的一套持续交付体系，可以好好借鉴下，建议分步实施，先理清楚每个环节。 当然，有条件用云上产品的话，建议直接用
2018-03-074- Geek_5baa01老师，有什么推荐的 CI/CD Tools ?
作者回复: 很多的，这里不做产品推广了，有心总可以找到的
2021-09-28 
τ在版本发布中遇到失败一般会采用回滚，可是新发布的版本涉及到了数据表结果已经部分字段的数据初始化，回滚的时候也需要相应的反向操作。在这一点上一般你们会用flyway这样的数据迁移工具嘛？还是会采用别的方式来对待回滚操作？另外在多版本（小版本）兼容的情况下的发布操作流程会有什么细节上的变化嘛？2018-05-036
yungoo发布/回滚过程中的DB schema变更怎么自动化？2020-06-292
飞翔数据库表变更也是自动化的吗，是怎么做的，这块应该注意哪些问题2020-05-31
收起评论
