全职技术开发外包2023年终复盘(二)django的启动流程是怎样的?

本文是2023年技术复盘文章之一。

复盘带来思考,通过思考取其精华,精进自我,提升赚钱能力。

平时对django的源码饶有兴趣,时不时翻看源码。本篇总结重在梳理django启动流程,了解在该过程中,到底发生了哪些事,用了哪些值得学习的方法。

注:生产环境和开发环境,仅入口文件及前面的某些流程有别而已,所以就以开发服务器启动的流程来分析。另外,我制作了一张启动的流程图,如想获取,移步文末看获取的方法。

第一步:入口文件启动

在上一篇django是如何加载settings的复盘中已有描述,manage.py会启动一个命令行管理工具类,命令行工具名为MangemenUtility类,执行它的execute方法会进入到启动流程。

django.core.management.__init__.py

def execute_from_command_line(argv=None):
    """Run a ManagementUtility."""
    utility = ManagementUtility(argv)
    utility.execute()

第二步 :载入配置文件、载入django模块

这里不再赘述,可看上一篇文章django是如何加载settings的:

在载入配置文件后,会继续载入django的各模块,加载内置的和开发者自定义的模型类:

django.core.management.__init__.py

class ManagementUtility:
    # 省略其他代码
    def exexute(self):
        # 省略其他代码
        django.setup()
        # 省略其他代码
    # 省略其他代码

django.setup()感兴趣的可自行查看源码。

只要运行了django.setup(),就能在当前进程中使用django的模块了,这也是我们要在子进程中使用django时,需要使用该方法的原因。如:

在这里插入图片描述

当然,这个步骤还有不少琐碎之事,如:

  • 解析命令行参数和选项
  • 热重载时语法检查(闭包函数实现)

第三步:调用Command类运行命令

需要先行注明的是,该环节有点绕,涉及到三个类,分别是:

1、当前Command类(该步骤所说的当前类均指该类),位于:

django.contrib.staticfiles.management.commands.runserver文件中

2、父类Command类(子类和它同名,??,该步骤所说的父类均指该类),位于:

django.core.management.commands.runserver文件中

3、祖父类BaseCommand该步骤所说的当祖父类均指该类),位于:

django.core.management.base文件中

走入这个绕脑袋的流程,就从self.fetch_command(subcommand).run_from_argv(self.argv)开始

class ManagementUtility:
    # 省略其他代码
    def exexute(self):
        # 省略其他代码
        django.setup()
        # 省略其他代码
        self.fetch_command(subcommand).run_from_argv(self.argv)
    # 省略其他代码

subcommand就是一个当前的Command类实例,由它去调用run_from_argv方法,这个方法,在祖父类中才有:

1、跳转到祖父类中的run_from_argv方法,在该方法中又执行了execute方法;

def run_from_argv(self, argv):
	# 省略其他代码
    try:
        self.execute(*args, **cmd_options)
    except CommandError as e:
        if options.traceback:
            raise
	# 省略其他代码

2、当前类中并没有execute方法,其父类中有,但也没干什么特别的事,又super().execute()跑回祖父类的execute方法了,

def execute(self, *args, **options):
	# 省略其他代码
    # 一灯注:检查迁移文件
    if self.requires_migrations_checks:
        self.check_migrations()
    # 一灯注:handle是个非常重要的节点的入口
    output = self.handle(*args, **options)
    # 一灯注:连接数据库
    if output:
        if self.output_transaction:
            connection = connections[options.get("database", DEFAULT_DB_ALIAS)]
            output = "%s
%s
%s" % (
                self.style.SQL_KEYWORD(connection.ops.start_transaction_sql()),
                output,
                self.style.SQL_KEYWORD(connection.ops.end_transaction_sql()),
            )
        self.stdout.write(output)
    return output

3、self.handle是个非常重要的节点入口,父类中声明了该方法必须在子类中重写,当前类并无handle方法,那么它一定在父类中实现了:

def handle(self, *args, **options):
    if not settings.DEBUG and not settings.ALLOWED_HOSTS:
        raise CommandError("You must set settings.ALLOWED_HOSTS if DEBUG is False.")
    # 省略其他代码
    self.run(**options)

4、self.run方法在当前类中也没有,在父类中有,self.run又迅速跳转到self.run_inner方法,同样的,该方法依然在父类中:

def inner_run(self, *args, **options):
    # 省略其他代码
    # 一灯注:检查迁移文件,和上面的检查迁移文件是二选一,即总会有一个节点是要检查的
    self.check_migrations()

    try:
        handler = self.get_handler(*args, **options)
        # 一灯注 run函数入参,传入了handler
        run(
            self.addr,
            int(self.port),
            handler,
            ipv6=self.use_ipv6,
            threading=threading,
            on_bind=self.on_bind,
            server_cls=self.server_cls,
        )
    except OSError as e:
        # 省略其他代码
        pass

这里是一个重要的分水岭,在该代码中,handler = self.get_handler(*args, **options)能获取到一个WSGIHandler的实例,它专门用来处理请求和响应的,即让请求和响应进入到django的内部中。既然是分水岭,那它到底分了什么呢?重点如下:

