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，这帮助我们实现一些被动调用对接提供了便利