DJANGO uWSGI服务实现优雅重启(graceful reload)的方式

背景文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/37983.html

线上主api服务使用的是uWSGI+Django框架，循历史传承一直是通过svc守护进程运行，每次重启无外乎通过svc -k / svc -i 通知server实现重启，本质上就是通过向server发送SIGKILL/SIGINT信号实现结束旧进程，而后守护进程重新拉起新进程运行。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/37983.html

问题文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/37983.html

此种重启方式每次都会导致重启时刻一小段时间(数秒--数十秒)线上server的不可用，这直接导致两个异常来源：1，旧进程直接被kill，当前正在处理未完成的请求流程也直接中断；2，旧server被kill掉，新server启动初始化ready前，完全无法处理任何新请求，直接体现为大量的niginx502响应。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/37983.html

针对异常1，由于SIGKILL信号直接杀死进程，所以不可避免，但是对于SIGINT信号，通过增加信号处理函数，理论上可以等server处理完全部未完成请求后再结束自身，但在收到SIGINT信号后，不应该再接收新的请求，此种方式不可能解决异常2的问题。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/37983.html

针对异常2，要解决出现server重启准备期间无法响应新请求的问题，只能提前将打向重启节点的流量先屏蔽掉，server重启ready后再恢复流量，通过提前一定时间屏蔽流量，等待历史请求处理完成后再重启，还可以解决掉异常1的问题。这算是保持多进程服务高可用的一种典型思路，难点在于需要能够自动化这一流程，即：a, nginx屏蔽node流量；b,一定时间后重启node服务；c，重启ready后恢复node流量。对于使用一体化分布式框架，已经打通流量控制、节点重启平台功能的大公司，这个不失为一种选择，但对于小公司来说，自动化难度较大，而如果手动操作则不但繁琐，而且很容易出错，节点增多后更是难以接受的labor work。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/37983.html

uWSGI优雅重启文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/37983.html

在网上搜寻有无更好的uWSGI优雅重启方案，找到了uWSGI官方文档：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/37983.html

优雅重载的艺术 — uWSGI 2.0 文档文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/37983.html

The Art of Graceful Reloading文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/37983.html

其中提到了数种reload的方案，简单总结如下：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/37983.html

<uwsgi>
    <socket>0.0.0.0:3000</socket>
    <listen>14400</listen>
    <master>true</master>
    <processes>4</processes>
    <threads>12</threads>
    <module>wsgi</module>
    <profiler>true</profiler>
    <memory-report>true</memory-report>
    <limit-as>6048</limit-as>
    <buffer-size>65536</buffer-size>
    <thunder-lock>true</thunder-lock>
    <harakiri>30</harakiri>
    <lazy-apps>true</lazy-apps>
</uwsgi>

<uwsgi>
    <socket>0.0.0.0:3000</socket>
    <listen>14400</listen>
    <master>true</master>
    <master-fifo>/tmp/uwsgi_api.fifo</master-fifo>
    <processes>4</processes>
    <threads>12</threads>
    <module>wsgi</module>
    <profiler>true</profiler>
    <memory-report>true</memory-report>
    <limit-as>6048</limit-as>
    <buffer-size>65536</buffer-size>
    <thunder-lock>true</thunder-lock>
    <harakiri>30</harakiri>
    <lazy-apps>true</lazy-apps>
</uwsgi>