self.get_handler方法在当前类和父类都有,我们是通过当前类进来的,那么它当然会使用当前类的get_handler方法:

def get_handler(self, *args, **options):
    """
    Return the static files serving handler wrapping the default handler,
    if static files should be served. Otherwise return the default handler.
    """
    handler = super().get_handler(*args, **options)
    use_static_handler = options["use_static_handler"]
    insecure_serving = options["insecure_serving"]
    if use_static_handler and (settings.DEBUG or insecure_serving):
        return StaticFilesHandler(handler)
    return handler

StaticFilesHandler的源码就不贴了,它的功能是,在开发服务器环境下,包装WSGIHandler类,增加了静态文件处理的方法。故当我们使用python manage.py runserver 启动开发服务器时,之所以能处理静态文件,关键点就在这了。请注意,在上面 run函数中,传入了StaticFilesHandler类实例,形参为:handler

再来说说,父类的get_handler方法,比当前类的更简单,它直接获取了一个WSGIHandler的实例,DEBUG = False时,会使用父类的get_handler,我们在开发服务器上设置DEBUG = False时会无法处理静态文件,样式文件js文件统统丢失。

注:

1、WSGIHandler__call__方法,上面的流程,获取到的都是它的类实例,这个类实例最后会交给底层服务器,由底层服务器调用实例,也就是调用__call__方法;

2、它在实例化时,自动加载一次中间件,并把所有中间件可调用的方法组合成一个中间件链(middleware_chain),供后面所使用。

再回头看看handler = self.get_handler(*args, **options)下方的run函数,它由外部文件引入,运行run方法后,启动流程就基本结束了。

第五步:运行run函数

该方法在django的服务器模块中:

def run(
    addr,
    port,
    wsgi_handler,
    ipv6=False,
    threading=False,
    on_bind=None,
    server_cls=WSGIServer,
):
    server_address = (addr, port)
    if threading:
        httpd_cls = type("WSGIServer", (socketserver.ThreadingMixIn, server_cls), {})
    else:
        httpd_cls = server_cls
    httpd = httpd_cls(server_address, WSGIRequestHandler, ipv6=ipv6)
    if on_bind is not None:
        on_bind(getattr(httpd, "server_port", port))
    if threading:
        httpd.daemon_threads = True
    httpd.set_app(wsgi_handler)
    httpd.serve_forever()

这一步,我们只关注重点:

1、httpd = httpd_cls(server_address, WSGIRequestHandler, ipv6=ipv6),启动了一个WSGIServer服务器,再往下看就追溯到底层了:socketserver服务;

2、httpd.set_app(wsgi_handler)WSGIHandler或子类StaticFilesHandler设置为底层服务socketserverapplication

3、在底层中,如果有请求,就会调用applicationapplicaiton(),把请求转交给WSGIHandler或子类StaticFilesHandler__call__方法;

4、在httpd = httpd_cls(server_address, WSGIRequestHandler, ipv6=ipv6)中,入参WSGIRequestHandler,它继承与wsgiref,看源码功推测应该是把原始的请求 包装成django的规范,以便请求进入到WSGIHandler或子类StaticFilesHandler__call__方法时,就可以直接使用了,也就是我们在视图中经常接触到的HttpReqeustHttpReponse对象。

至此,整个启动流程就结束了。

题外话

WSGIHandler或子类StaticFilesHandler__call__方法是django处理请求响应的开始,从这里开始,流程如下:

  • 加载中间件
  • 控制请求逐一经过请求中间件
  • 解析url,获取视图
  • 请求经过视图,生成响应
  • 控制响应逐一经过中间件
  • 响应传递给底层服务器

这里就不展开了,内容真的很多。

总结

1、整个流程似乎没看到什么异步操作,毕竟上下文联系得很紧凑,完成一步才能走到下一步流程

2、OOP的继承特性发挥到极致了,但也带来一些问题,阅读源码真的不容易,除了看不懂的,思路跟着流程在各个子类、父类、祖父类之间上蹿下跳也是一个大挑战;

3、不过继承特性也有好处,至少在django的启动流程中,开发服务器的启动和生产服务器走的流程,使用继承特性来满足分支需求显得非常容易;

4、会想起刚接触编程没多久,强行将各种不同功能函数揉成一个类,而各种教程也非常喜欢使用PersonCar之类的案例来讲述类的作用,随着经验见长,不断地阅读优秀的代码之后,对类才有了一些体会,在上面的PersonCar的基础上,增加一点个人拙见:

一个类,旨在完成一项工作,一项工作需要很多细节,如果几项工作的细节雷同,那么可以抽象一个基类了,N项工作都能继承该基类,如果方式相同,但细节不同,也可以抽象基类,子类可实现各自的细节。

问题

WSGIhandler中,为何要设计一个__call__来处理请求和响应呢?普通类成员方法也是可调用的,只能靠猜测了:

1、可能底层服务要求入参的handler必须是一个类实例

2、该类实例必须可调用

最后

个人水平有限,不当之处还请指出,感激不尽。
另外,我也将上面的流程绘制成了流程图,需要的可在评论区留言。