OpenERP Server Developers Documentation之Architecture（1）

结构

OpenERP作为多用户三层体系架构

这部分介绍了OpenERP结构体系和应用程序的技术细节。这里提出了组成OpenERP的层。也提供了应用程序之间的通信方式和协议。一些关于开发语言和技术栈稍后总结。

OpenERP是一个多租户，三层体系结构：数据库层用户数据存储，应用程序层用户处理和功能，和展现层用于用户界面。这些在OpenERP内分开的层。应用层是一个核心；可安装更多的模块来创建独特的实例满足特定的需求。更多地，OpenERP遵循MVC结构模式。

OpenERP的一个典型部署如图1所示。这种模式称作web嵌入式部署。一个OpenERP系统由三个主要组件组成：

•          一个PostgreSQL数据库服务包含了所有的OpenERP数据库。数据库包含了所有的应用数据，也包含了OpenERP系统配置元素的大部分。注意这个服务可以配置成集群方式
•         OpenERP服务，包含所有的业务逻辑并且确保OpenERP以最佳的方式运行。服务器的一层用来与数据库层（PostgreSQL ORM引擎）通信和交互，另一层用来与服务器与web浏览器之间通信，即web层。拥有更多的服务器是可能的，例如为了更好地性能使用负载均衡机制
• 运行在web浏览器上的客户端使用js应用程序

数据库服务器和OpenERP服务器可以安装在同一台计算机上，或者分布在不同的服务器上，为了更好地性能。

下一部分详细介绍OpenERP结构的不同层。

PostgreSQL 数据库

OpenERP的数据层由PostgreSQL关系型数据库提供。直接的sql查询可以在OpenERP模块中查询，大多数关系型数据库的访问是通过服务器ORM层完成。

数据库包含所有的应用程序数据，并且大多数OpenERP系统配置元素。注意这个服务器可以配置成集群模式。

OpenERP server

OpenERP提供了一个应用程序服务来指定构建的业务应用程序。在那些功能中，OpenERP的ORM提供了此功能和在PostgreSQL服务上的一个接口。其也提供了一个指定的层，设计来与基于客户端的web浏览器通信。这层使用标准浏览器连接用户到服务器。

从开发这角度看，服务器扮演着函数库给上面带来便利的同时隐藏了低层次的细节，并且以一种很简单的方式来安装，配置和运行所写的应用程序。服务器也包含了其他的业务，比如可扩展的数据模型和视图，工作流引擎或报表引擎。然而，那些是OpenERP的业务，与安全没有特别相关，因此不在这个文档中讨论。

Server-ORM

ORM层是OpenERP中很重要的一层。其在PostgreSQL服务上提供了额外的和基本的功能。数据模式使用Python描述并且OpenERP使用ORM创建底层数据库表。所有的RDBMS的优点比如唯一性约束，完整性限制，或者高效查询等都由Python灵活地完成。例如，Python写的任意约束可以添加到任一的模型上。不同模块的扩展机制也通过OpenERP提供。

在尝试通过ORM并且借助sql语句直接访问底层数据库之前理解ORM的责任是很重要的。当使用ORM时，OpenERP能确保没有任何脏数据。例如，一个模块会影响特定表中数据的创建。这种行为的发生是在通过ORM查询的时候。

通过ORM获取的服务包含其他：

• 通过强大有效检查的一致性校验
• 提供一个对象（方法，引用）接口，允许设计和实现高效模块
• 每个用户和组的行级安全机制
• 资源分组中复杂的action
• 继承业务 允许新资源的重新建模

Server -web

web层提供了一个接口来与标准浏览器通信。在OpenERP6.1版本中，web客户端已经被重写并集成到OpenERP的服务层。这个web层是一个WSGI相容的基于werkzeug的应用。它处理普通的查询服务器静态文件或者动态内容的http查询和来浏览器的JSON-RPC查询。

模块

