swift的启动流程

悠悠 2021-10-19 23:36 380阅读 0赞

转载地址[http://www.cnblogs.com/yuki-lau/archive/2013/06/05/3119866.html][http_www.cnblogs.com_yuki-lau_archive_2013_06_05_3119866.html]

（还有其他很好的文章）

说起较大型系统的源码阅读，算上目前正在进行的Swift，也就只有两次经验（去年的上半年有阅读过学习过[Openfire][]的源码）。虽说还是菜鸟级别啦，但两次也可以总结经验嘛:P，哈哈~

我的这个经验呢，就是对于这种服务器端的源码，最好首先对系统的“启动过程”和请求到来时的“data flow”进行一遍跟踪阅读，了解程序的运作流程以及各个关键类、方法之间的关系，然后再从这条主线进行各个分叉流程的细致学习。这种方式一来目的性比较强，代码比较容易看得下去，二来不会有越看越茫然的感觉，总体上是逐渐清晰了解细节的过程。

好啦，废话说完咯，进入正题。这两周开始了swift源码（swift 1.8.0）的学习，首先就按照以上所述的流程进行了一遍粗浅的阅读，现在总结一下。

Swift启动流程=========================================================

在ubuntu上部署完毕swift后，我们知道可以执行脚本 startmain 启动swift，那么这条命令执行后，swift究竟做了哪些启动相关的工作呢？

1. 概况

startmain 脚本实际上是执行了以下这条命令：

![复制代码][copycode.gif]

swift-init main start

![复制代码][copycode.gif]

即为swift执行初始化工作，而该命令实际上又分别执行了swift-proxy-server、swift-account-server、swift-container-server、swift-object-server 这四个swift bin中的python命令。接下来，让我们看一下在swift代码中都做了些什么。

2. swift-init

swift-init 是启动swift的脚本，改脚本可以跟几个参数：swift-init \[主体\] \[动作\]。在“swift-init main start”中main就对应主体，动作即为start。

1）swift-init main start 执行后，首先看swift-init代码 line61~line62，在这里对命令和参数进行了分割，从而决定接下来的执行任务：

![复制代码][copycode.gif]

command = args[- 1]     #command此处为start
    servers = args[:-1]     #servers此处为main

![复制代码][copycode.gif]

2）在swift-init代码line 70，创建了Manager的实例，Manager是直接管理各个servers的类：

![复制代码][copycode.gif]

manager = Manager(servers, run_dir=options.run_dir)     # 这里执行了Manager的__init__

![复制代码][copycode.gif]

3）由于在上一步中，swift-init创建了Manager实例，因此调用了Manager的\_\_init\_\_初始化方法，在\_\_init\_\_方法中，我们可以看到对命令参数servers（这里是“main”）的处理（line 137）。

![复制代码][copycode.gif]

elif server == 'main':
        server_names.update(MAIN_SERVERS)

![复制代码][copycode.gif]

其中MAIN\_SERVERS为manager.py中定义的全局数组，指明了swift中servers的启动脚本（line 37）

![复制代码][copycode.gif]

MAIN_SERVERS = ['proxy-server', 'account-server', 'container-server', 'object-server']

![复制代码][copycode.gif]

在Manager.\_\_init\_\_最后add servers的时候，就创建了Swift中的四个Server： swift-proxy -server、swift-account-server、swift-container-server、swift-object-server

4）Manager实例创建完毕后，回到swift-init中，在line 72，调用了manager的run\_command方法，继而获取了start命令：

![复制代码][copycode.gif]

status = manager.run_command(command, **options.__dict__)

![复制代码][copycode.gif]

5）在manager.py的run\_cmmand方法中（line 162），最终执行了start方法，即执行了swift-proxy -server、swift-account-server、swift-container-server、swift-object-server的\_\_main\_\_，也就是start方法中调用的launch方法打印了这堆东西：

![05204440-c4f8ab9bf3534cb398952a851b4b23b6.png][]

到这里，swift中的各个servers就被启动起来了，接下来让我们以proxy-server为例，看看在这些swift-xx-server中都做了些什么。

3. swift-xx-server的启动

在swift-xx-server中最终调用了相应的xx.server.py中相应类的\_\_init\_\_（以proxy为例）：

![复制代码][copycode.gif]

run_wsgi(conf_file, 'proxy-server', default_port=8080 , **options)

![复制代码][copycode.gif]

我们可以看到swift的HTTP交互是基于WSGI实现的，并且它使用了paste deploy进行配置文件的管理，从而通过xx-server.conf配置文件load相应的wsgi app。在run\_wsgi方法中，主要执行了以下四个步骤：

1）run\_wsgi方法根据参数load配置文件

2）根据配置文件绑定的端口创建socket，将socket与server绑定

![05204934-ebfcacc5d88b4fba9a98f520feda8878.png][]

3）run\_server方法调用proxy的server的\_\_init\_\_方法

4）\_\_init\_\_方法根据配置文件初始化server的内部状态，从而gets the server ready to handle requests

至此，Swift中的各个servers就已经stand by啦！只待request的到来！OK，那么接下来让我们来看一下当一个request到来时，swift中的data flow又是怎样的吧 : )

