odoo SAAS高可用架构部署,性能扩展安全增强

  • A+

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 实现多线程,多协程。同时支持多进程启动

这些通用且以开源为核心的架构,保证了其具备很好的可扩展性,可以方便的进行集群及高可用部署。

在本应用场景中,管理方为集团公司,下属多个子公司。每个子公司对自有b2b,b2c客户提供移动电商批发零售服务,每个子公司对自有供应链业务进行管理。每个b2b客户再通过门店收银为最终b2c消费者提供零售服务。平台顶层,由集团公司同时统一管理所有客户及产品,并通过odoo制定业务规则,以规范子公司以及b2b客户的日常运营。系统要达到保障百万级别用户在线,实现快速响应,热备份,热更新,动态扩展等要求。

 

  1. 消费者/零售商户

即我们的b2b, b2c客户,这些客户通过使用省内的线下门店、odoo开发的App、微信小程序及电商平台进行批发零售采购。基于互联网访问。

  1. 供货商

为平台提供端口的供应商,与1类似,通过App、微信小程序及网站来管理商品及发货。基于互联网访问

  1. 平台管理方

平台业主,包括集团用户与子公司的用户,主要通过odoo管理业务。基于内网或者通过VPN进入内网,访问平台。

  1. 互联网

基于odoo建立的门户网站,以及基于odoo接口实现的App或者微信小程序,都是通过互联网提供服务,odoo仅通过互联网提供接口服务,供客户端调用,相关管理后台功能不通过互联网开放。

  1. 防火墙

防火墙进行安全隔离,企业可以自行定制相关策略,防范网络攻击等。

  1. VPN+安全策略

核心平台部署于集团IDC,odoo的后台业务管理服务仅向内网用户提供,故所有子公司及相关管理用户,只可通过内网或者VPN登入内网,才可进行业务管理。

  1. 前端服务群组

前端服务器群组一般包括反向代理服务器和负载均衡服务器。

我们使用Nginx反向代理服务器,odoo通过Nginx对外提供Web服务,一般1主1备实现高可用即可,同时可以构建Nginx集群提供更好的性能。相关的SSL证书也通过Nginx进行配置以保证连接安全。

当使用多Nginx服务器后,我们需要增加负载均衡服务器如F5等进行用户动态分配。

使用Nginx作为前端有另外一个好处,就是当平台需要符合国家的网络安全等级保护要求时,很多内容通过Nginx即可进行。

  1. 核心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服务即可。

  1. CDN/文件服务群组

为提高性能,静态文件可使用专门的CDN或文件服务器存储,可以使用自有CDN或者云服务商的CDN。

我们可能自行决定哪些静态文件进行CDN处理,一般包括:css,js, 字体,图片,系统附件等。

  1. 数据缓存集群

Odoo本身有数据缓存机制,Postgresql也有内置数据缓存机制。为了更高的数据读取性能,我们可以增加部署Redis,作为PostgreSQL的二级缓存, 提升数据库的性能,减少IO请求。

此功能需要进行一定的二次开发,控制数据读取。一般乐观数据如商品品类等基本不变化的我们从redis中取。悲观数据比如商品要记录其浏览量,加购物车量的,我们从数据库中取。

Redis可以进行集群部署,细节可自行查询相关文章。

  1. 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数据库连接件。
  • 商业产品

相关方案比较多,可自行查阅。

  1. 运维监控服务

一般业主都有自己的基础运维体系,odoo使用的都是通用平台,所以可以很方便的将上述基础架构纳入集团整体IT运维架构中。

以下做些简述。

  • 12.1 备份

定期数据库备份。

定期应用服务及配置备份。

基于GIT的代码版本管理,release管理。

  • 12.2 主机监控

将上述主机纳入监控平台。

  • 12.3 日志与审计

Odoo业务数据的变更自带审计功能,用好即可。

系统运行的Log最好不使用操作系统的Log,通过配置,记录到单独的数据库中,做好预警管理。

其它具体运维参照业主方SLA标准实施即可。

 

以上,作为Odoo高可用架构部署的参考,以帮助我们支持海量用户与海量数据,提高性能、稳定性及安全性。

 

发表评论

您必须才能发表评论!