自身来讲，OpenERP服务是核心。对于许多企业来讲，OpenERP的值取决于它的不同模块。模块的角色用来实现任何业务需求。这个服务只是一个增加模块的必要组件。任何发布的办公化的OpenERP包含了大量组件这样的组件包括：CRM，HR，Marketing，MRP，Sale，等等

客户端

由于应用程序逻辑主要在服务器端，客户端就比较简单。其发出到服务器的请求，获取数据并显示结果（用不同的方式比如列表，树，表单，甘特图。。。）。根据用户操作，其发送到服务器修改数据的查询。

OpenERP的默认客户端是一个运行在浏览器的JS应用程序，与服务器之间通过JSON-RPC通信。

OpenERP中的MVC结构

MVC是软件开发中的结构模式。在复杂的软件应用程序中，提供给用户大量的数据，人们希望分离数据（model）和用户接口（视图）。用户接口的改变不会影响数据管理，并且数据可以重新组织而不需要改变用户接口。mvc模式解决了这个问题，通过数据访问和来自提供数据和用户接口的业务逻辑的解耦，通过介绍一个中间件：controller

在上面的图中，从controller出发的实线部分箭头分别指向View和Model，意味着controller可以完全访问View和Model。从View到Controller的虚线箭头表示View访问Controller受限制，这样设计的原因是：

•          从View到Model：当它的数据已经修改为了重新在视图上绘制内容时model发送消息到视图。model不需要知道view的内部工作机理来执行这个操作。然而，view需要访问model内部
•         从View到Controller：view受限访问Controller的原因是因为从View到Controller的依赖需要是最低限度的：Controller可以在任何时候被替换。

OpenERP按照MVC语义：

•         model：PostgreSQL模式
•         view：在OpenERP中用XML文件定义的视图
•         controller ：OpenERP的对象

网络通信和WSGI

OpenERP是一个HTTP web服务并能按照WSGI应用部署。

客户端可能使用无会话的XML-RPC与OpenERP通信，推荐方式是与OpenERP的交互操作。基于web客户端的通信使用会话可意识的JSON-RPC。

OpenERP中每件事情，包括方法对象都是通过网络和安全层暴露出来。数据模型的访问实际上是一个业务并且可能暴露更多的新的业务。例如，WebDAV 业务和FTP 业务是可用的。

业务可以利用WSGI堆。WSGI在Python的生态系统中是一个标准放来，用来写HTTP服务器，应用程序，和用于混合搭配的中间件。使用WSGI，在任何遵循WSGI的服务上都能够运行OpenERP。也能使用OpenERP做WSGI应用程序的主机。

一个例子是OpenERP的web层，针对文本客户端的计数部分。其给浏览器提供请求的数据并且管理web会话。其是一个遵循WSGI的应用程序。因此，其可以运行在单独的HTTP服务器或者嵌入到OpenERP内。

Process model（模型处理）

在过去，OpenERP服务器使用线程来处理当前HTTP请求或者处理cron工作。当运行openerp-server脚本时仍旧用线程处理但不是推荐的：最好使用--workers选项。

使用--workers选项，OpenERP将创建固定数量的进程而不是对于每个请求创建一个线程。

这样有很多好处：

• 进程不会遭遇CPython的全局解释锁。
• 当请求仍旧由服务器处理时进程能够最大限度的循环使用
• 对于进程的ＣＰＵ时间和内存资源，能够在每个进程基础上进行监控。

当使用--workers时，将产生两类进程：web进程和cron进程。

7.1版本中新功能

当使用--workers，将产生三类进程：web进程，cron进程和基于事件的web进程。通过即时通信功能按需进行长轮询。至于现在，这个进程坚挺不同的端口而不是主要的web进程。一个反向代理（比如nginx）监听唯一的端口，映射所有的请求到一个普通的端口，但是按照/longpolling路径映射到事件进程是必须的（web接口不能发送请求道不同的端口）

通过--gevent标示使线程服务器变为基于事件的服务。

目标是支持线程模型，并且也使得所有的线程基于事件；这里在普通和长轮询进程之间没有更多的差别。对于这种情况，需要更多的测试。