在叙述具体方案前,先说下自己的想法。我首先觉得我们做ERP软件系统前,就得有当今互联网思维。我们不要再去做一个大一统的系统了。我们要分拆一个大系统,做成一个个小系统。然后通过系统接口让这些小系统相互通信。这样来组成一个大系统,具体来说就是“分布式”、“服务化”的互联网思维。让系统在架构设计上就是一个先天支持高度可扩展的系统。
怎么做呢?具体来说就是要将订单管理、商品管理、生产采购、仓库管理、物流管理、财务管理拆分成一个个子系统。这些子系统可以单独设计开发,对外暴露出各种其他子系统需求的数据接口即可。每个子系统都有单独的数据库。甚至这些子系统可以交由不同的团队去开发和维护,使用不同的技术体系,使用不同的数据库。而不是再像以前那样,都集成在同一个大而全的系统中,一个大而全的数据库。
对于新架构的系统他有什么优点呢?
首先,也是最重要的就是解决系统的性能问题。以往数据库实例只有一个,没法扩展出多个实例,以便在性能受限的情况下依靠增加数据库实例来达到负载均衡。也许有人会说可以使用读写分离方案,但是因为ERP系统的特点,这个方案很多时候不现实。比如说操作库存的时候,你不能从读库里读库存,然后在写库里写入库存。因为主从复制会有时效性,写入的库存并不能马上写入从库。这样的场景在ERP中也有多处。何况写库不能扩展,只能有一个。而新设计方案是写库是分离的,每个子系统有自己的数据库。
其次,就是更新非常方便,各个子系统以后台微服务的方式存在。前台一个单独的web项目,这个web项目调用后台这些子系统的服务接口。这样的设计,在某个业务子系统需要更新的时候,可以单独更新。不用像以前那种单进程架构时,一个小更新需要整个系统重启,导致用户会话也丢失,用户需要新登录。
系统整体设计
系统物理部署视图
24th Jun 2020
24th Jun 2020
24th Jun 2020
24th Jun 2020
24th Jun 2020
24th Jun 2020
24th Jun 2020
24th Jun 2020
公司新闻 | 26 |
解决方案 | 70 |
成功案例 | 65 |
管理咨询 | 80 |
评价(220)