<p>来自： <a href="/misc/goto?guid=4959670128438023344" rel="nofollow">http://1.chaoxu.sinaapp.com/archives/3858</a></p>    <p>OpenStack遵循这样的设计原则，“不要重复发明轮子”，即对已实现的功能，开发者直接拿来用即可。这一设计原则最终形成了一个由专门团队维护的Oslo——OpenStack公共库，实现硬件、操作系统和应用程序等的松耦合。</p>    <p>一.消息总线（MQ）</p>    <p>OpenStack的各项目之间通过REST ful API进行通信；项目内部、不同服务进程之间的通信，则必须要通过消息总线。软件从最初的面向过程、面向对象、再到面向服务，要求我们去考虑各个服务之间如何传递消息，借鉴硬件总线的概念，引入了消息总线的模式，顾名思义，一些服务向总线发送消息，其他服务则从总线上获取消息。</p>    <p>OpenStack对很多消息总线的开源实现提供了支持，比如RabbitMQ、Qpid等。基于这些消息总线类型，OpenStack oslo.messaging库实现了以下两种方式来完成项目内部各服务进程之间的通信。</p>    <p>远程过程调用（RPC）</p>    <p>通过远程过程调用，一个服务进程可以调用其他服务进程的方法，并且有两种调用方式，call和cast。通过call的方式调用，远程方法会被同步执行，调用者会被阻塞直到结果返回。通过cast方式调用，远程方法会被异步执行，结果并不会立即返回，调用者也不会被阻塞，但是调用者需要利用其他方式查询这次远程调用的结果。</p>    <p>事件通知（Event Notification）</p>    <p>某个服务进程可以把时间通知发送到消息总线上，该消息总线上所有对此类事件感兴趣的服务进程，都可以获得此事件通知并进行下一步的处理，处理的结果并不会返回给事件发送者。这种通信方式，不但可以在同一个项目内部的各个服务进程之间发送通知，也可以实现跨项目之间的通知发送。Ceilometer就通过这种方式大量获取其他OpenStack项目的事件通知，从而进行计量和监控。</p>    <p>1.AMQP（高级消息队列协议）</p>    <p>OpenStack支持的消息总线类型中，大部分都是基于AMQP的。AMQP是一个异步的应用层消息传递开放协议，主要包括了消息的导向、消息交换、消息队列和路由。对于一个使用了AMQP的中间件服务而言，当不同的消息由生产者（Producer）发送到Server时，它会根据不同的条件把消息传递给不同的消费者（Consumer）。如果消费者无法接收消息或者接收消息不够快时，它会把消息缓存在内存或者磁盘上。</p>    <p>2.基于AMQP实现RPC</p>    <p>3．OpenStack支持的常见消息总线类型</p>    <p>1）RabbitMQ</p>    <p>2）Qpid</p>    <p>3）ZeroMQ</p>    <p>二．SQLAlchemy和数据库（Shane）</p>    <p>SQLAlchemy是Python语言下的一款开源软件，提供了SQL工具包以及对象关系映射器ORM，这样SQLAlchemy便能让Python开发人员简单灵活地运行SQL操作后台数据库。</p>    <p>SQLAlchemy主要分成两部分，SQLAlchemy Core和SQLAlchemy ORM。前者主要包括SQL语言表达式、数据库引擎、连接池等，其目的是为了实现连接不同的后台数据库、提交查询和更新SQL请求去后台执行。SQLAlchemy ORM提供数据映射模式，也就是把程序语言的对象数据映射成数据库中的关系数据，或者把关系数据映射成对象数据。</p>    <p>需要注意的是，如果程序用了对象关系映射器，虽然好处极多，但程序性能会受到一定影响。因此，对象关系映射是一个可选的模块，而开发人员即便不用任何对象关系映射也能直接用SQLAlchemy操作数据。</p>    <p>三．RESTful API和WSGI</p>    <p>OpenStack项目都是通过RESTful API向外提供服务，这使得OpenStack的接口在性能、可扩展性、可移植性、易用性等方面做到了比较好的平衡。</p>    <p>1.什么是REST ful API</p>    <p>如果一个软件架构符合REST原则，我们就称它为RESTful架构。</p>    <p>RESTful架构的一个核心概念是“资源”。从RESTful的角度看，网络中的任何东西都是资源。它可以是一段文本、一张图片、一首歌曲、一种服务等，每个资源都对应于一个特定的URL，并用它进行标示，访问这个URL就可以获得此资源。</p>    <p>资源可以有多种具体的表现形式，也就是资源的“表述”（Represent），比如一张图片可以是JPEG格式也可以是PNG格式，URL代表的是资源实体，而不是表现形式。</p>    <p>客户端和服务端之间的互动传递就是资源的表述。我们上网浏览网页，就是在调用资源的URL，获取它不同表现形式的过程，这种互动只能使用无状态协议HTTP，也就是说，服务端必须保存所有的状态，客户端可以使用包括GET、POST、PUT和DELETE这些在内的基本操作，使服务端上的资源发生“状态转移”，也就是所谓的“表述性状态转移”</p>    <p>2.RESTful路由</p>    <p>Openstack各个项目都提供了RESTful架构的API作为对外提供的接口，而RESTful架构的核心是资源和资源上的操作。也就是说，OpenStack定义了很多的资源，并实现了针对这些资源的各种操作函数。</p>    <p>当OpenStack 的API服务进程接收到客户端的HTTP请求时，一个所谓的路由模块会将请求的URL转换成相应的资源，并路由到合适的操作函数上。OpenStack使用的路由模块是Routers。</p>    <p>比如，当我们执行“neutron router-list”命令时，Neutron客户端（neutron_client）将这个命令转换成HTTP请求发送给Neutron的server服务进程，然后被路由到下面代码中的“index”操作。</p>    <pre>  # neutron/api/v2/router.py  43 class Index(wsgi.Application):   44     def __init__(self, resources):   45         self.resources = resources   46    47     @webob.dec.wsgify(RequestClass=wsgi.Request)   48     def __call__(self, req):   49         metadata = {'application/xml': {'attributes': {   50                     'resource': ['name', 'collection'],   51                     'link': ['href', 'rel']}}}   52    53         layout = []   54         for name, collection in self.resources.iteritems():   55             href = urlparse.urljoin(req.path_url, collection)   56             resource = {'name': name,   57                         'collection': collection,   58                         'links': [{'rel': 'self',   59                                    'href': href}]}</pre>    <p>3.什么是WSGI</p>    <p>RESTful只是软件设计的风格而不是标准，Web服务中通常使用基于HTTP的符合RESTful风格的API。而WSGI（Web服务器网关接口）则是Python语言中所定义的Web服务器和Web应用程序之间的通用接口标准。</p>    <p>WSGI是一个网关，作用是在协议之间进行转换。也就是说，WSGI是一座桥梁，桥梁的一端称为服务端或者网关端，另一端称为应用端或者框架端。当处理一个WSGI请求时，服务端为应用端提供上下文信息和一个回调函数，应用端处理完请求之后，使用服务端提供的回调函数返回相对应的请求响应。</p>    <p>作为一个桥梁，WSGI将Web组件分成了三类，Web服务器（WSGI Server）、Web中间件（WSGI Middleware）与Web应用程序（WSGI APPlication）。WSGI Server接收http请求，封装一系列的环境变量，调用注册的WSGI Application，最后将响应返回给客户端。</p>    <p>WSGI Application是一个可被调用的Python对象，它接受两个参数，通常为environ和start_response。如下一个Neutron项目中关于Server的功能测试列子：</p>    <pre>  # neutron/tests/functional/test_server.py  177     def application(environ, start_response):  178         """A primitive test application."""  179   180         response_body = 'Response'  181         status = '200 OK'  182         response_headers = [('Content-Type', 'text/plain'),  183                             ('Content-Length', str(len(response_body)))]  184         start_response(status, response_headers)  185         return [response_body]</pre>    <p>其中，参数environ指向一个Python字典，WSGI Application可以从environ字典中获取相对应的请求及其执行上下文的所有信息。而参数start_response指向一个回调函数，如下所示一个Neutron项目中关于WSGI的单元测试列子：</p>    <pre>  # vim neutron/tests/unit/test_wsgi.py  161         def hello_world(env, start_response):  162             if env['PATH_INFO'] != '/':  163                 start_response('404 Not Found',  164                                [('Content-Type', 'text/plain')])  165                 return ['Not Found\r\n']</pre>    <p>字符串“404 Not Found”用于表示请求响应的状态，“’Content-Type’, ‘text/plain’”是一个分别代表了header_name，header_value的元组列表。也就是HTTP响应中的http报头和内容。</p>    <p>WSGI中间件同时实现了服务端和应用端的API，因此可以在两端之间起协调沟通作用，在服务端看来，中间件就是一个WSGI应用；在应用端看来，中间件则是一个WSGI服务器。</p>    <p>WSGI中间件可以将客户端的HTTP请求，路由给不同的应用对象，然后将应用处理后的结果返回给客户端。自然，我们也可以将WSGI中间件理解为服务端和应用端交互的一层包装，经过不同中间件的包装，便具有不同的功能，比如URL路由分发，再比如权限认证，这些不同中间件的组合便形成了WSGI的框架，比如Paste。</p>    <p>4.什么是Paste</p>    <p>OpenStack使用Paste的Deploy组件来完成WSGI服务器和应用的构建，每个项目源码的etc目录下都有一个Paste配置文件，比如Neutron中的/etc/neutron/api-paste.ini，部署时，这些配置文件会被复制到系统的/etc/Project_name目录下。Paste Deploy的工作便是基于这些配置文件。</p>    <p>Paste配置文件分为多个Section，每个Section以type:name的格式命名。使用Paste Deploy的主要目的是从配置文件中生成一个WSGI Application，有了配置文件之后，只需要使用下面的调用方式。</p>    <pre>  from paste.deploy import loadapp  wsgi_app = loadapp(‘config:/path/to/config.ini’)</pre>    <p>5.什么是WebOb</p>    <p>除了Routers与Paste Deploy外，OpenStack中另一个与WSGI密切相关的是Webob。Webob通过对WSGI的请求与响应进行封装，来简化WSGI应用的编写。</p>    <p>6.什么是Eventlet</p>    <p>Openstack中的绝大部分项目都采用了协程模型。在操作系统看来，一个Openstack服务只会运行在一个进程中，但在这个进程中，OpenStack巧妙的地利用了Python的网络库Eventlet产生出许多个协程（绿色线程），这些协程之间只有在调用到了某些特殊的Eventlet库函数的时候（比如睡眠sleep、I/O调用等）才会发生切换。</p>    <p>与线程类似，协程也拥有自己独立的栈和局部变量，同时，又与其他协程共享全局变量。协程与线程的主要区别是，多个线程可以同时运行，而同一时间内只能有一个协程在运行，无须考虑很多锁的问题。</p>    <p>使用线程时，线程的执行完全由操作系统控制，而使用协程时，协程的执行顺序、时间完全由程序自己决定，由于工作方式为主动模式，所以可以最大化的利用CPU性能。协程的实现主要是在协程休息时把当前的寄存器保存起来，然后重新工作时再将其恢复过来，因此，协程可以理解为一个线程内的伪并发方式（并发也就是指创建多个绿色线程）。</p>    <p>7.什么是AsynclO</p>    <p>目前，OpenStack社区正在考虑使用AsyncIO来代替Eventlet。AsyncIO可以看做是许多第三方Python库的超集，包括Twisted、Eventlet等。</p>    <p>三．OpenStack通用库Oslo</p>    <p>1.Cliff</p>    <p>Cliff，是OpenStack中用来帮助构建命令行程序的通用库。主程序负责基本命令行参数的解析，然后调用各个子命令去执行不同的操作。</p>    <p>2.oslo.config</p>    <p>oslo.config通用库用于解析命令行和配置文件中的配置选项。</p>    <p>3.oslo.db</p>    <p>oslo.db是针对SQLAlchemy访问的对象。</p>    <p>4.oslo.i18n</p>    <p>oslo.i18n是对Python gettext模块的封装，主要用于openstack字符串的翻译和国际化。</p>    <p>5.oslo.messaging</p>    <p>oslo.messaging通用库为openstack各个项目使用RPC和事件通知提供了一套统一的接口。</p>    <p>为了支持不同的RPC后端实现，oslo.messaging对如下的对象进行了统一：</p>    <p>Transport</p>    <p>Transport传输层主要实现RPC底层的通信，比如Socket以及事件循环、多线程等其他功能。</p>    <p>Target</p>    <p>Target封装了指定某一个消息最终目的地的所有消息。</p>    <p>Server</p>    <p>一个RPC服务器可以暴漏多个endpoint，每个endpoint包含一组方法。</p>    <p>RPC Client</p>    <p>通过RPC Client可以远程调用RPC Server上的方法，有cast和call两种远程调用方式。</p>    <p>Stevedore</p>    <p>在Python代码运行时动态发现和载入所谓的插件“Plugin”，使得程序更容易的扩展，Python库Stevedore就是在setuptools的entry points基础上，构造了一层抽象层。使用Stevedore实现程序动态载入插件的过程主要分为三个部分：插件的实现；插件的注册，以及插件的载入。</p>    <p>Taskflow</p>    <p>通过Taskflow通用库，可以更容易的控制任务（Task）的执行。Task、flow和engine是Taskflow中的几个基本概念。</p>    <p>Task是Taskflow库中拥有执行（execute）和回滚（revert）功能的最小单位（实际最小单位是atom，其他所有类包括task类都是Atom类的子类），然后新建一个线性流flow。而engine用来载入一个flow，然后驱动该flow中的task/flow运行。</p>    <p>Cookiecutter</p>    <p>开发人员，可以使用openstack的Cookiecutter通用库模板，新建一个符合惯例的openstack项目。</p>    <p>Oslo.policy</p>    <p>Policy用于控制用户的权限，能够执行什么样的操作，openstack的每个项目中都有一个/etc/project_name/policy.json文件，可以通过配置该文件来实现对用户的权限管理。将policy操作的公共部分提取出来，便形成了oslo.policy通用库。</p>    <p>Oslo.rootwrap</p>    <p>Oslo.rootwrap可以让openstack服务以root身份去执行一些shell命令。一般来说openstack的服务都是以普通用户的身份去运行的，但是当他们需要以root身份去执行一些shell命令时，便需要利用到oslo.rootwrap的功能。</p>    <p>Oslo.test</p>    <p>Oslo.test库是openstack中提供单元测试的基础框架或通用库。Oslo.test基于testtools库定义了oslotest.base.BaseTestCase类，可以作为其他openstack项目单元测试的基类。</p>    <p>比如，在下面的neutron/tests/unit/api/v2/test_resource.py文件中：</p>    <pre>  28 class RequestTestCase(base.BaseTestCase):   29     def setUp(self):   30         super(RequestTestCase, self).setUp()   31         self.req = wsgi_resource.Request({'foo': 'bar'})   32   33     def test_content_type_missing(self):   34         request = wsgi.Request.blank('/tests/123', method='POST')   35         request.body = b"<body />"   36         self.assertIsNone(request.get_content_type())   37   38     def test_content_type_with_charset(self):   39         request = wsgi.Request.blank('/tests/123')   40         request.headers["Content-Type"] = "application/json; charset=UTF-8"   41         result = request.get_content_type()   42         self.assertEqual(result, "application/json")</pre>    <p>使用BaseTestCase作为基类时，单元测试中创建的所有临时文件都会被存放在一个单独的目录中，此时系统环境变量HOME也会被设置成一个临时的目录。</p>    <p>BaseTestCase类提供了方法create_tempest（）来创建临时文件：</p>    <pre>  Create_tempfiles(files, ext=’.conf’)  参数：files(元组的列表)，包含了类似（文件名、文件内容）的元组列表        ext（字符串），新建的文件扩展名  返回：所有新建的文件名列表</pre>    <p>oslo.test通用库除了提供上面的基类之外，还提供了两个通用的fixture，oslotest.mockpatch和oslotest.moxstubout供其他Openstack项目开发单元测试用例。不过，一般建议使用oslotest.mockpatch。比如：</p>    <p>Oslotest通用库提供了一个debug脚本用来支持在测试中使用pdb。</p>    <p>1)在代码中设置调试：</p>    <pre>  import pdb; pdb.set_trace()</pre>    <p>2)在Openstack项目的tox.ini配置文件中加入如下行：</p>    <pre>  [ testenv:debug]  commands = oslo.debug_helper.sh {posargs}</pre>    <p>3)运行类似下面的命令来触发断点，进入Python debugger：</p>    <pre>  # tox –e debug  # tox –e debug 程序模块名.类名.方法名</pre>