大型网站架构：无损发布

大型网站架构：无损发布

2015-07-06

1. 背景

因为发布系统，导致应用可用性跌到 99.99 以下，细节参考：Nginx 上收集的系统可用性损失记录，借此机会，寻求应用无损发布的解决方案。

备注：

通过比对「系统发布时间」和「系统可用性降低」时 Nginx 的访问日志，2 个时间相吻合，因此，确定系统发布过程中，应用不可用，损失可用性。

2. 分析

之前可用性文章中，提到了无损发布的基本思路：

1. 准备发布的服务器，Nginx 上，切掉流量
2. 服务器，发布系统
3. 检查系统存活状态
4. Nginx 上，重新开启流量

转存失败重新上传取消

对于 Nginx 服务器，如何切掉流量？如何切回流量？

1. 通过调整 Nginx 配置，切掉服务器流量
2. 通过调整 Nginx 配置，切回服务器流量

Note:

Nginx 提供 fallback 机制， 通过配置 http status code，将失败的流量，在 fallback 机器上重试，能够解决系统发布时的流量损失。

2.1. 思路 A：手动触发，切换流量

手动触发，切换流量：以发布系统为主，通过配置发布脚本，修改 Nginx 配置。

1. 发布系统动作触发时，程序自动切掉服务器流量
2. 服务器上，系统发布成功后，切回流量

优点：

• 手动触发，控制简单
• Nginx 上业务侵入弱

缺点：

• 发布脚本需要修改 Nginx 配置，进行流量切换

2.2. 思路 B：自动监测，切换流量

自动监测，切换流量：以 Nginx 服务器为主，需要其知道各个应用服务器健康检查的 url，以此判断服务器存活状态，并修改 Nginx 配置。

1. Nginx 自动监测所有服务器的存活状态，当服务器无响应时，自动切掉服务器流量
2. Nginx 自动监测已经失去连接的服务器存活状态，当服务器重新响应时，再自动切回服务器流量

优点：

• 可以约定默认的应用健康检查 url
• 不需要应用服务器感知无损发布的处理细节

缺点：

• 自动监测，需要监测服务器上应用的存活状态，统一所有应用服务器的健康检查 url，对 Nginx 服务器侵入较高

3. 参考资料

1. 如何实现程序的100无损发

附录

Nginx 的 fallback 机制，提升系统可用性：

1. 502 504 负载过高或者正在发布系统
2. Nginx 动态修改 upstream，有单独的 Nginx 模块，需要开启。