FastAPI接口调用Linux系统命令时遇到的问题

        最近的工作一直是在开发一些接口，大概介绍一下其中一个实现的功能：通过调用接口，从公司的gitlab中clone代码到服务器上，具体的逻辑是通过Python的FastAPI构建一套接口框架，接口中使用subprocess.run()方法运行git clone ssh://xxxx.git /home/download。实现的过程不难，本地很快就开发完并完成了测试，但是在部署到服务器之后却遇到了问题。

        服务器的部署我用的是gunicorn，这是几乎网上所有资料包括官网都推荐的生产环境部署方式，我用的启动命令如下：

gunicorn -k uvicorn.workers.UvicornWorker -c gunicorn.conf.py run:app

启动后访问接口，在运行的clone命令时直接报错：fatal: the remote end hung up unexpectedly，网上查到的资料基本上都是去修改git配置中的缓存以及超时时间，而这些办法都不能解决我的问题，我只能一点点的排查问题可能出现的原因。

        首先，我在服务器上直接运行git clone命令，下载正常。之后又在服务器的Python控制台中执行相关的代码（subprocess.run(git clone ssh://xxxx.git /home/download)），结果也正常。再之后分别创建了shell脚本以及python脚本，都能正常使用。但只要在接口中调用，不管是直接使用subprocess还是调shell脚本，通通报错。再结合本地正常、服务器端报错的线下，问题应该就出现在接口框架或者gunicorn上了（本地使用的是uvicorn）。

        问题定位了，但是原因以及解决办法是什么呢？只能去翻官方文档或者源码了，趁着国庆假期好好的肝了一把。先是FastAPI的官方文档，看了一遍后似乎没找到问题可能的原因。再继续看uvicorn和gunicorn，似乎发现了一些问题。文档中在开头就介绍：

Uvicorn is a lightning-fast ASGI server implementation, using uvloop and httptools.

Gunicorn ‘Green Unicorn’ is a Python WSGI HTTP Server for UNIX

继续找ASGI和WSGI的文档，看到了这些：

WSGI applications are a single, synchronous callable that takes a request and returns a response; this doesn’t allow for long-lived connections, like you get with long-poll HTTP or WebSocket connections. 

而git clone在执行过程中，其实是多步操作，如下图就是打印出了git clone执行的整个过程：

 而每次报错就是在执行了第一句ssh -p后发生的，问题应该就是这个原因，解决办法也很简单，将服务器上的gunicorn改为uvicorn，重启后调用接口，果然解决了问题。

        问题虽然解决了，但是原因是不是真的如我所分析的这样呢？还是需要继续去深挖一下ASGI、WSGI的执行过程以及相关原理的。最后总结一下我在这个问题的解决过程中的收获吧！首先肯定是FastAPI、uvicorn、gunicorn、ASGI、WSGI的相关知识。在整个过程中，看了很多官方文档和源码（主要是FastAPI的源码）收获很大！其次是问题的逻辑分析判断过程，根据已有的线索如何一步步的去判断问题可能出现的原因以及根据判断去试错，这个过程也学习到了不少的引申知识（各种试图“曲线救国”，比如使用Python调用Java、换flask等等）同时也再次证明了“老本行”的关键性啊😂