Glance源码架构探秘（四）

Glance源码架构探秘（一）

Glance源码架构探秘（二）

Glance源码架构探秘（三）

Glance源码架构探秘（四）

最近感情生活颇不顺利，耽搁了很长时间。今天抽出时间来给大家继续分享Glance源码架构探秘，详细阐述glance镜像操作部分。

前几章，我们花了很大的篇幅，讨论了Glance服务的WSGI框架部分，包括网络编程eventlet库，绿化的webserver，WSGI，URL的Routes分发，分析请求拼接响应及控制器controller的机构等。了解及掌握这些技术内幕，对于我们今后研究Nova的代码架构是十分有帮助的。

首先，我们先研究一下Glance的代码目录，我们一直以来还没有研究过目录，这对本章的理解十分重要

api —— API对外接口的包，glance服务的对外接口都在这里

    middleware —— 中间件

    V1 —— 第一版API

    V2 —— 第二版API

    authorization.py —— 提供用户验证管理的功能

    policy.py —— 提供policy管理的功能（policy不是本章的重点，可自行进行引申阅读）

common —— glance一些共用的模块

db —— 数据库操作模块

openstack —— openstack的一些共用模块

notifier —— 通知系统的模块（目前主要做log用）

store —— 后端存储管理模块

当用户的glance操作的请求通过WSGI，通过分发dispatch终于进入到控制器Controller之后，我们也最终要开始glance镜像的具体操作了。大家研读Controller内的代码会发现，不管什么操作，如上传镜像，修改镜像元数据等，开始都会有上述两条语句

image_factory = self.gateway.get_image_factory(req.context)
image_repo = self.gateway.get_repo(req.context)

会生成一个image_factory对象和一个image_repo对象，其中image_factory对应后端store进行镜像的存储等操作，image_repo对应glance的镜像数据库的管理等操作。

我们看一下gateway中的代码

class Gateway(object):
    def __init__(self, db_api=None, store_api=None, notifier=None,
                 policy_enforcer=None):
        self.db_api = db_api or glance.db.get_api()
        self.db_api.configure_db()
        self.store_api = store_api or glance.store
        self.notifier = notifier or glance.notifier.Notifier()
        self.policy = policy_enforcer or policy.Enforcer()

    def get_image_factory(self, context):
        image_factory = glance.domain.ImageFactory()
        policy_image_factory = policy.ImageFactoryProxy(
                image_factory, context, self.policy)
        authorized_image_factory = authorization.ImageFactoryProxy(
                policy_image_factory, context)
        return authorized_image_factory

    def get_repo(self, context):
        image_repo = glance.db.ImageRepo(context, self.db_api)
        store_image_repo = glance.store.ImageRepoProxy(
                context, self.store_api, image_repo)
        policy_image_repo = policy.ImageRepoProxy(
                context, self.policy, store_image_repo)
        notifier_image_repo = glance.notifier.ImageRepoProxy(
                policy_image_repo, self.notifier)
        authorized_image_repo = authorization.ImageRepoProxy(
                notifier_image_repo, context)
        return authorized_image_repo

下面是我画的所涉及到类的UML图

熟悉涉及模式的同学可以看出，这是一个经典的责任链模式（Chain of Responsibility）。责任链模式是一种对象的行为模式【GOF95】。在责任链模式里，很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使得系统可以在不影响客户端的情况下动态地重新组织链和分配责任。

正如上面对于责任链模式的描述，我们进行一个操作比如add（），这个操作会在我们的ImageRepoProxy责任链上传递下去（authorization -> notifier -> policy -> store -> db），如果这个操作在链上某个类中有对应的同名方法，则调用这个方法然后传递下一级类，否则直接传递至下一级。通过这种方式，将验证，通知，policy，后端存储，数据库等操作有机的结合起来，代码结构也非常优美，便于理解。

OpenStack代码可以发现许多非常棒的设计模式的应用，大家不妨多多留心。