大型网站架构：无损发布
2015-07-06
1. 背景
因为发布系统，导致应用可用性跌到 99.99 以下，细节参考：Nginx 上收集的系统可用性损失记录，借此机会，寻求应用无损发布的解决方案。
备注：
通过比对「系统发布时间」和「系统可用性降低」时 Nginx 的访问日志，2 个时间相吻合，因此，确定系统发布过程中，应用不可用，损失可用性。
2. 分析
之前可用性文章中，提到了无损发布的基本思路：
- 准备发布的服务器，Nginx 上，切掉流量
- 服务器，发布系统
- 检查系统存活状态
- Nginx 上，重新开启流量
对于 Nginx 服务器，如何切掉流量？如何切回流量？
- 通过
调整 Nginx 配置，切掉服务器流量 - 通过
调整 Nginx 配置，切回服务器流量
Note:
Nginx 提供 fallback 机制， 通过配置 http status code，将失败的流量，在 fallback 机器上重试，能够解决系统发布时的流量损失。
2.1. 思路 A：手动触发，切换流量
手动触发，切换流量：以发布系统为主，通过配置发布脚本，修改 Nginx 配置。
- 发布系统动作触发时，程序自动切掉服务器流量
- 服务器上，系统发布成功后，切回流量
优点：
- 手动触发，控制简单
- Nginx 上业务侵入弱
缺点：
- 发布脚本需要修改 Nginx 配置，进行流量切换
2.2. 思路 B：自动监测，切换流量
自动监测，切换流量：以 Nginx 服务器为主，需要其知道各个应用服务器健康检查的 url，以此判断服务器存活状态，并修改 Nginx 配置。
- Nginx 自动监测所有服务器的存活状态，当服务器无响应时，自动切掉服务器流量
- Nginx 自动监测已经失去连接的服务器存活状态，当服务器重新响应时，再自动切回服务器流量
优点：
- 可以约定默认的应用健康检查 url
- 不需要应用服务器感知无损发布的处理细节
缺点：
- 自动监测，需要监测服务器上应用的存活状态，统一所有应用服务器的健康检查 url，对 Nginx 服务器侵入较高
3. 参考资料
附录
Nginx 的 fallback 机制，提升系统可用性：
- 502 504 负载过高或者正在发布系统
- Nginx 动态修改 upstream，有单独的 Nginx 模块，需要开启。
原文地址：https://ningg.top/large-scale-web-app-tech-4/