erp系统构架

　　当今互联网思维。泛普软件问题不要再去做一个大一统的系统了。我们要分拆一个大系统，做成一个个小系统。然后通过系统接口让这些小系统相互通信。这样来组成一个大系统，具体来说就是“分布式”、“服务化”的互联网思维。让系统在架构设计上就是一个先天支持高度可扩展的系统。

　　怎么做呢?具体来说就是要将订单管理、商品管理、生产采购、仓库管理、物流管理、财务管理拆分成一个个子系统。这些子系统可以单独设计开发，对外暴露出各种其他子系统需求的数据接口即可。每个子系统都有单独的数据库。甚至这些子系统可以交由不同的团队去开发和维护，使用不同的技术体系，使用不同的数据库。而不是再像以前那样，都集成在同一个大而全的系统中，一个大而全的数据库。

　　对于新架构的系统他有什么优点呢?

　　首先，也是最重要的就是解决系统的性能问题。以往数据库实例只有一个，没法扩展出多个实例，以便在性能受限的情况下依靠增加数据库实例来达到负载均衡。也许有人会说可以使用读写分离方案，但是因为 erp系统的特点，这个方案很多时候不现实。比如说操作库存的时候，你不能从读库里读库存，然后在写库里写入库存。因为主从复制会有时效性，写入的库存并不能马上写入从库。这样的场景在ERP中也有多处。何况写库不能扩展，只能有一个。而新设计方案是写库是分离的，每个子系统有自己的数据库。

　　其次，就是更新非常方便，各个子系统以后台微服务的方式存在。前台一个单独的web项目，这个web项目调用后台这些子系统的服务接口。这样的设计，在某个业务子系统需要更新的时候，可以单独更新。不用像以前那种单进程架构时，一个小更新需要整个系统重启，导致用户会话也丢失，用户需要新登录。而现在的这种设计就不会有这个问题。

　　泛普erp系统整体架构设计

　　详细设计

　　拆分应用层

　　拆分应用层，是践行“微服务”架构的理念。将原来大而全的单进程架构按照业务模块拆分成可独立部署的应用程序，以此来达到平滑系统更新、升级、方便负载扩展的目的。具体来说，技术上可以使用restfull风格的接口，也可以使用像java中dubbo框架方式来简化开发复杂度。ERPWeb端或其他移动端也是一个单独的应用充当表现层。非常薄，只是简单的接受参数，调取后台其他各种微服务程序的接口获取所需展示的数据。微服务充当业务逻辑层，每个微服务都是可独立部署上线的程序，对外提供数据访问接口。

　　微服务可以使用流行的各种RPC框架，比如dubbo，可以支持多种调用协议Http、TCP等，这些框架使得编码比较容易，框架封装底层数据通信细节，使得客户端执行远程方法如同执行本地方法一样简单。

　　dubbo微服务架构，还支持服务治理，负载均衡等功能。这样不仅可以提高系统的可用性，还能动态提升系统应用层的性能。比如仓库管理中入库业务非常繁忙，占用非常多的CPU和内存资源，我们可以另外加一台机器，单独再部署一个仓库管理服务上去。这样使得整个系统，有两个仓库管理服务在同时工作，平衡负载。而这一切都是在服务注册中心，比如Zookeeper下自动完成的。

　　微服务结构，天生很好的支持系统更新升级操作。比如财务模块有个新需求需要上线，我们只需要替换财务模块的服务重启即可。这对已经登录系统的用户来说，没有多少影响，不用重新登陆系统，其他模块服务使用也不受影响。

　　拆分数据层

　　数据库瓶颈是ERP系统的永久之伤。大量复杂的数据查询表连接逻辑充斥着整个系统。数据库垂直拆分成功的关键就是如何重新设计系统数据层各个模块相互耦合的问题。能解决这个问题，永久之伤便可以解决了。

　　分布式事务

　　也许有人又又问了，ERP系统很多操作都要求事务性，你拆分系统后怎么实现事务性，保障数据一致性呢?

　　这个问题很好，也是我决定写这篇文章前思考的最后一个问题。在微服务架构中，实现夸服务的事务并不容易，至少不像本地应用使用本地数据库事务那样方便，性能高效，数据一致性好。

　　也许你听过分布式事务这个概念。有两种情景，一种是一个应用中使用多个数据库，为保障数据一致性，需要使用分布式事务。还有一种情况就是针对我们这个架构而言的。微服务环境下的分布式事务，具体来说打个比方。采购入库这个操作设计在仓库管理服务中。入库后，需要更新采购子系统中的采购单中的入库数量。这个过程要求数据一致性，也就是采购单入库成功后写入了库存表中的数量，同时要更新采购单表中的入库数量。我们不能直接在仓库服务中去访问采购服务中的数据库，必须通过采购服务提供的服务接口才行。如果这样，我们怎么能保证数据一致性呢?因为很有可能库存表写入成功，但调取采购服务写入采购单数据时失败了。可能是网络问题原因导致的，这样数据就不一致了。

　　在分布式事务技术中，有实现最终一致性这么一说，意思就是只要我能保证两边数据最终实现了一致性就行，不一定要使用事务。这样说来就有方案了。如仓库子系统在处理采购入库时需要增加入库单数据和更新库存数据等多个表。这多个表都在仓库子系统中，我们可以使用一个本地事务来保证仓库子系统中的表数据一致性。然后调用采购子系统更新采购单里的入库数量。为了防止这个过程突然中断导致调用失败，我们考虑增加一个消息队列中间件如ActiveMQ。如果接口返回失败我们就往MQ里写入这个处理请求，等到采购子系统恢复正常后，MQ通知采购子系统处理这个更新操作。由于消息消费掉以后不会再有通知了，采购子系统处理过程中发生异常导致更新失败，需要将问题写入本地的日志库，以便通知管理员做后续补偿处理。就这样通过各种办法来达到数据的最终一致性即可。虽然听上去有点坑，但这就是解决方案。没有其他更好的了。或者更新失败后重新调用仓库子系统回滚入库单和库存数据，达到最终一致性!

发布：2021-05-08 13:54 编辑：泛普软件 · hujian [打印此页] [关闭]

erp系统构架

相关栏目