erp应用

第三大erp软件

　　在企业当中成功构建起大规模领先项目是IT领导者必须具备的一项关键能力。因此无论是对ERP进行升级或是改善其网络基础架构，培养员工知识水平抑或是进行项目迁移，您都需要着眼于各个层面确保企业能够借此保持竞争优势。

　　erp系统很多操作都要求事务性，你拆分系统后怎么实现事务性，保障数据一致性呢?

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

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

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