ERP之痛

起初，因为数据量不大，系统性能还不错，各种列表查询，报表查询，Excel数据导出功能等用的都很流畅。但是随着公司业务发展，订单量日积月累，后期各种业务部门的报表查询、数据导出需求不断增多，我们渐渐就感觉系统运行越来越慢。于是我们可能最先想到的解决方案就是，优化系统瓶颈数据库这个大头。我们可能的一种尝试就是将数据库单独放置到一个服务器，实现数据库和应用程序分离，或者是建立各种数据库表索引，优化程序代码等方法。经过这样一番研究优化，系统某些功能可能性能的确大大提高，但是我们还是发现某些功能列表的数据查询导出依然很慢，或者随着数据量继续积累，原来较快的列表导出功能，也愈来愈变得缓慢了。我们用尽各种办法，最后也达不到理想的系统性能速度。

为了提高系统性能，我们也许会主动学习一些互联网公司的技术经验，什么高并发、高性能、大数据、读写分离等方案，发现自己根本无从下手。我们会觉得因为系统业务特点不一样。ERP系统并发量不高，主要是业务复杂，各种业务耦合度远高于那些互联网应用，不好做拆分，数据查询逻辑要远比互联网系统复杂，一个列表页查询出来的数据，往往需要关联4、5张表才能得到结果。有些报表类的甚至更多。加上各种业务操作事务性、数据一致性要求很高，很多时候导致我们措不及手，无法进一步优化系统。

曾几何时，我也被这样或那样的理由所挫败，认为ERP系统非常特殊，无药可救，可是后来。。。

我现在已经不这么认为了，似乎有了新的解决方案O(∩_∩)O哈哈~

曙光乍现

在叙述具体方案前，先说下自己的想法。我首先觉得我们做ERP系统前，就得有当今互联网思维。我们不要再去做一个大一统的系统了。我们要分拆一个大系统，做成一个个小系统。然后通过系统接口让这些小系统相互通信。这样来组成一个大系统，具体来说就是“分布式”、“服务化”的互联网思维。让系统在架构设计上就是一个先天支持高度可扩展的系统。

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

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

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

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

系统整体设计系统物理部署视图

详细设计拆分应用层

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

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

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

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

拆分数据层

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

我们先来看一个典型数据层模块耦合问题。需求是展示物料库存，列表字段：物料编号、物料名称、品类、仓库、数量

品类和仓库表省略。。。

很显然，传统一个数据库中，我们只需要简单的join操作，即可关联这两张表，外加关联品类和仓库表即可查询出我们所要的数据。但是现在我们的架构中，物料表和商品表不在同一个数据库实例中，我们不能使用join操作了，那我们该怎么实现需求呢?

新的架构，只允许我们通过对方的服务接口来获取数据，不能直接关联对方服务的私有数据库。至少从架构上，服务化角度来说不能直接访问对方服务的数据库。这种情况下，假设web模块子系统调用仓库子系统来获取数据，则我们需要在仓库模块中创建一个service方法来装配这些数据。然后返回给web子系统。如下图所示，仓库管理方法首先获取本地库存表的物料编码、和仓库表的仓库名称字段信息，并且分页完后最终准备返回20条数据到Web模块前，将这20条数据中的物料ID作为参数请求商品模块子系统，商品子系统返回这20个物料ID相关的商品信息给到仓库管理模块，然后仓库管理模块重新组装上列表所需的物料名称和品类两个字段数据，实现最终要返回给Web子系统的数据。

也许你会说，这太麻烦了，这种方法的性能肯定没有直接join来的高，解决不了性能问题。咋看起来好像是这么回事，但是仔细考虑看看，在系统并发量低、数据量小、业务不算繁忙的环境下，的确性能还不如传统一个数据中join方式来的快速。但我们想想以后吧!我们现在的架构设计是将一个数据库拆成多个数据库，每个数据库可以运行在单独的服务器上去，这样以后就能负载数据库的压力了。整体来说这样才能不会让数据库成为未来业务繁忙时候的性能瓶颈了。想想都觉得让人兴奋不已，是不是?

这时候有人又会问，那以后系统数据量、业务更大了，连你这个拆分成几个数据库还不够用怎么办呢?我的方法是，可以基于拆分的数据库，单独每个库可以做读写分离、使用缓存等。甚至可以继续拆分下去，将子系统再次拆分成多个孙子系统。视业务模块繁忙程度而定。

报表系统

有人又会问，有些列表查询逻辑非常复杂，关联十多张表，如果按上述方法拆分数据，那简直是灾难啊!是的，你说的没有错。这种情况下我的方案是将这种更加复杂的报表级别的数据查询展示需求，可以单独做个报表系统。报表数据库设计采用数据仓库方式。为了更高的读取性能，我们可以将数据库表设计成很多冗余字段方式也就是反范式设计，以及建立非常多的组合索引。

这种系统成功的关键就是数据和主ERP系统业务库的同步问题了。一般可以写一个定时同步程序，将ERP主业务系统的数据经过帅选、转化等方式直接生成报表视图所需的最终或中间数据，简化关联查询。报表系统也可以采用微服务架构设计。如下图所示：

