高可用服务变更的最佳实践
焦振清
讲述：丁婵大小：1.71M时长：03:44
在上一篇文章中，我列出了服务变更需要注意的几个关键点。本文以蓝绿部署为基础，介绍服务变更的最佳实践，以下为具体内容。
如上图所示：将系统按照 AZ 的维度，独立部署了 4 组，分别是 AZ1、AZ2、AZ3 和 AZ4，这四组完全一致，基于隔离的思路，四个分组间，尽量避免了服务间的交互和基础设施共享。
考虑到线上环境的复杂度，以及天然存在一定的冗余度，因此每次仅升级一个 AZ 分组。在第一个分组 AZ1 的时候，会进行较为详细的验证，除去常规的自动化检查外，还会有测试人员的手工效果检查，以此确保变更的质量。其余 AZ 因为变更内容一致，因此不会有测试人员的接入，仅保留自动化检查。
如果变更存在问题，因选择的 AZ1 是明确小于冗余度的，因此仅需要摘除流量后，再进行回滚，部分时候，如果研发要求短暂保留现场，也可以满足其要求。
再说说部署系统，应该将变更的关键点内嵌到部署系统中，不断完善，让其成为变更流程无法逾越的环节，从而更好的保证变更质量。一个部署系统在做好单机部署工作的同时，也应该满足如下业务侧的需求：
提供部署清单功能，并具备自动化的检查能力，阶段性进展通告的能力；
提供版本管理功能，常规变更（二进制代码和配置）必须全部基于版本库进行；
提供快速回滚功能，能够帮助业务快速回滚到上一个稳定版本，并能够按照业务上下游编排顺序进行回滚；
提供时间窗口功能，默认不能够在业务定义的黑名单时间点上线；
提供备份功能，每次变更都需要将可能影响到的内容进行单机备份，便于快速回滚，默认是需要将上次的发布包进行全量备份尽量排除掉日志；
提供灰度发布功能，能够定义分组间和分组内的并发度，分组变更的暂停时长等；
提供效果检查功能，自动化的对业务进行预定义的各类检查并和部署动作联动，如暂停变更，继续变更以及调整灰度的比例；
提供编排功能，满足多模块的联合上线。
另外，在配置变更中，常见的错误有两点，其一是配置文件错误。在配置变更的过程中，因配置文件错误，导致服务不可用，进而导致全局的服务故障，可能的原因有配置文件被截断，配置文件合法性校验缺失导致配置错误进程无法启动，常见的故障有：
Nginx 配置文件错误导致网站整体不可用；
DNS 配置文件错误导致网站整体不可用；
基础服务如数据库的授权白名单被清空导致多个业务服务异常。
其二是规则冲突。在规则变更的过程中，基于不同业务的规则生效顺序不同，新增规则后可能会和原来的一些规则冲突，进而导致业务的异常，常见的场景比如 Iptables 规则，在现有的 100 条规则中新增 1 条；Nginx 的规则，基于正则匹配的方式进行域名规则的处理。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论