Swift作为一个存储的具体实现出现在OpenStack中，与Cinder的定位有差别，这导致Swift的兼容并包性不够强。必须基于XFS文件系统来存储数据?显然Swift也希望能将数据存储到更多的后端设备中，这样Swift可与具体的XFS文件系统解耦，作为独立的存储软件存在。这能使得Swift存储的构建更加灵活，同时也能吸引更多的存储厂商(如阿里云)投入到其怀抱中。

　　Swift提供了一种简单机制来实现后端存储设备的pluggable——可插拔的后端。这篇文章想探讨一下该机制。在亚特兰大峰会上面，这一特性是Swift的热门话题之一，对于亚特兰大OpenStack峰会涉及Swift的话题这里有汇总：链接。

　　看起来很有意思的创举，细看起代码来，其实挺简单的。有句话说，代码之外，了无秘密。Swift对于存储介质的要求其实挺简单的，提供读取，写入接口，涉及两种类型的数据：对象数据和元数据。对于面向对象而言，这个接口的实现就很容易了。

　　/swift/swift/obj/server.py文件定义了REST API，在各个API中有访问DiskFile的流程，其实也就是对DiskFile需要提供的接口的要求。那么只要新的DiskFile实现各个API中需要的接口就可以了。这样接口其实是固定的。OpenStack的官方文档给出了接口的详细描述：Back-end API for Object Server REST APIs。新的设备怎样接入?怎样被业务访问到呢?是不是整个obj目录要整体替换掉，那样显得很笨拙，有很多代码是可共用，就像刚才提到的REST API这一部分是固定的，完全可保留。但是从下面的代码来看：

　　class ObjectController(object):

　　…

　　05def setup(self, conf):

　　"""

　　Implementation specific setup. This method is called at the very end

　　by the constructor to allow a specific implementation to modify

　　existing attributes or add its own attributes.

　　:param conf: WSGI configuration parameter

　　"""

　　# Common on-disk hierarchy shared across account, container and object

　　# servers.

　　self._diskfile_mgr = DiskFileManager(conf, self.logger)

　　# This is populated by global_conf_callback way below as the semaphore

　　# is shared by all workers.

　　if 'replication_semaphore' in conf:

　　# The value was put in a list so it could get past paste

　　self.replication_semaphore = conf['replication_semaphore'][0]

　　else:

　　self.replication_semaphore = None

　　self.replication_failure_threshold = int(

　　conf.get('replication_failure_threshold') or 100)

　　self.replication_failure_ratio = float(

　　conf.get('replication_failure_ratio') or 1.0)

　　def get_diskfile(self, device, partition, account, container, obj,

　　**kwargs):

　　"""

　　Utility method for instantiating a DiskFile object supporting a given

　　REST API.

　　An implementation of the object server that wants to use a different

　　DiskFile class would simply over-ride this method to provide that

　　behavior.

　　"""

　　return self._diskfile_mgr.get_diskfile(

　　device, partition, account, container, obj, **kwargs)

　　从上面加粗的diskfile_mgr成员来看，似乎server类与diskfile耦合了，绑定在一起了。但是再看，也只有这两处涉及到了具体的Diskfile相关类的对象的生成。只要能够向server的ObjectController类中“注入”自定义的Diskfile Manager等类的对象就可以了。很自然的就想到了开放出setup接口，提供一个类似于setdiskfile(SpecialDiskfileMgr diskfilemgr)的接口，这样其实破坏了封装性，不是面向对象的实现。并且，ObjectController是框架生成的，不易于获取到其运行的时候的实例。考虑另外一种思路，就是继承server中的ObjectController，实现一个新的ObjectController，这个ObjectController只需要重写setup方法就可以了。如果有必要，将get_diskfile也重写一下，若接口定义得足够优雅，那么只需要前者。运行时，将新的ObjectController注册到WSGI框架中就可以了。正好WSGI框架是通过配置来指定具体的server类的。因此只需要修改配置就可以同时支持多种不同的后端。

　　Swift提供一个简单的样例，一个内存文件系统的后端接口：

　　/swift/swift/obj/mem_diskfile.py定义了一整套的上述文档中规定的接口的实现。/swift/swift/obj/mem_server.py中定义了新的ObjectController，供客户配置使用。只需修改/etc/swift/object-server.conf中的pipline中的最后的server指向新的ObjectController即可。

　　看具体ObjectController的代码：

　　class ObjectController(server.ObjectController):

　　"""

　　Implements the WSGI application for the Swift In-Memory Object Server.

　　"""

　　def setup(self, conf):

　　"""

　　Nothing specific to do for the in-memory version.

　　:param conf: WSGI configuration parameter

　　"""

　　self._filesystem = InMemoryFileSystem()

　　def get_diskfile(self, device, partition, account, container, obj,

　　**kwargs):

　　"""

　　Utility method for instantiating a DiskFile object supporting a given

　　REST API.

　　An implementation of the object server that wants to use a different

　　DiskFile class would simply over-ride this method to provide that

　　behavior.

　　"""

　　return self._filesystem.get_diskfile(account, container, obj, **kwargs)

　　相信不久的将来，Swift会有越来越多的后端存储设备可以选用，这其实相当于Swift变成一个存储的管理软件，集成各种存储设备的适配“驱动”就可以实现将数据存储到其上。