odoo性能优化思路

odoo在大型企业遇到的挑战

性能问题

性能问题主要是架构问题和二次开发的代码质量问题，尤其是在二次开发者水平尤为明显。

横向可扩展性

• Odoo开源版本没有提供分布式集群部署。
• 大量依赖单块磁盘能力，很多东西都放在硬盘和内存中。
• 为了方便开发，做了很多便于开发部署，但不太适用生产环境的功能。
  • 主要体现在有预编译器，当CSS文件改动时，odoo自动生成代码。当在分布式集群部署时会严重影响性能。

业务需求

• 2B业态决定了大客户对你系统的影响非常大，甚至可以重塑你业务流程
• ODOO虽然可以快速开发升级，但是将大量客户强加于你功能需求写在一套代码里，势必会将你设计架构打乱
• 大量业务代码揉进一套代码里面，也势必造成性能下降和代码冗余

与异构系统的结合

• 客户用的系统
• 全公司不可能一种架构
• odoo不是万能的
  • Odoo的创建和发展都是围绕企业信息化的进行的，他擅长的领域別人没他好，在其他领域他可能又没别人好
• 一套系统干太多需要拆解
  • Odoo将很多功能都採在一套程序里面，在运行时候，性能相互影响
  • 共用一个数据库，所有功能探在一起，在后期优化和高可用不利

优化思路

性能问题

• 专业度：减少循环search查询集群数据
• 不要轻易使用IO：将数据写入磁盘，IO阻塞严重
• 减少滥用SQL：Odoo有ORM层缓存，绕过ORM层直接用SQL会导致数据库负载高
• 静态文件处理：Odoo服务改为Nginx代理服务器更优。

横向扩展性

单台机器性能总有上限，对于性能扩展和灾备来看分布式集群系统是所有大型系统首选

• 用户登录
  • 需要将每台用户登录信息进行高效的同步，目前网上已知手法有硬盘数据挂载共享和redis改装法，保证集群中每个机器记住用户登录信息
• LRU缓存
  • Odoo是带缓存的，采用的是LRU缓存，完全python实现并且是单机实现，不太利于分布式部署，通过redis化，满足一般的缓存数据一致性
• 静态文件
  • Odoo生产的css和js，原生是由数据库承担的，由odoo webserver承担访问，改造后放到一个共享磁盘中，由nginx代理出去
• 数据库集群
  • 基础的读写分离，满足大部分ERP场景，运用云厂商的数据库还可以实现灾备和任意时间点数据还原

业务需求

• 保证odoo原有设计
  • 首先要抓出业务最基础的共性，比如销告必有销售单，出库必有库存移动单据，这些基础性的东西，是不能改掉的
• 增加子系统
  • 有些业务已经改出原有odoo系统设计的流程后，但是由于是客户要求，最好方式在odoo新开模块，并与以前模块连通，保证基础数据的互通
• 增加独立子系统
  • 完全超出原有设计时，考虑再做个新的系统与odoo系统对接

兼容异构系统

• 主动调用对方接口
  • 因为odoo到现在没完全实现异步，大部分调用三方系统的性能影响很大，建议加队列和事件方式用外挂程序解决
• Odoo提供RPC
  • Odoo原生就提供RPC webserver，这帮助我们实现一些被动调用对接提供了便利