原文可参考，更好的阅读体验：
https://www.sunpop.cn/odoo_saas_high_performant_ha_redis/
Odoo是一个全功能ERP平台，也是一个在线服务门户。随着odoo越来越流行，已经有了大量的海量部署。
比如官方的500万用户和每个月上百的企业SAAS用户，国内某odoo电商App的500万+注册用户等，我们为客户支持的在线应用，也达到了十万用户级别。海量数据应用更是比比皆是，国内使用odoo的上市公司，特别是制造行业，其SKU数量都在数十万级以上。
替代文字
为更好的支持海量用户及海量数据，我们需要进行odoo的高可用性部署，以达到高性能，高稳定性，高扩展性，高安全性。我们以一个多租户电商供应链门户应用为例，简述高可用架构的部署。由于odoo本身就是一个B/S架构的应用，所以本架构也可以适用于所有的odoo部署。
odoo采用了业界流行的基础架构，包括：
操作系统：Linux，官方推荐Ubuntu
数据库：Postgresql
Web服务器：内置 Werkzeug，前端一般通过Nginx，Apache等代理
前端：基于JavaScript的富客户端，通过Json-rpc调用后台数据。技术基于Jquery + backbone + owl(odoo14开始采用的mvvm架构)
后台：Python 3.6 +，使用threading + gevent 实现多线程，多协程。同时支持多进程启动
这些通用且以开源为核心的架构，保证了其具备很好的可扩展性，可以方便的进行集群及高可用部署。
在本应用场景中，管理方为集团公司，下属多个子公司。每个子公司对自有客户、自有供应链业务进行管理，集团公司同时统一管理所有客户及产品，并通过odoo制定业务规范管理日常运营。
消费者/零售商户
即我们的b2b, b2c客户，这些客户通过使用odoo开发的App、微信小程序及电商平台。基于互联网访问。
供货商
为平台提供端口的供应商，与1类似，通过App、微信小程序及网站管理商品及发货。基于互联网访问
平台管理方
平台业主，包括集团用户与子公司的用户，主要通过odoo管理业务。基于内网或者通过VPN进入内网，访问平台。
互联网
基于odoo建立的门户网站，以及基于odoo接口实现的App或者微信小程序。通过互联网提供服务，odoo仅通过互联网提供接口服务，供客户端调用，相关管理后台功能不通过互联网开放。
防火墙
防火墙进行安全隔离，企业可以自行定制相关策略，防范网络攻击等。
VPN+安全策略
核心平台部署于集团IDC，odoo的后台业务管理服务仅向内网用户提供，故所有子公司及相关管理用户，只可通过内网或者VPN登入内网，才可进行业务管理。
前端服务群组
前端服务器群组一般包括反向代理服务器和负载均衡服务器。
我们使用Nginx反向代理服务器，odoo通过Nginx对外提供Web服务，一般1主1备实现高可用即可，同时可以构建Nginx集群提供更好的性能。相关的SSL证书也通过Nginx进行配置以保证连接安全。
当使用多Nginx服务器后，我们需要增加负载均衡服务器如F5等进行用户动态分配。
使用Nginx作为前端有另外一个好处，就是当平台需要符合国家的网络安全等级保护要求时，很多内容通过Nginx即可进行。
核心odoo服务集群
Odoo设计时就考虑了集群及多租户情况。按实际业务情况，我们可以分为多个odoo服务集群，将应用负载分离，以保证高性能。
每个集群可以由多台odoo服务器组成，这样当某台odoo故障下线时，其它odoo服务器可以承担服务，以保证高可用。
这些服务器通过7中的前端服务器群组进行任务分配，一般这些服务器集群我们会在DMZ区进行更好的安全保障。
8.1 核心odoo服务集群
提供系统核心服务，包括对外部App接口，对内部的业务管理。
8.2 定时任务odoo服务集群
Odoo的定时任务即Cron，我们一般是用来进行业务计算或者数据同步的。比如同步其它系统的用户、商品信息，同步天猫/Amazon的订单信息，定期与支付服务商对账等。制造业中会用来做MRP计算或补货运算。
Odoo的Cron是可以单独执行的，由于这种服务可以免http服务，所以将其独立开来有助于提高性能，所以我们建立了独立的定时任务服务集群。
8.3 其它odoo服务集群
由于odoo可以多进程开启，所以我们可以根据实际业务需要，将某些应用独立开来建立单独的odoo服务器或者odoo服务器集群。
就原生功能而言，其IOT物联网服务，即时聊天是比较独立的，如有特殊性能要求，可以将其独立部署。
在本文的应用中，我们也可以将对外的接口服务，进行独立部署。
注意！当我们拆分独立的odoo应用集群时，一定要注意代码的处理，特别是本集群内的odoo服务器，要保证多台服务器间代码的一致，可以用 Linux的rsync服务即可。
CDN/文件服务群组
为提高性能，静态文件可使用专门的CDN或文件服务器存储，可以使用自有CDN或者云服务商的CDN。
我们可能自行决定哪些静态文件进行CDN处理，一般包括：css，js, 字体，图片，系统附件等。
数据缓存集群
Odoo本身有数据缓存机制，Postgresql也有内置数据缓存机制。为了更高的数据读取性能，我们可以增加部署Redis，作为PostgreSQL的二级缓存， 提升数据库的性能，减少IO请求。
此功能需要进行一定的二次开发，控制数据读取。一般乐观数据如商品品类等基于不变化的我们从redis中取。悲观数据比如商品要记录其浏览量，加购物车量的，我们从数据库中取。
Redis可以进行集群部署，细节可自行查询相关文章。
PG数据库集群
数据是企业的核心，所以数据库是平台中最重要的组成部份。Postgresql作为最主流的数据库，有多种成熟的集群方案功能。
首先在硬件层架构上，我们要尽量保证：
使用物理机而非虚拟机作为数据库服务器
使用SSD或者高转速硬盘保证高IO性能
使用Raid保证存储的高可用及高IO性能
接着进行高可用架构部署，我们的目标主要为：
读写分离，实现高性能
主备复制，实现高可用
相关方案已经很成熟，比如我们可以直接使用：
华为云方案：
https://support.huaweicloud.com/bestpractice-rds/rds_pg_0009.html
阿里云方案：
https://help.aliyun.com/document_detail/127875.htm?spm=a2c4g.11186623.2.8.202b5beeeH4Bwv#concept-1443745
他们都提供公有云或私有云的部署方案。
如果要自行建设，也有多种方案选择。
可以使用 postgresql数据库自带的基于Standby的异步流复制进行replication配置。
可以使用pgpool，这是个应该是最流行的一个集连接池、主备切换与负载均衡于一身的pg数据库连接件。
商业产品
相关方案比较多，可自行查阅。
运维监控服务
一般业主都有自己的基础运维体系，odoo使用的都是通用平台，所以可以很方便的将上述基础架构纳入集团整体IT运维架构中。
以下做些简述。
1 备份
定期数据库备份。
定期应用服务及配置备份。
基于GIT的代码版本管理，release管理。
2 主机监控
将上述主机纳入监控平台。
3 日志与审计
Odoo业务数据的变更自带审计功能，用好即可。
系统运行的Log最好不使用操作系统的Log，通过配置，记录到单独的数据库中，做好预警管理。
其它具体运维参照业主方SLA标准实施即可。
以上，作为Odoo高可用架构部署的参考，以帮助我们支持海量用户与海量数据，提高性能、稳定性及安全性。
