FastAPI、Docker负载均衡部署

写在春节前，这次的活动并发量之大超过我之前开发的所有项目。

先说背景

部署机器：腾讯云8c16g 数据库：腾讯云4c8g 每秒的请求大概是300次~500次左右（主要是读、写、查），在晚上高峰期大约会到800次左右的峰值 fastapi还部署了后台定时任务，会在后台对新增数据计算向量，做人工推荐

线上结果

上线雪崩，这里的崩有2个方面，我分别说一下。 1、对数据表层面的优化严重不够，导致太多的查询没有走在索引上；(对查询的限制不够严格，造成tortoise-orm里面大量的.all()未做限定等，造成查询后期严重雪崩) 2、docker-compose 做编排的时候，nginx没有在开始做负载均衡，造成单容器打满，无法横向扩展； 简单总结就是之前的“玩具代码”写多了，真正深入到业务的时候，敏感度变低了，完全没有重视。

解决方案

1、通过在docker的nginx配置中增加负载均衡，增加10个容器同时并发

    http {
        upstream fastapi_backend{
            server web_1:8000;
            server web_2:8000;
            server web_3:8000;
            server web_4:8000;
            server web_5:8000;
            server web_6:8000;
            server web_7:8000;
            server web_8:8000;
            server web_9:8000;
            server web_10:8000;
        }
    server {
            listen  80;
            location / {
                    proxy_set_header Host $http_host;
                    proxy_set_header X-Real-IP $remote_addr;
                    proxy_set_header REMOTE-HOST $remote_addr;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                    proxy_pass http://fastapi_backend;
            }
        } 

2、在容器启动上面使用--scale参数，比如 docker-compose up --scale web=10 -d这样来确保容器启动。 3、因为线上项目虽然崩了（大量返回404、502等各种错误），但部分请求还能跑通，所以直接停掉也不现实，只能进入mysql机器，在逐个执行要添加的索引

CREATE INDEX 索引名称 ON 表名(字段1, 字段2,字段3...);

上面这一套组合拳打下来，主要就是负载均衡、添加索引、代码优化，成功优化完成。 1、mysql没有慢查询，机器cpu占用率从100%下降到3%以下； 2、机器整体性能从单web容器100%,到10个容器，平均每个在30%以内；

同时对于热更新docker-compose build web 、docker-compose restart web 可以实时单容器类目更新应用的也更熟悉了。