Swift Data Flow=========================================================

在上文中呢，我已经提到过swift的HTTP交互框架是基于wsgi实现的，并且使用paste deploy实现通过conf来load app，因此如果你希望可以更好的了解swift的交互流程和wsgi-style application标准，那么建议你先学习一下 [wsgi标准][wsgi] 以及 [paste deploy][] 的配置文件含义。

首先，来看一张俺画滴图！这张图基本上就把整个请求过程的data flow说清楚啦！（原谅我无耻的打了水印，哈哈哈哈哈）

![05211329-2d77f6cceae1432584a77a541595b472.jpg][]

让我们按照图中的流程来解释吧。

1. Send a Request

首先，用户也就是Client向swift发出一个request，该请求通过proxy-server.conf中配置的bind\_port进入swift；

2. WSGI middleware: Pipeline

这里先给出一份proxy-server.conf的配置内容，我们来结合这个paste deploy配置文件进行pipeline的说明：

![复制代码][copycode.gif]

[DEFAULT]
    bind_port = 8080
    user = root
    log_facility = LOG_LOCAL1
    eventlet_debug = true
    
    [pipeline:main] pipeline = healthcheck cache tempauth proxy-logging proxy-server 
    [app:proxy-server]
    use = egg:swift#proxy
    allow_account_management = true
    account_autocreate = true
    
    [filter:tempauth]
    use = egg:swift#tempauth
    user_admin_admin = admin .admin .reseller_admin
    user_test_tester = testing .admin
    user_test2_tester2 = testing2 .admin
    user_test_tester3 = testing3
    
    [filter:healthcheck]
    use = egg:swift#healthcheck
    
    [filter:cache]
    use = egg:swift#memcache
    
    [filter:proxy-logging]
    use = egg:swift#proxy_logging

![复制代码][copycode.gif]

请求需要经过wsgi pipeline中的层层过滤器才能最终到达请求的应用：proxy-server。请注意配置文件中加粗的部分：

\[pipeline:main\]表明这里是application的入口，pipeline代表一些列的filters，main则类似各种编程语言中的main方法指明入口。

pipeline = filter1 filter2 ... filterN application 的最后一个元素必须是一个符合wsgi的callable对象，具体到这个例子中，表明请求必须经过healthcheck、cache tempauth、proxy-logging这四个filter的过滤后，才能到达proxy-server。如果请求没有通过任何一个过滤器，则请求将会被返回相应的错误信息，不能到达proxy-server。

这些filters和最后的app都必须是符合WSGI标准的callable application，在程序执行时，依次调用它们的\_\_call\_\_方法，让我们以healthcheck为例，来看看它的\_\_call\_\_:

