服务变更如何做到高可用？

任何的变更，都需要事前进行通告，告知相关的上下游团队，变更时间，变更内容，可能的影响，应急联系人等，并在变更期间的各个阶段，进行通告。同时，也应该将变更信息录入到统一的系统中，便于相关上下游订阅。

本文以蓝绿部署为基础，介绍服务变更的优秀实践

截图简要说明：将系统按照 AZ 的维度，独立部署了 4 组，分别是 AZ1、AZ2、Z3 和 AZ4，这四组完全一致，基于隔离的思路，四个分组间，尽量避免了服务间的交互和基础设施共享。

考虑到线上环境的复杂度，以及天然存在一定的冗余度，因此每次仅升级一个 AZ 分组。在第一个分组 AZ1 的时候，会进行较为详细的验证，除去常规的自动化检查外，还会有测试人员的手工效果检查，以此确保变更的质量。其余 AZ 因为变更内容一致，因此不会有测试人员的接入，仅保留自动化检查。

如果变更存在问题，因选择的 AZ1 是明确小于冗余度的，因此仅需要摘除流量后，再进行回滚，部分时候，如果研发要求短暂保留现场，也可以满足其要求。

部署系统应该将变更的关键点内嵌到部署系统中，不断完善，让其成为变更流程无法逾越的环节，从而更好的保证变更质量。一个部署系统在做好单机部署工作的同时，也应该满足如下业务侧的需求：

• 提供部署清单功能，并具备自动化的检查能力，阶段性进展通告的能力
• 提供版本管理功能，常规变更（二进制代码和配置）必须全部基于版本库进行
• 提供快速回滚功能，能够帮助业务快速回滚到上一个稳定版本，并能够按照业务上下游编排顺序进行回滚
• 提供时间窗口功能，默认不能够在业务定义的黑名单时间点上线
• 提供备份功能，每次变更都需要将可能影响到的内容进行单机备份，便于快速回滚，默认是需要将上次的发布包进行全量备份尽量排除掉日志
• 提供灰度发布功能，能够定义分组间和分组内的并发度，分组变更的暂停时长等
• 提供效果检查功能，自动化的对业务进行预定义的各类检查并和部署动作联动，如暂停变更，继续变更以及调整灰度的比例
• 提供编排功能，满足多模块的联合上线

在配置变更的过程中，因配置文件错误，导致服务不可用，进而导致全局的服务故障，可能的原因有配置文件被截断，配置文件合法性校验缺失导致配置错误进程无法启动，常见的故障：

• Nginx 配置文件错误导致网站整体不可用
• DNS 配置文件错误导致网站整体不可用
• 基础服务如数据库的授权白名单被清空导致多个业务服务异常

在规则变更的过程中，基于不同业务的规则生效顺序不同，新增规则后可能会和原来的一些规则冲突，进而导致业务的异常，常见的场景：

• Iptables 规则，在现有的 100 条规则中新增 1 条
• Nginx 的规则，基于正则匹配的方式进行域名规则的处理

【编辑推荐】

1. 工信部废止《关于组织开展计算机技术与软件专业技术资格（水平）证书登记工作的通知》部分文件
2. 担心被AI换脸技术祸害？别怕！Deepfake打假队正在赶来
3. 妹子一个rm -rf把公司服务器数据删没了_技术栈微信半月刊第46期
4. 阿里、拼多多面试分享：已获技术专家Offer
5. 2019年上半年企业IT技术在线学习报告

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!