今天，首席CTO笔记将与您分享与Django有关的哪些过程。其中，将详细介绍Django的工作原理。如果您可以解决您现在面临的问题，请不要忘记注意此网站。让我们现在开始！
本文目录清单：
1. DJANGO源代码阅读（1）项目的生成和启动2.主管提起了Django 3的过程，Django A请求对应于过程4. Django和主管的管理过程，诚实，到目前为止，我将做到这一点因此，Fardon不欣赏django。这不是我认知中的微妙设计。这只是功能所积累的“成熟解决方案”。，但这是需要的。
将其本质带到滴度上，Django的优势很方便。我们的源代码阅读的目的是探索其便利性的本质。阅读源代码的计划对每个地方都不好，而是解释功能的功能。
django-admin startproject helloworld可以生成django项目。命令行是EXE格式。
manage.py将参数交给了命令行。
execute_from_command_line（）通过命令行参数创建管理类。然后运行他的execute（）。
如果设置了重新加载，请在启动之前检查_errors。
check_errs（）是一个关闭，因此在上一篇文章的末尾是（django.setup）（）。
查看最后一个句子设置.installed_apps.grab从设置
请注意，此设置不是我们项目中的设置。
这是设置类的懒负载包装包装，直到__getAttr __。然后从设置类的实例中获取值，然后说将其分配给您自己的__ -dict__（我会直接找到它下次我自己，因为__getAttr __优先级）
为了促进调试，我们直接编写一个run.py。
在项目下创建一个run.py，以模拟运行服务器命令
调试抓取设置_MODULE
回到setup（）中的最后一句话
开始观看apps.populate（）
首先查看本段
这些应用最终被封装在appconfig中。
随后，调用了每个AppConfig的import_models（）和ready（）方法。
应用程序的加载部分通常是这样的
为了促进调试，我们重写了最后一句话
RES的类型是命令django.contrib.staticfiles.management.commands.runserver.com和object at 0x00000101ED5163A0
重点是第二个句子，让我们跳到run_from_argv（）方法，这是几个处理参数。
用Pycharm指向手柄将进入基类，该基类无法获得正确的方向。实际上，子类已重写此方法。
这里有两种情况。如果加载重新加载，它将直接执行inner_run（），并且项目首先从其他逻辑开始。
当Django项目启动时，它实际上将启动两次。如果我们在项目入口（manage.py）中设置一个贴心，您会发现它将打印两次。
在第一个启动开始时，django_autoreload_env却没有，无法输入启动逻辑。将输入crandt_with_reloader（）。
在这里，您将将django_autoreload_env放置为true，然后重新启动。
第二次，您可以输入启动逻辑。
在此创建一个Django主线程以传递innit_run（）。
随后，此线程创建了一个旋转式，通过reloader.run（django_main_thread）询问监护过程。
让我们看一下django innion_run（）的主线程。
当我们看到WSGI时，Django的启动逻辑已经结束。下一个作业已移交给WSGI服务器
这相当于我们之前在Fastapi中所说的话，然后将Fastapi的应用程序交给ASGI服务器（ASGI也是Django提出的，这两个基本上是同源的）
那么WSGI来自哪里？让我们回头回去
此设置是一个对象，它已从以前的操作中从settings.py配置文件中获取了自己的属性。因此，我们只需要转到settings.py配置文件即可找到。
让我们找到此get_wsgi_application（）。
它将再次调用setup（），返回WSGIHANDLER类的实例很重要。
这是WSGIAPP本身。
load_middleware（）是WSGIAPP构建中间件堆栈的唯一方法。
如果您之前阅读了FastAPI源代码，则应该对中间件堆栈不陌生。
应用程序入口→中间件堆栈→路由→路由节点→端点
因此，WSGIAPP已完成此操作，并将服务器传递到应用程序入口的请求中，并且可以通过中间件与该路由分配。
知道这是Django自己的重新加载，我在Django的Django中向Django添加了两个过程。将没有两个进程。但是，以这种方式，Django无法自动加载修改后的文件。
在UWSGI部署方法中，请求将输入一个过程，但同时“接收”了多个请求。
在Django项目中，我们需要使用独立于Django框架的某些脚本。这样，某些脚本可能需要独立运行并具有强大的维护。目前，主管可用于使用该字段。
直接使用PIP
使用主管很容易。您只需要修改一些配置文件即可使用它。
跑步
您可以看到默认配置情况，但是通常，我们不应修改默认配置。相反，将默认配置重定向到其他文件。不同的过程使用不同的配置文件来复制默认文件。
默认配置描述
解释了配置文件，并且非常简单，因此我不描述它。有一些建议可以修改其目录。如果您进行了修改，则应首先创建这些文件。您需要注意权限。
现在，让我们开始主管服务。
检查主管是否运行：
上面我们运行了SuberSrod，现在我们可以添加要管理的配置文件。您可以在Substisord.Conf文件中编写所有配置项目，但是不建议这样做。相反，不同程序（组）被写入不同的配置文件。是的，这是默认配置在默认配置结束时的末尾。
假设我们将项目配置文件放在此目录中：/etc/supervisor/
然后，我们需要修改include in /etc/supervisord.conf为::
测试PY文件：
以下是Configuration File Directory /etc/supervisor/test.conf：
配置完成后，可以运行：
查看运行状态
打开浏览器，输入127.0.0.9001，然后输入用户名和密码（如果在set_http_server中的配置文件中设置），您可以看到以下接口：
开始服务后，运行：
或直接监管
如果成功，您将输入supercorctl的外壳接口。有以下方法：
执行相关操作后，您可以在网络端看到特定更改，例如停止程序
实际上，您也可以使用suspisorctl shell接口，但在Bash终端运行：
根据官方文档的定义，a [program：x]实际上是指一组相同的功能或相似过程，也就是说，[program：x]可以启动多个进程。该过程的成员由该过程确定numProcs和process_name的两个参数。这句话是什么意思？让我们看这个示例。
上面的示例将启动两个进程，proces_names是foo：foo_01和foo：foo_02.in。
详细配置，单击此处
主管还提供另一种流程组管理方法。通过这种方式，可以使用supcortisorctl命令来管理一组进程。从[program：x]的进程组不同，此处的过程是[program：x]。
添加上述配置后，Program1和Progname2的过程名称将成为GroupName：program：program1 and theGroupName：“管理过程”而不是以前的protname1。
在SupervisorCtl停止groupname之后：您可以同时结束程序元和progname2，并执行supcordisorctl stop top thegroupname：the groupname：togral to end protName1。
实际上，默认情况下，主管也是一个过程。最理想的情况应作为系统服务安装。可以在此处引用安装方法。安装脚本在这里引用。因为没有具体的实验，所以这里没有解释。
实际上，还有另一种简单的方法，因为Linux启动时会在 /etc/rc.local中执行脚本，因此只要您在此处添加执行命令
需要在退出命令之前添加上述内容，并且由于执行RC.Local脚本时未初始化路径环境变量，因此需要与绝对路径一起使用该命令。
在添加之前，请测试是否可以在终端中正常执行命令。如果找不到主管，可以找到以下命令
结论：以上是首席CTO的全部内容有关Django过程的注释。感谢您阅读本网站的内容。我希望这对您有帮助。关于Django的工作原理的更多信息，Django有什么过程？不要忘记在此网站上找到它。