![复制代码][copycode.gif]

def __call__(self, env, start_response):
            req = Request(env)
            try:
                if req.path == '/healthcheck':
                    handler = self.GET
                    if self.disable_path and os.path.exists(self.disable_path):
                        handler = self.DISABLED
                    return handler(req)(env, start_response)
            except UnicodeError:
                # definitely, this is not /healthcheck
                pass
            return self.app(env, start_response)

![复制代码][copycode.gif]

我们可以看到，这个方法必须包含两个参数（这里是类中的方法，因此还有一个self）env和start\_response，env是wsgi中的环境变量字典，start\_response用于产生response的结果，这个方法返回的self.app(env, start\_response)的这个app其实就是它的下一个filter：cache，cache也会以相同的方式执行，直到调用proxy-server，proxy-server负责产生相应的Response并返回。

3. Proxy-Server.\_\_call\_\_

假设Client发出的这个request非常的合法，他通过了所有的filters，现在终于到达了proxy-server，那接下来又会发生什么呢？

proxy-server这个application实际上对应swift源码proxy包下的server.py中的Application类，如同我们在上文中说到的，这里会调用Application.\_\_call\_\_。在Application.\_\_call\_\_中，对请求做了一些校验，合法后，就调用它的handle\_request方法，顾名思义的来handle这个request。

我们知道在swift中请求可以针对account、container和object，显然它们所对应的控制器是不一样的，因此在handle\_request方法中又继续调用了get\_controller方法。

get\_congroller方法根据request path中的http://xxxx/account\[container/object\]/xxx的子路径来判断这个request想要请求的部分，从而获取对应的controller（AccountController、ContainerController、ObjectController）。细心的你一定会检查一下swift源码中的account包、container包、obj包中的server.py吧，没错AccountController、ContainerController、ObjectController就分别位于这些server.py中！

4. Controllers

现在，我们已经确定了这个request对应的controller啦！那么它的请求动作又是什么呢？HEAD？GET？其实这一切已经在HTTP Verb中定义了，因此在handle\_request方法中会继续调用controller实例中对应的XXX方法（如HEAD/PUT/GET/POST/DELETE），这些方法最终对这个request做出处理，产生响应，返回相应的Request！

5. 返回Request

最后这个Request就沿着原路一层层的返回到Client。Swift也继续该干嘛干嘛等待它来自四面八法的Requests。

至此，一个比较outline的请求处理过程就算介绍完毕了。我在这里省略了很多的细节和校验工作，只是为了让大家跟我一样，在diving into swift source code前先知道它的水大概有多深，路线大概是个什么样子的。至于每一步的细节，和精准的角度，还需要在后续一步步的来看，一步步的充实、学习。

==================================全文完结分割啦啦啦啦======================================

本文写于慌乱之际，说慌乱，是因为我对Python实在是一知半解，很多地方都是现学的（比如W

[http_www.cnblogs.com_yuki-lau_archive_2013_06_05_3119866.html]: http://www.cnblogs.com/yuki-lau/archive/2013/06/05/3119866.html
[Openfire]: http://www.igniterealtime.org/projects/openfire/
[copycode.gif]: /images/20211019/aebd4124f21547bd8a9afbf4c3ed4655.png
[05204440-c4f8ab9bf3534cb398952a851b4b23b6.png]: /images/20211019/ea6b3f6cce1141dab88fef1017ed1a3c.png
[05204934-ebfcacc5d88b4fba9a98f520feda8878.png]: /images/20211019/216daa684d3d45f6b68db26119b037d5.png
[wsgi]: http://www.python.org/dev/peps/pep-0333/
[paste deploy]: http://pythonpaste.org/deploy/#the-config-file
[05211329-2d77f6cceae1432584a77a541595b472.jpg]: /images/20211019/16dd7f4b3ec44412a2b52784de211e39.png