如果报表所需的数据要求实时的，我们可以让ERP系统业务操作时，触发同步数据的请求，实时同步至报表库。

分布式事务

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

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

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

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

非常有幸能和大家一起分享知识和经验，正是由于大家的无私分享，才让我们得以成长和进步，我最近几年来都很少分享东西，有时候是因为工作很忙没有时间写点东西，有时候也是因为自己懒或是没有什么新东西可以分享给大家的。最后也希望大家对我的分享不足之处给予批评指正，一起进步!

更多erp相关，请点击百度搜索：ERP

常见问答

随着科技的不断进步，企业的经营模式也发生着翻天覆地的变化。在高度竞争的市场环境中，如何提高企业的生产效率，提升竞争力成为了企业迫切需要解决的问题。ERP（EntERPrise Resource Planning）系统应运而生，在提高企业内部管理、降低成本、提高生产效率等方面发挥着不可替代的作用。而其中的能效等级换算，更是企业高效建设ERP的关键所在。

一、能源管理在企业管理中的重要性

随着环保意识的不断提升，企业节能降耗已成为中国制造业的必由之路。一个好的能源管理制度，不仅可以降低企业能源消耗，同时也会提高企业形象和品牌影响力。而在ERP系统中，能源管理得到了有效的融合，为企业管理者打造了一个精细化、可视化的能源管理平台。

在能源管理中，对于能效等级的换算是非常关键的。通常，能效等级指的是设备的能效等级，是通过比较该设备的功率及输入/输出的能量比例来计算得出的。而在ERP系统中，能效等级换算可以通过记录设备的运营数据，计算设备的能耗效率等多种方式来实现。这些数据可以帮助企业管理者更好地掌握设备运行的情况，优化生产流程，从而提升能效等级。

二、ERP如何实现能效等级换算

在ERP系统中，能效等级换算可以通过多种方式进行。比如可以通过对设备运营数据进行监控，通过大数据算法分析计算设备的能源利用效率。另外，也可以结合企业的设备管理系统，通过对设备的维护保养等多种因素来计算多维度的能效等级。这些方式都能够有效地实现能效等级的换算，并为企业提供全面的能源管理服务。

此外，ERP系统还可以将能效等级与成本进行关联分析，通过识别高能耗设备，优化能源结构，减少不必要的能源损耗，从而提升生产效率与企业的经济效益。

三、ERP在能源管理中的应用案例

大型制造企业在ERP系统中应用能源管理模块已经成为一种趋势，其主要原因在于能源管理能够非常好地解决企业传统的设备管理难题。例如，我国机车制造企业正常生产需要耗费大量的电力、氧气等能源，而在制造过程中数据难以收集，设备之间互不通信等瓶颈问题也非常严重。而通过应用ERP系统中的能源管理模块，制造企业可以全面掌握设备的运行情况，实现对于流程的精细化控制，有效地提升了企业的生产效率。

此外，近年来，随着企业对于环保意识的不断提升，智能能源管理也逐渐成为一个热门的发展方向。智能能源管理不仅能够监控设备的运行状态，还可以根据不同设备的需求进行能量分配，从而提升能源的利用效率，降低企业能源成本。应用智能能源管理模块，企业可以实现全面的能源管理，通过对能耗数据和能源接口的监测，达到更加智能化管理的目的。

四、ERP系统如何促进企业节能减排

ERP系统中的能源管理不仅能够推动企业的生产效率提升，同时还可以有效地促进企业的节能减排。通过实时监控和能源数据分析，企业管理者可以快速识别并解决能源浪费和巨大耗能的问题erp能效等级，实现能源的优化配置和生产流程的改进，大大降低企业的能源消耗，减少对环境的负面影响。

此外，ERP系统还可以有效促进企业节能减排，并提高企业社会责任意识。通过能源管理知识的提升，员工也可以更好地理解能源管理的重要性，在日常生产中更加注重节约能源，从而实现减少企业的碳排放，保障生态环境和社会公共利益。

五、未来ERP系统能源管理的发展趋势及趋势分析

随着人工智能技术和大数据分析技术的不断发展，ERP系统能源管理模块的发展也将更加完善和完备。未来，ERP系统的能源管理将投入更多的研究精力，以更高精度和更低成本的方式实现能源监测和能源优化，打造更加智能化的能源管理平台。

同时，在应用ERP系统的能源管理模块时，企业管理者也必须充分认识到能源管理的重要性，并合理配置相应的人力、物力和财力资源。只有有效地结合传统设备维护与智能能源管理手段，整合资源，企业才能在日常管理中共创节能环保的美好未来。

总而言之，ERP系统能源管理模块的应用已经成为制造企业实现高效建设、降低能耗、提升企业竞争力的必要手段。通过从不同维度的角度去探索ERP系统中的能效等级换算，可以让企业管理者更好地了解企业的能源利用情况，为企业的核心竞争力提升奠定坚实的基础。

企业究竟能否在竞争激烈的市场环境下立于不败之地，还需要在ERP系统能源管理模块的支持下，全员持续不断的追求和突破。